【转载】php-fpm的高CPU使用率排查方法

1、CPU使用率监控

sar -P ALL 1 100

输出结果如下:
CPU %user %nice %system %iowait %steal %idle
all 85.54 0.00 5.69 0.00 0.00 8.76
0 74.75 0.00 25.25 0.00 0.00 0.00
1 98.00 0.00 2.00 0.00 0.00 0.00
2 89.22 0.00 3.92 0.00 0.00 6.86
3 91.00 0.00 2.00 0.00 0.00 7.00
4 75.00 0.00 9.00 0.00 0.00 16.00
5 94.95 0.00 5.05 0.00 0.00 0.00
6 95.00 0.00 4.00 0.00 0.00 1.00
7 87.88 0.00 4.04 0.00 0.00 8.08
8 93.94 0.00 3.03 0.00 0.00 3.03
9 88.00 0.00 3.00 0.00 0.00 9.00
10 89.11 0.00 2.97 0.00 0.00 7.92
11 82.35 0.00 3.92 0.00 0.00 13.73
12 73.27 0.00 7.92 0.00 0.00 18.81
13 81.44 0.00 4.12 0.00 0.00 14.43
14 77.23 0.00 6.93 0.00 0.00 15.84
15 78.79 0.00 4.04 0.00 0.00 17.17

2、开启php-fpm慢日志

配置输出php-fpm慢日志,阀值为2秒:

request_slowlog_timeout = 2 #设置一个超时的参数
slowlog = log/$pool.log.slow #设置慢日志的存放位置,查看:tail -f xxx.slow.log

利用sort/uniq命令分析汇总php-fpm慢日志:

[[email protected] log]# grep -v "^$" www.log.slow.tmp | cut -d " " -f 3,2 | sort | uniq -c | sort -k1,1nr | head -n 50
5181 run() /www/test.net/framework/web/filters/CFilter.php:41
5156 filter() /www/test.net/framework/web/filters/CFilterChain.php:131
2670 = /www/test.net/index.php
2636 run() /www/test.net/application/controllers/survey/index.php:665
2630 action() /www/test.net/application/controllers/survey/index.php:18
2625 run() /www/test.net/framework/web/actions/CAction.php:75
2605 runWithParams() /www/test.net/framework/web/CController.php:309
2604 runAction() /www/test.net/framework/web/filters/CFilterChain.php:134
2538 run() /www/test.net/framework/web/CController.php:292
2484 runActionWithFilters() /www/test.net/framework/web/CController.php:266
2251 run() /www/test.net/framework/web/CWebApplication.php:276
1799 translate() /www/test.net/application/libraries/Limesurvey_lang.php:118
1786 load_tables() /www/test.net/application/third_party/php-gettext/gettext.php:254
1447 runController() /www/test.net/framework/web/CWebApplication.php:135

参数解释:

sort: 对单词进行排序
uniq -c: 显示唯一的行,并在每行行首加上本行在文件中出现的次数
sort -k1,1nr: 按照第一个字段,数值排序,且为逆序
head -10: 取前10行数据

3、用strace跟踪进程

1)利用nohup将strace转为后台执行,直到attach上的php-fpm进程死掉为止:

  nohup strace -T -p 13167 > 13167-strace.log &

参数说明:

2)也可以用利用-c参数让strace帮助汇总,非常方便非常强大!

[[email protected] log]# strace -cp 9907
Process 9907 attached - interrupt to quit
Process 9907 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
56.61 0.016612 5 3121 read
11.11 0.003259 1 2517 715 stat
8.04 0.002358 7 349 brk
6.02 0.001767 1 1315 poll
4.28 0.001255 6 228 recvfrom
2.71 0.000796 1 671 open
2.54 0.000745 0 2453 fcntl
2.37 0.000696 1 1141 write
1.69 0.000497 1 593 13 access
1.37 0.000403 0 1816 lseek
0.89 0.000262 1 451 22 sendto
0.56 0.000163 1 276 208 lstat
0.49 0.000145 0 384 getcwd
0.31 0.000090 0 1222 fstat
0.28 0.000082 0 173 munmap
0.26 0.000077 0 174 mmap
0.24 0.000069 2 41 socket
0.23 0.000068 0 725 close
0.00 0.000000 0 13 rt_sigaction
0.00 0.000000 0 13 rt_sigprocmask
0.00 0.000000 0 1 rt_sigreturn
0.00 0.000000 0 78 setitimer
0.00 0.000000 0 26 26 connect
0.00 0.000000 0 15 2 accept
0.00 0.000000 0 39 recvmsg
0.00 0.000000 0 26 shutdown
0.00 0.000000 0 13 bind
0.00 0.000000 0 13 getsockname
0.00 0.000000 0 65 setsockopt
0.00 0.000000 0 13 getsockopt
0.00 0.000000 0 8 getdents
0.00 0.000000 0 26 chdir
0.00 0.000000 0 1 futex
------ ----------- ----------- --------- --------- ----------------
100.00 0.029344 18000 986 total

