标签： php-fpm
-
在解决 WordPress 首页性能问题后，对当前服务器进行了完整配置审计，重点检查 Nginx、PHP-FPM、OPcache、Redis、W3 Total Cache、阿里云 RDS/MySQL 以及 WordPress 应用层。最终将 PHP-FPM 最大工作进程从 10 提高到 14，调整 OPcache 内存与 Interned Strings 配置，关闭 Gutenberg 实时协作，并为 SlyTranslate 调试日志增加日志轮转；同时保留大量已经运行健康的参数不变，形成一套更适合当前网站长期运行的服务器配置基线。
-
本文记录一次 WordPress 动态首页性能问题的完整排查与优化过程。绕过 EdgeOne、Cloudflare 和 W3 Total Cache 后，发现中文首页真实动态生成时间接近 19 秒。通过 PHP-FPM slowlog、MySQL EXPLAIN 与实际 SQL 基准测试，最终定位到 Post Views Counter 的热门文章排行榜查询：完整 wp_posts.* 参与 SUM、GROUP BY 和 ORDER BY，导致 MySQL 5.7 创建磁盘临时表。通过 MU Plugin 将查询改造成“轻量排名 + Top N 完整文章加载”的两阶段结构后，中文动态首页降至约 0.83～0.89 秒，英文首页稳定在约 0.87～0.96 秒，同时保持排行榜顺序、浏览量和 Polylang 语言过滤正确。
-
将 WordPress 生产环境升级到 PHP 8.5 后，PHP-FPM 日志中出现了多项插件兼容性警告。本文记录对 TMS Extensions for Polylang、Nimble Page Builder、SyntaxHighlighter、Yoast SEO 和 PublishPress Series 的逐项排查：停用已经失去实际用途的 Nimble Page Builder，为 SyntaxHighlighter 实施三处最小兼容性补丁，对无法稳定复现的 Yoast SEO 问题暂不修改，并将 PublishPress Series 的问题提交给上游。整个过程以正常生产环境是否受影响为判断依据，而不是盲目追求清除所有 Deprecated 和 Notice 日志。
-
本文记录在 OneinStack 生产环境中将 PHP 从 8.1.19 升级到 8.5.9 的完整过程。升级期间，PHP 主体、PHP-FPM、Redis 和 LDAP 扩展均安装成功，但 Imagick 3.8.0 因 PHP 8.5 头文件兼容问题编译失败，最终改用 Imagick 3.8.1，并明确指定现有 ImageMagick 7.1.1-10 的安装路径完成编译。随后继续验证 WordPress、WP-CLI、REST API、Polylang 多域名输出，以及 W3 Total Cache Redis Object Cache 的跨请求持久化和中英文域名 Host 隔离，确认中文站、英文站和后台域名均正常运行。
-
阿里云 ECS 再次频繁触发 CPU 告警后，我结合云监控与 EdgeOne 离线日志，确认自动化抓取和大量回源 MISS 是主要诱因，而 W3TC 未预缓存归档分页只是放大因素。考虑到服务器长期运行在 1 核 2G、内存占用接近 60%，且后续还要部署 Go Tour，最终将实例升级为 2 核 4G。本文记录了告警分析、规格选择、快照备份、升配重启，以及 Nginx、PHP-FPM、Redis、W3TC 和三个域名的完整验证过程。
-
本文记录一次 WordPress 中文站 EdgeOne 524 故障的排查与优化过程。故障期间，大量带有 amp、nonamp、query-62-page 等查询参数的文章和列表页出现缓存 MISS，导致 1 核 ECS 上的 PHP-FPM 进程被占满。为减少缓存碎片和重复回源，本文将原有文章详情页的 Query String 归一化方案扩展至首页、分类、标签、系列和日期归档等公开列表页，并分别在 EdgeOne 与 Cloudflare 中配置缓存 Key 忽略、回源去参和 URL 重写。同时保留 WordPress 搜索参数 s，通过 MISS → HIT、缓存 Age 及 Nginx 源站日志验证规则已经生效。
-
一次阿里云 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。此次排查说明，服务器出现性能瓶颈时，不应急于升级配置，应先确认异常流量和真正的资源消耗来源。