运营中心PHP实时交互卡顿？14年运维老炮三招速解

　　今天下午三点十七分，运营中心那个PHP实时交互页面又卡了——不是加载慢，是输完字等三秒光标才跳，点提交按钮得按两次，第二次才有反应。我正蹲在监控台前盯FPM进程数，小王端着咖啡过来问：“张工，是不是又触发限流了？”我没抬头，回他：“限流有日志，这没日志。”

　　第一招：把opcache.revalidate_freq从0改成2。改完三秒后我刷新，还是卡。小王说：“那可能得清下opcode缓存。”我敲完opcache_reset()，屏幕闪了一下，输入框终于跟手了——可两分钟后，又开始顿，像踩了刹车。我原以为是缓存热身没过，结果看进程发现php-fpm子进程全挂在stream_select上，第七个worker卡在curl_exec里，但上游服务HTTP状态码全是200。

　　第二招：查nginx upstream keepalive。发现配的是32，但后端PHP用的file_get_contents，没开stream context的http.keepalive。我把nginx upstream keepalive_connections调到64，加了proxy_http_version 1.1；重启nginx，小王试了五次，第三次卡得更久——光标停在“请稍候”弹窗中间不动，连×都点不了。他低头戳手机，说：“客服刚转来三个投诉，说‘提交就像扔进黑洞’。”

　　第三招：临时切走流量。不是切到备用集群，是直接把/api/realtime这个location return 503。我手抖输错成502，少打了个斜杠，回车一按，整条rewrite规则崩了，运营后台所有图片路径全404。还好就十来秒，我赶紧补上，Ctrl+C中断重配。再试，实时接口活了，不卡，也不抖，小王对着屏幕哈了口气擦掉指纹，说：“真神。”

　　可二十来分钟后，同一台机器上另一个Python脚本突然占满磁盘IO——它每天这时候扫/tmp，和PHP共享一个RAID1阵列。我们没人动它，但它扫完正好压住fpm的write操作。监控图上IO wait曲线像心电图乱跳，PHP响应时间跟着抽搐，但只持续八秒，第八次峰值后自己平了。我也不知道这算不算相关，反正它每次发作都比PHP卡顿晚四秒二。

文章配图，仅供参考

　　（办公室绿萝上周换盆，现在新叶卷边）

　　最后发现，真正卡顿的源头是前端SDK里埋的一个setInterval，每200毫秒调一次PHP接口做心跳，参数带了个无意义的timestamp=Math.random()，后端收到后必须走完整session_start→pdo连接→查表→写log→echo空json流程——没缓存，没短路，就是硬扛。删掉那行JS，卡顿立刻消失。但问题是：这个JS三个月前就上线了，为啥偏偏这周爆？因为上周三财务部统一装了新版Chrome 131，而这个版本把Math.random()精度从16位提到了53位，导致后端log文件日增27MB，最后把/var/log所在分区的inodes吃光了七成……

　　我说不清是log占inode引发的延迟，还是Chrome升级触发的JS执行频次畸变，还是opcache校验本身在高inode压力下变慢——我只知道改完opcache.revalidate_freq那会儿，我听见机房空调发出一声闷响，像谁在铁皮箱里关上了抽屉。

　　有谁碰到过这个吗

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!