早上被客户连环call吵醒,说网站直接返回503，连错误页面都没来得及显示，我喝着豆浆刷面板，发现Apache进程确实挂了，但最诡异的是——重启了三次，启动后撑不过10分钟就自动消失。
第一反应是检查资源,内存还剩2.1G，CPU负载也正常，我盯着宝塔面板的Apache状态页，那个绿色的小圆点每次启动时亮那么几秒，然后变成灰色，像是在嘲讽我。
第一次踩坑：直接看错误日志是废的 习惯性点开“错误日志”，结果只有一行“Segmentation fault”，这种笼统的错误连小学生都知道是段错误，但具体哪里出了问题？我翻了半小时论坛，试过关opcache、禁用某些模块，问题依旧。
Apache日志别乱删！4年宝塔运维老鸟的血泪排查史
第二次踩坑：删日志删出大问题 实在没招了，我打开Apache的logs目录，发现access_log居然有12GB，想着先清掉腾点空间，顺手点了删除，结果再启动Apache，直接报“Permission denied”，原来之前一直用root账户在操作，日志文件是root删的，但日志目录的权限没改，导致子进程（以apache用户运行）无法创建新日志文件，修复了权限问题，Apache终于启动了，但10分钟后还是会挂掉。
第三次踩坑：错误日志竟然藏在PHP里 这时我突然灵光一灭——既然Apache本身启动正常，只是运行一段时间后崩溃，那问题可能出在处理请求的过程中，我打开PHP错误日志，果然发现了罪魁祸首：
[Wed Jun 19 10:22:45.302674 2025] [proxy_fcgi:error] [pid 28745] (104)Connection reset by peer: AH01075: Error dispatching request to : 但这行信息只说请求被重置了,具体哪个PHP脚本导致的？我继续往下翻，在同一个时间戳附近看到了一条警告：
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 5242880 bytes) in /www/wwwroot/xxx/wp-content/plugins/xxx-image-optimizer/class.xxx.php on line 582内存耗尽！但很多网站都有内存限制问题，顶多502，怎么会让整个Apache崩溃？我怀疑这个插件在内存耗尽后产生了无法处理的信号。
排查思路复盘：
- 看Apache主日志（error_log）→ 只有段错误，没用
- 看系统日志（journalctl -xe）→ 发现“php-fpm: pool www”的崩溃记录
- 看PHP-FPM慢日志 → 定位到具体CPU密集的请求
- 跟踪mod_fcgid错误 → 找到“Server connection timeout”和“exited on signal 7”
- 最终定位到某个上传图片接口的PHP脚本会耗尽分配给当前PHP-FPM子进程的内存
解决方案：
- 临时：停用那个插件，Apache立刻稳定运行
- 长期：在宝塔面板的PHP设置里，把“memory_limit”从256M调到512M，并在Apache配置里添加：
IPCCommTimeout 240 FcgidBusyTimeout 300 FcgidIOTimeout 300这三个参数让Apache对等待PHP处理请求的时间更宽容,避免因为超时强行杀掉进程。
预防建议：
- 日志轮转必须开：宝塔面板里“网站→设置→日志→日志切割”每天自动切割一次，保留7天即可，不要等日志堆到10G才手动删。
- 定期检查错误日志关键词：每个月用grep查一次error_log里的“Fatal”“Segfault”“out of memory”，很多问题都是先有警告后出大事故。
- 插件更新前先备份：尤其是涉及图片处理、文件上传、API请求的插件，出问题往往直接拖垮整个Apache进程池。
- 给PHP-FPM留余量：假设你的服务器有8G内存，PHP-FPM的max_children * memory_limit 别超过总内存的70%，否则一旦并发上来，内存就会拉满，然后系统OOM Killer直接杀PHP进程。
现在每次有客户说“网站打不开”，我都是先看宝塔面板里的Apache日志大小，超过2G直接怀疑日志相关问题，4年踩坑经验浓缩成一句话：Apache的问题，八成藏在PHP的错误日志里，剩下两成在系统日志里，宝塔面板的“错误日志”反而是最没用的。
发表评论