迁移WordPress至GCP E2 Medium后扫描时CPU占满崩溃求助

核心排查方向与解决步骤 #

1. 调整MySQL配置适配GCP实例内存 #

GCP E2 Medium（4GB内存）的默认MySQL配置大概率沿用小内存模板，未利用额外内存，导致扫描时大量磁盘IO拖垮CPU：

• 用mysqltuner工具自动分析配置瓶颈，执行：

  mysqltuner
  

• 手动编辑/etc/mysql/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，调整关键缓存参数：

  innodb_buffer_pool_size = 2G  # 设为物理内存的50%-70%
  key_buffer_size = 256M
  query_cache_size = 64M
  

• 重启MySQL生效：systemctl restart mysql

2. 定位并优化慢查询 #

Screaming Frog爬取会触发大量数据库请求，迁移后可能存在索引丢失或低效查询：

• 开启慢查询日志，在MySQL配置文件中添加：

  slow_query_log = 1
  slow_query_log_file = /var/log/mysql/slow_query.log
  long_query_time = 1  # 记录1秒以上的查询
  

• 爬取几分钟后，用mysqldumpslow /var/log/mysql/slow_query.log分析高频慢查询，针对性添加索引或修改插件逻辑。
• 检查wp_options表的autoload数据，清理无效项：

  SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 20;
  

3. 降低Screaming Frog爬取压力 #

过高的并发爬取会瞬间耗尽MySQL连接资源：

• 打开Screaming Frog，进入Settings > Crawl Limits：
  • 将Maximum Threads从默认50降至10-20
  • 设置Delay为100-200ms，分散请求压力

4. 检查GCP磁盘IO性能 #

E2实例默认标准磁盘IO性能有限，可能成为瓶颈：

• 用iostat -x 1 5查看磁盘使用率（%util），若持续接近100%，升级为SSD持久磁盘。
• 临时调整MySQL参数牺牲少量安全性换性能：

  innodb_flush_log_at_trx_commit = 2
  

5. 确认MySQL资源限制 #

系统级别的资源限制可能导致MySQL无法正常处理高负载：

• 检查文件描述符限制：

  ulimit -n  # 确保不低于65535
  

• 在/etc/security/limits.conf中添加：

  mysql soft nofile 65535
  mysql hard nofile 65535
  

• 重启MySQL和系统生效。

内容的提问来源于stack exchange，提问作者Isaac Adams-Hands