宝塔面板首页“系统负载过高”标红，说明load average持续高于cpu核心数，背后可能是cpu忙、磁盘i/o卡死、d状态进程堆积或php-fpm/mysql配置与实际流量不匹配；需优先用top、iostat、ps和iotop定位真实瓶颈，而非仅看cpu百分比。
负载状态变红说明什么
宝塔面板首页“系统负载过高”标红，不是CPU爆了100%，而是load average持续高于服务器CPU核心数。比如4核机器，1分钟load值长期>4.2，面板就会标红——这背后可能是CPU真忙、磁盘卡死、进程挂D状态，甚至只是PHP-FPM子进程配置和流量模型完全不匹配。
先查并发连接数是否失控
高并发下PHP-FPM子进程拉满、MySQL连接数打穿上限，是负载飙升最常见原因。别急着改pm.max_children，先确认是不是真有这么多活请求：
- 执行
ss -s看当前TCP连接总数，若>2000且ESTAB占比低，大概率是短连接风暴或连接未释放 - 进宝塔「软件管理」→「MySQL」→「配置修改」，检查
max_connections是否设为1000以上；但更关键的是看实时连接：mysql -e "show processlist;" | wc -l，超300就危险 - PHP-FPM方面，进对应PHP版本的「性能调整」页，重点看
最大空闲进程数和并发方案是否远高于实际QPS（比如QPS 50，却设了pm.max_spare_servers=100） - 改完必须
systemctl restart php-fpm-74（版本号按你实际填），reload不生效
慢查询日志必须开着，否则永远抓不到根因
90%的MySQL型负载问题，根源在没开慢查询日志，或者long_query_time设得太高。面板标红时，你根本不知道哪条SQL正在拖垮整个队列：
- 进MySQL配置文件（通常是
/www/server/mysql/my.cnf），确认以下几项已启用：slow_query_log = 1、slow_query_log_file = /var/log/mysql/slow.log、long_query_time = 1.0 - 特别注意：
log_queries_not_using_indexes = 1要阶段性开启——它能暴露缺失索引的高频查询，但会撑大日志体积 - 重启MySQL：
systemctl restart mysqld，然后等10分钟，再用tail -n 50 /var/log/mysql/slow.log看有没有新记录 - 别手动翻日志，直接跑：
pt-query-digest /var/log/mysql/slow.log --since "1 hour ago"，重点关注Rows_examined和Query_time两列
最容易被忽略的点：D状态进程和I/O等待
负载红了但%CPU只有30%，%wa却飙到70%以上？那基本可以确定是磁盘I/O卡死。这时候杀PHP进程、调MySQL参数全都没用：
- 执行
ps aux | awk '$8 ~ /D/ {print $0}'，列出所有不可中断睡眠进程——它们正卡在读写硬盘，kill -9无效，只能等或重启服务 - 装
iotop -o -P，盯住IO>列，如果某个php-fpm或mysqld持续写入>5MB/s，立刻查它对应的站点日志或慢SQL -
/www/wwwlogs/php_slow.log必须开着，request_slowlog_timeout = 0.5，否则0.8秒就干完的CPU尖峰根本留不下痕迹
