记录一下那天晚上的排查过程。百度搜索资源平台的抓取频次 11 月 6 日从 3 档掉到 1 档，源站日志里百度蜘蛛的请求有 41% 返回 503，PHP-FPM 的进程池同时接近打满。
刚开始盯着「页面里调用的第三方接口没有超时设置，一次请求挂住十几秒」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。抓取高峰撞上数据库备份，MySQL 连接数被打满后接口超时。还有一种是PHP-FPM 的 pm.max_children 设得太小，排队请求被 Nginx 直接拒掉。
另外，object-cache 未命中时每次都回源查库，突发抓取直接把库压垮。
先统计百度蜘蛛按小时的响应码分布
awk '$9==503{print substr($4,14,2)}' access.log | sort | uniq -c然后查看 FPM 进程池的排队与拒绝次数
grep -E 'max children|pool' /var/log/php-fpm/error.log | tail -20再往下把备份任务挪出抓取高峰并限速
mysqldump --single-transaction --max-allowed-packet=64M db > /backup/db.sql调大进程池后观察 503 是否回落
systemctl reload php-fpm && curl -o /dev/null -s -w '%{http_code}\n' https://www.example.com/别只看报错消失，验证要多做一步。备份错峰并把进程池从 20 调到 40 后，百度蜘蛛的 503 比例降到 1% 以内，第三天抓取频次回到 3 档。
频次掉档是结果不是原因，先看返回码分布再谈恢复，光在平台里点申请恢复额度基本没有作用。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。