Apache2 Droplet启动后CPU占满100%，Magento2网站异常缓慢求助

嘿，你这情况我之前也碰到过类似的——宕机恢复后老系统突然掉链子，Apache直接把CPU拉满，用htop扫了一圈还摸不着头绪，确实闹心。结合你说的细节，我给你整理几个针对性的排查方向，一步步来：

1. 先揪出Apache CPU占用的“元凶”进程 #

htop看整体可能不够细，试试这几个命令精准定位：

• 跑top -b -n 1 -c，能看到每个进程的完整命令行，找到CPU占比最高的Apache子进程，看看它对应的请求URL是什么——说不定是某个Magento的接口或者页面在疯狂触发请求
• 如果你的Apache开了server-status模块，直接用apache2ctl status命令行查看，能实时看到当前的连接数、请求队列、正在处理的请求，这一步往往能直接锁定问题请求

2. 先把Magento 2的基础状态拉回正轨 #

宕机最容易搞乱Magento的缓存和索引，先把这俩基础项理清楚：

• 强制刷新所有缓存：bin/magento cache:flush && bin/magento cache:clean，宕机可能导致缓存文件损坏，清完缓存大概率能缓解一部分慢的问题
• 检查索引状态：bin/magento indexer:status，要是有索引标着Reindex required，赶紧跑bin/magento indexer:reindex——未更新的索引绝对是页面加载慢的重灾区
• 查数据库有没有“堵点”：登录MySQL执行SHOW PROCESSLIST;，看看有没有长时间挂着的查询（比如锁表、慢查询），宕机可能导致事务没提交或者表损坏，这会拖垮整个Magento的读写

3. 解析你拿到的Apache日志片段 #

你给出的那段日志[Wed May 02 07:21:21.415818 2018] [mpm_prefork:notice] [pid 3208] AH00169: ca...，是mpm_prefork模块的通知日志，完整内容一般是关于子进程启动/关闭的信息，比如AH00169: caught SIGTERM, shutting down（重启）或者AH00163: Apache/2.4.x configured -- resuming normal operations（启动完成）。如果是宕机后的启动日志，大概率只是记录重启过程，但如果日志里有大量子进程频繁创建销毁的信息，那可能是mpm_prefork的配置不合理（比如MaxRequestWorkers设得太高，导致进程频繁波动占CPU）。

建议你去完整的Apache错误日志（通常在/var/log/apache2/error.log）里找这段日志的完整内容，看看具体提示的是什么。

4. 排查系统层面的资源瓶颈 #

有时候问题不在应用层，而是系统资源扛不住：

• 内存：跑free -h看看内存使用，如果内存不足导致swap疯狂读写，整个系统都会变慢，CPU也会因为等待swap飙升
• 磁盘IO：用iostat -x 1 5查看磁盘的读写负载，如果%util接近100%，那可能是数据库读写或者日志写入把磁盘堵了
• 系统日志：翻/var/log/syslog或者/var/log/messages，看看宕机前后有没有硬件、系统层面的错误（比如磁盘故障、OOM Killer杀了进程）

5. 临时救急方案（如果需要快速恢复服务） #

要是CPU一直跑满导致服务没法用，可以先临时调整Apache的mpm_prefork配置救个急：

1. 打开/etc/apache2/mods-available/mpm_prefork.conf
2. 把MaxRequestWorkers临时调低（比如从250降到50），减少并发进程数
3. 重启Apache：systemctl restart apache2
   这能暂时压下CPU占用，但还是得找到根本原因彻底解决。

内容的提问来源于stack exchange，提问作者Axel Dekker