[实战] PHP WorkerMan CPU太高致使的业务延时 排查与优化

WorkerMan介绍

官方项目地址：https://www.workerman.net/features

workerman是一个高性能的PHP socket 服务器框架，workerman基于PHP多进程以及libevent事件轮询库，
PHP开发者只要实现一两个接口，即可以开发出本身的网络应用，例如Rpc服务、聊天室服务器、手机游戏服务器等。

workerman的目标是让PHP开发者更容易的开发出基于socket的高性能的应用服务，
而不用去了解PHP socket以及PHP多进程细节。 

workerman自己是一个PHP多进程服务器框架，具备PHP进程管理以及socket通讯的模块，
因此不依赖php-fpm、nginx或者apache等这些容器即可以独立运行。

业务场景

终端机经过互联网走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利用率太高，就容易延迟了。

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

解决方案

1.减小查询返回的量

2.将每次一种状态生成的redis操做的频繁指令合并到多个指令数据集合操做一条redis操做。

3.将遍历方法变成校对产生变化的值，从而减小量级。

取值时间 9:00-21:00

WorkerMan主机平均负载

优化前

优化后

WorkerMan进程CPU使用率

优化前

优化后

redis主机网络流入流出数据包数(pps)

优化前

优化后 ，由于是经过2次优化处理，因此这张图能很明显的看出对比变化

目前线上业务延时已经恢复正常，优化还在进行中，重点将会是WorkerMan进程的CPU优化，不知各位看官有什么多进程处理的好方案呢？