设为首页 收藏本站
查看: 1547|回复: 0

[经验分享] [实战] PHP WorkerMan CPU过高导致的业务延时 排查与优化

[复制链接]

尚未签到

发表于 2018-12-11 12:34:25 | 显示全部楼层 |阅读模式
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优化,不知各位看官有什么多进程处理的好方案呢?




运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-650118-1-1.html 上篇帖子: axis2 webservice入门知识(JS,Java,PHP调用实例源码) 下篇帖子: docker安装php
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表