【PHP问题定位】2018-07-02 fpm掉底分析

滞波接口
• 阅读 3026

顺风车运营研发团队 黄桃

问题现象
某机器这段时间出现cpu-idle掉地的报警 如图:

【PHP问题定位】2018-07-02 fpm掉底分析

原因分析

查看当时的监控(php-fpm-idle、cpu-idle,io-wait、io-write 等)
(1)php-fpm-idle今天出现两次突降,一次是12点左右,一次是16:30左右,查看整周也经常出现突降,如图

【PHP问题定位】2018-07-02 fpm掉底分析

(2)io-wait在11:58分时 突然升高

【PHP问题定位】2018-07-02 fpm掉底分析

(3)io-write也在11:58时出现大量写:

【PHP问题定位】2018-07-02 fpm掉底分析

(4)cpu-idle当时短暂出现降低,之后出现徒增,但是结合整周的曲线来看,一直维持在70-80之间,徒增原因待分析:

【PHP问题定位】2018-07-02 fpm掉底分析

(5)原因推测:因为当时出现了大批量的写日志,导致io-wait上升,php-fpm进程因为写文件出现延时,造成整体响应过慢,从而导致了fpm掉地; 对同一个文件进行 write时,大批量并行会出现等待,阻塞

验证推测
(1)查看当时的php-fpm的慢日志,看当时阻塞的地方,基本是在调用fwrite阻塞

【PHP问题定位】2018-07-02 fpm掉底分析

(2)查看当时的程序日志trace.log的大小,日志文件越大的时间段,正好是fpm-idle下滑严重的阶段:

【PHP问题定位】2018-07-02 fpm掉底分析

(3)在通过 sar命令,验证下当时的写入磁盘情况,在出现掉地的时间段确实出现极大的写入,wr_sec/s 从每秒几百低峰的几百增长到十几万:

【PHP问题定位】2018-07-02 fpm掉底分析

问题原因及优化建议
写入日志大可能两方面原因:

(1)当时请求暴增
(2)请求未暴增,但是某些请求触发了某些不合理的打日志
验证原因1,出现问题时间段每秒的流量