ps:可以使用strace学习php解释器的解释执行过程

4、加速PHP解释执行

如果自己的程序的确没有问题,只是执行了太多操作,没法再做优化了。则考虑使用APC或xcache等PHP加速器来减少CPU解释php文件的耗时。这些PHP加速器在php文件第一次解释时会生成中间代码opcode,所以之后的执行会快很多,并且减少了一些CPU的运算。以xcache为例,看下如何安装和配置。
    XCache:是一个开源的opcode缓存器/优化器, 这意味着他能够提高您服务器上的PHP性能。他通过把编译PHP后的数据缓冲到共享内存从而避免重复的编译过程, 能够直接使用缓冲区已编译的代码从而提高速度. 通常能够提高您的页面生成速率2到5倍, 降低服务器负载。

安装xcache,php.ini中配置如下,一般推荐xcache.size根据php文件多少来定,xcache.count与CPU核心数相同:

[xcache.admin]
xcache.admin.enable_auth = Off
xcache.admin.user = "xcache"
xcache.admin.pass = ""

[xcache]
xcache.shm_scheme ="mmap"
xcache.size=1024M
xcache.count =16
xcache.slots =8K
xcache.ttl=0
xcache.gc_interval =0
xcache.var_size=16M
xcache.var_count =1
xcache.var_slots =8K
xcache.var_ttl=0
xcache.var_maxttl=0
xcache.var_gc_interval =300
xcache.test =Off
xcache.readonly_protection = Off
;xcache.readonly_protection = On
xcache.mmap_path ="/dev/zero"
;xcache.mmap_path ="/tmp/xcache"
xcache.coredump_directory =""
xcache.cacher =On
xcache.stat=On
xcache.optimizer =Off

[xcache.coverager]
;;xcache.coverager =On
;;xcache.coveragedump_directory =""

常见问题:

  启动php-fpm时会报错:Cannot open or create file set by xcache.mmap_path, check the path permission or check xcache.size/var_size against system limitation    这是因为/tmp/xcache是一个文件,而不能创建成目录。

  重启php-fpm服务后,用top命令观察会发现每个worker进程的VIRT(包含了swap区)都是xcache.size大小,但REQ变得很小了。使用上面的配置在使CPU使用率的峰值时间变短了,但峰值时还是所有核心都会达到90%以上,不知道是不是哪里没有配置对。另外高并发时,/dev/zero这种配置方式经常会导致Nginx 502错误。/tmp/xcache和开启readonly_protection则很稳定。

时间: 2024-11-29 06:56:33

【转载】php-fpm的高CPU使用率排查方法的相关文章

嵌入式 如何定位死循环或高CPU使用率(linux)

如何定位死循环或高CPU使用率(linux) 确定是CPU过高 使用top观察是否存在CPU使用率过高现象 找出线程 对CPU使用率过高的进程的所有线程进行排序 ps H -e -o pid,tid,pcpu,cmd --sort=pcpu |grep xxx 得到如下结果,其中线程2909使用了7.8%的CPU. 2907 2913 0.0 ./xxx 2907 2909 7.8 ./xxx 也可以通过查看/proc中的信息来确定高CPU线程. 打印了4列,线程ID,线程名,用户时间和内核时间

制造高CPU使用率的简单方法

