[实战] PHP WorkerMan CPU过高导致的业务延时 排查与解决

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[实战] PHP WorkerMan CPU过高导致的业务延时 排查与解决相关的知识,希望对你有一定的参考价值。

业务场景

终端机通过互联网走TCP协议通过nginx反向代理服务器与线上php服务器中的WorkerMan进程通讯,属于长连接,对实时性要求较高。
技术分享图片

系统与应用环境

# uname -r
3.10.0-693.11.1.el7.x86_64

# cat /etc/centos-release
CentOS Linux release 7.4

Workerman   version:3.5.5
PHP         version:5.6.36

# php -m
[PHP Modules]

event
phpiredis
这里只列出了高并发相关的已经加载的模块

现象

终端机通过扫码形式进行打开,发现在扫码后会有大约5-10秒的延时才开始下一流程工作。体验变得很糟糕。

排查过程

因为终端机是与Workerman通讯的,因此,直接查看此应用的情况

Workerman 实时连接情况
技术分享图片

技术分享图片

通过htop指令,发现Workerman占用的CPU核心(CPU 1)还是特别高的。
技术分享图片

按理说,刚增加的CPU核数,应该可以改善CPU高的问题啊。不过呢,仔细观察,本机的业务分为传统PHP类和Workerman,按照官方的手册讲到的,Workerman并不跟php-fpm有太多的影响。实际中确实也反映出来了,跟Workerman连接的终端会延时,同一时刻,相关的PHP访问却不受影响,除非整个服务器的CPU都超高。

开始把问题瞄向了磁盘IO和网络IO瓶颈上面,不过当我调出相关的性能监控的时候,发现并不是这个原因。虽然说有写日志的行为,在SSD磁盘的上面还是没有压力的。

随即寻求Workman官方技术群主帮助,通过状态页和相关监控系统指令,产生了疑问:
业务有啥耗费cpu的操作么?请求量不大怎么cpu这么高?

通过mpstat查看每个核的CPU状况,发现运行Workerman的CPU核心确实存在CPU高的现象
技术分享图片

于是,立即使用strace命令跟踪下情况

strace命令是一个集诊断、调试、统计与一体的工具,我们可以使用strace对应用的系统调用和信号传递的跟踪结果来对应用进行分析,以达到解决问题或者是了解应用工作过程的目的。

strace -ttp 进程号

技术分享图片

其中每一行是一个系统调用,从这个信息中我们很容易看到进程在做一些什么事情,可以定位到进程卡在哪里,卡在连接还是读取网络数据等

在与终端机发送消息是一去一回,有一个FD=10的操作相当的频繁,刷新的非常快。

使用lsof跟踪此进程

# lsof -p 24373 | grep 10

技术分享图片

可以看出,这个就是本机向redis主机通讯(没有采用默认的6379端口号)
技术分享图片

会不会是redis的瓶颈引发的?

再次确认了所连接的Redis配置如下
技术分享图片

内网每秒发包数不到2000 pps,远远没达到极限的5万pps
技术分享图片

事实证明,并不是因为Redis服务的瓶颈。

定位问题

与开发人员进行沟通,得知这是终端设备查询的操作。而且访问的数据都相同,这样疯狂访问redis,导致了cpu利用率过高,就容易延迟了。

至此,基本定位出问题了,剩下的就交给开发进行优化了。

解决方案

后续再更新解决方案:请等待。。。

以上是关于[实战] PHP WorkerMan CPU过高导致的业务延时 排查与解决的主要内容,如果未能解决你的问题,请参考以下文章

JVM故障问题排查心得「虚拟机线程问题」实战分析JVM线程导致CPU过载过高的问题排查方案

求php-cgi.exe使用率过高导致CPU100%的解决办法

php-fpm进程占用CPU过高| php-cgi进程过多

php-fpm占用cpu和内存过高100% 解决办法

PHP CGI 进程占用CPU过高导致CPU使用达到100%的另类原因

SHOPNC占用CPU过高