32 [02/Jul/2018:12:01:12
18 [02/Jul/2018:12:01:13
18 [02/Jul/2018:12:01:14
42 [02/Jul/2018:12:01:15
30 [02/Jul/2018:12:01:16
35 [02/Jul/2018:12:01:17
26 [02/Jul/2018:12:01:18
30 [02/Jul/2018:12:01:19
1 [02/Jul/2018:12:01:22
108 [02/Jul/2018:12:01:24
17 [02/Jul/2018:12:01:25
1 [02/Jul/2018:12:01:27
1 [02/Jul/2018:12:01:29
1 [02/Jul/2018:12:01:30
9 [02/Jul/2018:12:01:33
1 [02/Jul/2018:12:01:31
1 [02/Jul/2018:12:01:32
146 [02/Jul/2018:12:01:33
62 [02/Jul/2018:12:01:34
44 [02/Jul/2018:12:01:35
1 [02/Jul/2018:12:01:37
1 [02/Jul/2018:12:01:38
1 [02/Jul/2018:12:01:41
2 [02/Jul/2018:12:01:44
2 [02/Jul/2018:12:01:50
1 [02/Jul/2018:12:01:45
12 [02/Jul/2018:12:01:50
2 [02/Jul/2018:12:01:45
7 [02/Jul/2018:12:01:50
1 [02/Jul/2018:12:01:46
1 [02/Jul/2018:12:01:50
1 [02/Jul/2018:12:01:46
15 [02/Jul/2018:12:01:50
7 [02/Jul/2018:12:01:48
2 [02/Jul/2018:12:01:50
1 [02/Jul/2018:12:01:48
342 [02/Jul/2018:12:01:50
65 [02/Jul/2018:12:01:51
46 [02/Jul/2018:12:01:52
54 [02/Jul/2018:12:01:53
1 [02/Jul/2018:12:01:55
1 [02/Jul/2018:12:01:56
1 [02/Jul/2018:12:01:57
1 [02/Jul/2018:12:01:59
16 [02/Jul/2018:12:02:03
1 [02/Jul/2018:12:02:01
1 [02/Jul/2018:12:02:02
42 [02/Jul/2018:12:02:03
1 [02/Jul/2018:12:02:02
187 [02/Jul/2018:12:02:03
39 [02/Jul/2018:12:02:04
40 [02/Jul/2018:12:02:05
25 [02/Jul/2018:12:02:06
44 [02/Jul/2018:12:02:07
29 [02/Jul/2018:12:02:08

正常情况是QPS是30左右,出问题时间段则非常不稳定,时高时低,相差非常大,例如在 12:01:50 时 342 qps,但是前十几秒则基本都是个位数;原因?前几十秒都阻塞了,响应不了,积累到了12:01:50才响应;整体流量并未出现暴增;

验证原因2,查看当时traceId日志,查看写进去的内容:

发现这段写入非常巨大,一行就119kb ,总共写了 33555 行,总大小占:33555 * 119KB = 3993045KB =3899M 基本可以断定为这行出的问题了
【PHP问题定位】2018-07-02 fpm掉底分析

优化建议:在底层打日志的类中对字符串长度做限制,避免这种大批量的写入;

点赞
收藏
评论区
推荐文章
Wesley13 Wesley13
3年前
java中比较两个时间的差值
项目背景1.某篇文稿的发布时间是publishDate,例如:2020072118:00:41。2.现要求判断该篇文稿的发布时间是否在近30天之内。publicstaticlongdayDiff(DatecurrentDate,DatepublishDate){LongcurrentTimecurrentDat
Wesley13 Wesley13
3年前
PHP教程
PHP教程php读取输出其他文件方法人们往往想到出现一些关于访问很缓慢,有白页现象,要是测试环境你也就重启一下PHP的phpfpm进程发现又好了,隔一段时间又出类似的问题,本期我们邀请到了兄弟连PHP教育www.lampbrother.net(https://www.oschina.net/action/GoToLink?urlhttp%3A
Stella981 Stella981
3年前
JS 苹果手机日期显示NaN问题
问题描述newDate("2019122910:30:00")在IOS下显示为NaN原因分析带的日期IOS下存在兼容问题解决方法字符串替换letdateStr"2019122910:30:00";datedateStr.repl
Stella981 Stella981
3年前
LAMP架构之php禁止解析、user_agent限定及php配置文件常规设置
本文索引:禁止某目录PHP解析限制user\_agentPHP相关配置查看PHP配置文件的位置安全函数设定设置时区错误信息日志安全相关的参数禁止某目录PHP解析某些目录可以上传图片等文件,如果不设置禁止PHP
Stella981 Stella981
3年前
SpringBoot整合Redis乱码原因及解决方案
问题描述:springboot使用springdataredis存储数据时乱码rediskey/value出现\\xAC\\xED\\x00\\x05t\\x00\\x05问题分析:查看RedisTemplate类!(https://oscimg.oschina.net/oscnet/0a85565fa
Wesley13 Wesley13
3年前
PHP创建多级树型结构
<!lang:php<?php$areaarray(array('id'1,'pid'0,'name''中国'),array('id'5,'pid'0,'name''美国'),array('id'2,'pid'1,'name''吉林'),array('id'4,'pid'2,'n
Easter79 Easter79
3年前
SpringBoot整合Redis乱码原因及解决方案
问题描述:springboot使用springdataredis存储数据时乱码rediskey/value出现\\xAC\\xED\\x00\\x05t\\x00\\x05问题分析:查看RedisTemplate类!(https://oscimg.oschina.net/oscnet/0a85565fa
Stella981 Stella981
3年前
PHP Header失效的原因分析
在PHP中用header("location:test.php")进行跳转要注意以下几点:1、location和“:”号间不能有空格,否则会出错。2、在用header前不能有任何的输出,包括include的页面中标签“?”后不能有空格!!3、header后的PHP代码还会被执行。续:问题:
Stella981 Stella981
3年前
Mongodb特定场景性能数十倍提升优化实践(记一次mongodb核心集群雪崩故障)
1\.问题背景某核心JAVA长连接服务使用mongodb作为主要存储,客户端数百台机器连接同一mongodb集群,短期内出现多次性能抖动问题,此外,还出现一次“雪崩”故障,同时流量瞬间跌零,无法自动恢复。本文分析这两次故障的根本原因,包括客户端配置使用不合理、mongodb内核链接认证
记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队
一、排查过程问题发现是因为当时接到了内存UMP报警信息,如下:通过查看PFinder发现内存一直在增长,没有停止迹象,触发fullGC也并没有下降趋势:当机立断,先立即去NP上摘除了此台机器流量,然后继续观察,发现内存依然在不断增长。随即查看故障分析,并没
HBase Sync功能导致HBase入库性能下降
本文分享自天翼云开发者社区《》,作者:5m问题背景与现象HBase入库慢,regionserver日志中大量打印slowsync。原因分析1.对比正常写入时间段监控,检查HBase服务整体CPU、内存以及NameNodeRPC在异常时间段是否增加;2.检查
滞波接口
滞波接口
Lv1
采得百花成蜜后,为谁辛苦为谁甜。
文章
4
粉丝
0
获赞
0