原文:制造高CPU使用率的简单方法 在群里有人问制造CPU占用率高的场景用来做测试.所谓做好事难,干“坏”事还不容易?这个需求有很多方法可以实现,比如使用一些压力测试工具.我首先想 到的是HASH JOIN.这个联接比较消耗CPU资源,拿两大表HASH JOIN一下,最好是包含大字段的,开多几个进程,CPU使用率马上飙升到80-90%! 下面就使用一张系统视图进行HASH JOIN来实现,简单快捷. DECLARE @i BIGINT WHILE (1=1) BEGIN SELECT @i =

[Java] HashMap 导致的高 CPU 使用率

今天在生产环境遇到一个问题,Java 应用程序的 cpu 使用比例很高,导致整台机器的 cpu 使用率高达 90% ,正常情况下是 20% 左右. 把 Thread dump 导出来,利用 IBM Thread Analyzer for Java 工具进行分析.总共有60 多个在线线程,其中有 15 个线程都在执行同一个文件中的同一句代码,最顶层的调用是 HashMap.get() . HashMap 的底层数据结构是数组 + 链表进行存储,链表用于处理 hash 碰撞的情况.正常情况下链接是线

制造高CPU的简单方法

今天在群里有人问制造CPU占用率高的场景用来做测试.所谓做事难,做"坏"事很容易啊.这个需求有很多方法可以实现,比如使用一些压力测试工具.我首先想到的是HASH JOIN.这个联接比较消耗CPU资源,拿两大表HASH JOIN一下,最好是包含大字段的,开多几个进程,CPU使用率马上飙升到80-90%! 下面就使用一张系统视图进行HASH JOIN来实现,简单快捷. DECLARE @i BIGINT WHILE (1=1) BEGIN SELECT @i = COUNT(*) FROM

记一次服务器高CPU的排查思路

现象 排查思路 另一台服务器CPU正常,由于消息中心有部分老接口是域名调用的,网关已做负载均衡,并且pinpoint上的两台服务器gc如图,初步猜测是否是负载不均衡导致. 经运维调试nginx权重无效,证明与负载均衡无关.那么先看子线程,这种情况必定由某几个线程引起 ps -mp pid -o THREAD,tid,time命令查看子线程,如图 这个数据上,分两部分看,1.有3个占用高的线程,2.执行时间可以注意到分别是4天,1天,23小时.说明线程出于某种情况,死锁,死循环. 由于这时候jst

Linux性能优化从入门到实战:04 CPU篇:CPU使用率

??CPU使用率是单位时间内CPU使用情况的统计,以百分比方式展示. $ top top - 11:46:45 up 7 days, 11:52, 1 user, load average: 0.00, 0.01, 0.00 Tasks: 198 total, 1 running, 197 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st K

WinCE 下 CPU 使用率的计算方法

在函数 GetIdleTime 的用法中,MSDN 推荐的 CPU 使用率的计算方法,在部分平台下使用时得到的使用率异常:非 0-100% 的数值. 先看看 MSDN 推荐的算法的大概实现: 1 static void CallCountCpuIdleThread(CCountCpuDlg *pCCountCpuDlg) 2 { 3 DWORD dwStartTick; 4 DWORD dwIdleStart; 5 DWORD dwStopTick; 6 DWORD dwIdleEnd; 7 i

.Net 调式案例—实验4 高CPU(High CPU)回顾

原文地址:http://blog.csdn.net/directionofear/article/details/8033506 如果Web应用程序经常遇到的问题按频率排名的话,我觉得 第一名unhandled exception 第二名high memory 第三名high cpu 这篇文章介绍web应用程序中cpu使用率过高问题相应的数据收集方式和调试问题的方法. 对ASP.NET Web应用程序CPU使用率过高的问题,从宏观上分分类,大概就这么几种情况, 大量请求 过多循环 GC频繁 数据

shell 获取cpu使用率

shell脚本获取主机每颗CPU使用率的方法. #!/bin/bash interval=3 cpu_num=`cat /proc/stat | grep cpu[0-9] -c` start_idle=() start_total=() cpu_rate=() cpu_rate_file=./`hostname`_cpu_rate.csv if [ -f ${cpu_rate_file} ]; then mv ${cpu_rate_file} ${cpu_rate_file}.`date +%