您好！针对您遇到的低负载Rocky Linux服务器突然爆资源、触发OOM的问题，我整理了几个实用的排查方向，帮您一步步定位根源：

一、提前部署监控工具，抓准异常瞬间的进程数据 #

因为异常是突发的，事后再查很容易错过关键信息，建议先做好监控准备：

• 安装atop（比htop更适合长期回溯）：sudo dnf install atop，然后开启服务：sudo systemctl enable --now atop，它会自动按小时记录系统资源、进程的详细日志，异常发生后可以用atop -r /var/log/atop/atop_YYYYMMDD回溯对应时间段的情况
• 异常突发时，第一时间执行这两个命令，记录最占资源的进程：
  • 按内存排序：ps aux --sort=-%mem
  • 按CPU排序：ps aux --sort=-%cpu
    重点关注php-fpm子进程和MySQL线程的PID、对应的脚本/数据库操作

二、深挖MySQL层面的异常 #

日志显示MySQL占满内存，这大概率和低效查询或不合理配置有关：

• 开启慢查询日志：编辑Percona的配置文件（比如/etc/my.cnf或/etc/my.cnf.d/server.cnf），添加或修改：

  slow_query_log = 1
  long_query_time = 2
  slow_query_log_file = /var/log/mysql/slow.log
  

  重启MySQL后，异常发生后用mysqldumpslow /var/log/mysql/slow.log分析，看是否有全表扫描、大结果集的慢查询突然爆发
• 实时查看MySQL线程状态：执行mysql -e "SHOW FULL PROCESSLIST;"，排查是否有大量非Sleep状态的线程，或者正在执行耗时操作（比如ALTER TABLE、批量INSERT）的线程
• 检查内存配置合理性：4GB内存的服务器，innodb_buffer_pool_size建议设为1.5GB左右（不要超过物理内存的50%），避免和php-fpm抢占内存导致OOM；同时检查key_buffer_size、join_buffer_size等参数，不要设置过大

三、排查PHP-FPM的进程与脚本问题 #

多个WordPress站点的php-fpm进程数配置不当，或者插件/主题有内存泄漏，很容易触发突发资源占用：

• 调整php-fpm进程数：编辑/etc/php-fpm.d/www.conf，4GB内存的话，建议设置：

  pm.max_children = 12
  pm.start_servers = 4
  pm.min_spare_servers = 2
  pm.max_spare_servers = 6
  

  每个php-fpm子进程大概占200-300MB内存，过多的进程会直接把内存撑爆
• 开启php-fpm慢日志：在php-fpm配置里添加：

  slowlog = /var/log/php-fpm/www-slow.log
  request_slowlog_timeout = 5s
  

  这样能抓到执行时间超过5秒的PHP脚本，大概率是WordPress插件（比如备份、统计类插件）或者爬虫触发的低效代码
• 检查WordPress站点：排查最近更新的插件、主题，有些插件可能存在内存泄漏，低流量时不明显，一旦有批量请求（比如搜索引擎爬虫、恶意扫描）就会爆发

四、系统日志与IO回溯 #

• 分析/var/log/messages，OOM Killer触发时会记录被杀死的进程，通过这个可以判断是php-fpm还是MySQL先触发内存耗尽，缩小排查范围
• 异常发生时用iostat -x 1 5查看磁盘IO细节，确认是MySQL的磁盘读写（比如大量日志写入、全表扫描）还是静态文件请求占满了IO
• 您提供的监控图清晰显示了资源突发飙升的情况：
  
  结合这个时间段的日志和进程记录，能更精准定位触发事件

五、临时缓解与长期预防 #

• 临时调整swap策略：执行sudo sysctl vm.swappiness=10，并写入/etc/sysctl.conf永久生效，减少系统对swap的依赖，避免IO阻塞加剧
• 设置内存上限：在php.ini中设置memory_limit = 256M，限制单个PHP脚本的内存使用；MySQL通过配置参数限制整体内存占用
• 配置自动恢复：用monit或者systemd服务单元，设置当CPU/内存超过阈值时自动重启php-fpm或MySQL，避免服务器完全锁死

备注：内容来源于stack exchange，提问作者Erus