Yaf框架是一个c语言编写的PHP框架,它更快、更轻、内存占用更低。项目组本着对性能的追求选择了Yaf框架,由于安全的原因PHP升级到7.3.18,为了兼容PHP,将Yaf升级到3.2.3。Yaf框架的bug导致PHP进程core。尽管从表象上看就是一个core,但整个排查解决的过程还是遇到了不少困难,这里记录了这一次线上core的整个排查过程,希望能够帮助遇到类似问题的同学。
因为php 7.0.9有安全漏洞,升级到php 7.3.18,PHP的Yaf框架3.2.3版本导致接口服务出现502。
现象:达到2000 qps时有15台机器出现502的问题,重启PHP后问题不重现。
问题影响: 15%的请求会出502
通过strace attach到进程看到发生了segfault,进程被系统信号SIGSEGV强杀。
进程被SIGSEGV强杀,第一反应是去找coredump,cordump是进程在退出前由操作系统把进程当前的内存转存到一个core文件中。core文件包含程序运行时的内存信息,含寄存器状态、堆栈指针、内存管理信息、操作系统flags。core文件中保留了进程被杀的“凶案”现场,找到core文件几乎就等于抓住了“凶手”。经过一顿搜索并未发现生成core。
ulimit -a 显示core file size为unlimited,系统允许生成core文件。排除
查看core文件目标存储路径,确认进程有权限写入。排除
查看/proc/pid/status发现sigCgt为0x0000000184004a07,SIGSEGV并未被进程捕获。排除
linux支持对每个进程进行dumpable标记,dumpable被设置为SUID_DUMP_DISABLE(0) 的进程不会输出core。PHP 7之后进程默认不会输出core。
修改进程dumpable标记位:
尝试用GDB的方式来设置CORE的标记位,让PHP在异常的情况下能打DUMP gdb -p pid 执行call prctl(4,1)。第一个参数4表示PR_SET_DUMPABLE,第二个参数1表示SUID_DUMP_USER,经验证可以输出coredump
找到了core文件就等于抓住了“凶手”,从堆栈中分析可以看到挂在Yaf。
Yaf 3.2.3版本,请求uri中出现两个相同参数,进程会被SIGSEGV信号杀掉。
github issues:
https://github.com/laruence/yaf/issues/490 (请求web服务时, uri参数两个参数名相同出现 502)
https://github.com/laruence/yaf/issues/491 (从yaf3.0.9升级到3.2.4出现php-fpm进程被SIGSEGV信号杀掉)
回退yaf版本到3.0.9,该版本经验证没有上述bug且可兼容php 7.3.18版本。
项目在使用第三方扩展中遇到问题是经常会出现的问题,在进行选型时要充分了解第三方扩展及使用版本的稳定性避免踩坑。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。