标签： php-fpm
-
此前已经发现 W3 Total Cache 页面缓存长期很难看到超过 2 天的文件，但当时正在批量处理历史文章，不适合立即判断。等历史处理结束后，借这次 CPU 告警继续排查，最终发现联合预热 Sitemap 长期生成失败，根因是 Yoast SEO 生成 post-sitemap.xml 时触发 PHP 256M 内存耗尽并返回 HTTP 500。将 PHP-FPM memory_limit 提升到 512M 后，中英文 Sitemap 恢复 200，联合预热 Sitemap 也恢复自动更新。
-
在多次 OneinStack 生产环境升级和兼容性处理之后，我将已经实际验证并固化到代码中的修改整理为 oneinstack-custom 定制分支，并正式公开到 GitHub。该分支继续保留 OneinStack 原有目录结构和运维方式，重点补充 PHP 8.5.9 构建兼容、GNU libiconv 冲突处理、Imagick 3.8.1、PHP-FPM 状态验证以及 Nginx/OpenSSL 3.5.7 构建等内容。本文同时梳理 OneinStack 原生能力与定制分支的边界，并说明哪些历史运维实践尚未自动化进入仓库。
-
在解决 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 规范化，从根源减少动态参数造成的缓存穿透。