标签： php-fpm
-
一次阿里云 ECS CPU 接近 100% 的告警，最终从 Nginx 499、PHP-FPM max_children、Slowlog、W3 Total Cache Object Cache 和 Redis 一路排查到 Page Cache 冷缓存。实测发现服务器仅有 1 vCPU，而 /page/9/ 在 Cold MISS 时 TTFB 高达 10.6 秒，缓存命中后仅约 0.016 秒。最终没有提高 PHP-FPM 并发、关闭 Redis 或开启缓存预热，而是将 W3TC Page Cache 最长生命周期从 1 小时延长到 12 小时，以降低历史页面反复动态生成带来的 CPU 压力。
-
在通过 EdgeOne 屏蔽异常 Sogou UA 流量、解决 WordPress 502 后，阿里云 ECS 仍然偶发 CPU 95%～100% 告警。进一步结合 PHP-FPM Slow Log、Nginx 请求日志和 W3 Total Cache 实测发现，大量带 Query String 的前台请求会导致 W3TC Disk: Enhanced 页面缓存无法复用，使请求重新进入 PHP-FPM，完整执行 Gutenberg、Polylang、Post Views Counter、Redis Object Cache 和数据库查询。正常 URL 第二次请求 TTFB 仅约 0.1 秒，而带参数 URL 每次仍需约 7～11 秒。最终决定不逐个封禁参数，也暂不升级服务器或修改 W3TC 内部逻辑，而是在 EdgeOne 与 Cloudflare CDN 层进行 Query String 缓存键和回源 URL 规范化，从根源减少动态参数造成的缓存穿透。
-
在一次 WordPress 502 故障排查结束后，我继续完善阿里云 ECS 的主机监控与报警体系。排查发现原有云监控 Agent 2.1.56 已停止运行，导致 CPU、内存、磁盘等操作系统级指标长期没有数据。随后通过传统云监控「主机监控」将 Agent 升级至 4.0.0，恢复 CPU、内存、Load、磁盘、网络和公网带宽等监控，并分别为 CPU、内存、磁盘及公网流出带宽设置 Info、Warn、Critical 三级报警。结合恢复后的实际监控数据，现阶段 1 核 2G ECS 与 2 Mbps 公网带宽仍有明显余量，因此暂不升级服务器，而是先通过持续监控积累长期运行基线，让服务器运维从“故障后排查”转向“异常前预警”。
-
一次 WordPress 生产站间歇性 502 故障排查记录。阿里云 ECS 一度出现 CPU 100%、Load 超过 9、PHP-FPM Socket 队列达到 510/511，大量请求返回 499 和 502。通过分析 Nginx 日志发现，最近 20000 条请求中有 18455 条携带 Sogou web spider/4.0 User-Agent，并以每分钟约 500～700 次的频率持续遍历网站。随后在 EdgeOne 中通过 *Sogou* User-Agent 规则进行边缘拦截，Sogou UA 请求降至 0，PHP-FPM 队列恢复为 0/511，CPU 空闲率最高恢复到 97%，后台连续请求全部返回 HTTP 200。此次排查说明，服务器出现性能瓶颈时，不应急于升级配置，应先确认异常流量和真正的资源消耗来源。
-
这篇博客记录了一次 WordPress 核心升级失败的完整排查过程：在从 WordPress 7.0 升级到 7.0.1 时，后台反复出现 524 超时和“另一更新正在进行”的提示。通过检查 `core_updater.lock`、WordPress 当前版本、升级临时目录、文件权限以及 EdgeOne 转发状态，最终确认 WordPress 核心文件并未半升级，问题主要集中在经过 CDN 代理后的后台长请求超时。文章进一步总结出：前台页面适合继续走 EdgeOne 缓存，而 WordPress 后台更新、插件安装等维护操作，后续应考虑通过独立后台域名或源站直连方式处理，以避免 CDN 对后台长请求造成干扰。
-
个人博客出现 504 Gateway Timeout，排查发现服务器因恶意扫描和分布式爬虫导致严重过载。内存被过多的 PHP-FPM 进程耗尽，引发负载飙升。通过降低 PHP-FPM 进程数以适配硬件配置，在 Nginx 层面封禁恶意扫描 IP 及爬虫 IP 段，并重启 ECS 清理积压进程，最终解决了资源耗尽问题，恢复了服务正常响应。
-
文章针对 curl 请求 https 网址时响应为 false 的问题进行了排查分析。通过 var_dump 检查请求返回值为 false 后，操作过程是在 php.ini 中配置 openssl.cafile 路径。重启 php-fpm 服务后，问题得到解决，不再响应 false，完成了对 curl 请求异常的修复。
-
文章记录了一个 GraphQL API 耗时长达 7 秒的排查过程。经 Laravel Telescope 和独立客户端测试，实际执行时间仅约 1.8 秒。问题根源在于 Windows 10 环境下的 Nginx 与 PHP FastCGI 默认只能同时处理单一请求，导致请求排队。通过调整 Nginx 配置并启动多个 php-cgi 进程绑定不同端口，实现了并发处理。最终刷新页面测试，请求耗时缩短至 2 秒左右，符合预期。
-
针对 Nginx 与 FastCGI 环境下日志表数据量达到 GB 级时，查询最后一页出现 504 Gateway Time-out 超时的问题，通过分析定位了本地环境与生产环境的配置差异。在本地增加 fastcgi_read_timeout 并调整 PHP 脚本最大执行时间后问题解决，但在生产环境中排查发现，由于请求经过 Kong 网关，超时原因出在网关层面而非后端服务，最终确认由运维人员处理网关配置。