应优先用终端命令（如top/htop）实时定位高CPU或内存占用进程，关注%CPU和RES值；PHP-FPM需设dynamic模式及合理pm.max_children；MySQL高负载先kill慢查询；Nginx 502需查错误日志并调优超时参数。
怎么看哪个进程在吃 CPU 或内存
宝塔面板里“系统监控”只给个总览，真要定位问题得进终端查实时进程。别依赖面板自带的“进程管理”，它常刷不及时，还可能漏掉短时爆发的异常进程。
推荐直接运行：top 或更直观的 htop（没装就先 yum install htop 或 apt install htop）。按 P 按 CPU 排序，M 按内存排序，一眼看出谁在狂占资源。
-
top -b -n 1 | head -20可快速截取当前前 20 行快照，适合远程脚本采集 - 注意看
%CPU和RES（实际物理内存占用），别只盯着VIRT（虚拟内存，意义不大） - 如果看到大量
php-fpm进程 RES 都超 200MB，大概率是某个 PHP 脚本内存泄漏或死循环
PHP-FPM 进程数暴增且响应慢怎么调
负载高经常是因为 PHP-FPM 子进程无节制拉起，把内存耗光后系统开始 swap，整个变卡。关键不是“加内存”，而是让 pm 策略匹配真实请求模型。
进宝塔 → 网站 → PHP 设置 → 配置文件，重点改三处：
-
pm = dynamic（别用static，除非你确定并发恒定且极低） -
pm.max_children = 32（根据内存算：假设每个 PHP 进程占 80MB，16GB 内存服务器最多撑 120 个，但留 30% 给系统和其他服务，设 32–64 更稳） -
pm.start_servers和pm.min/max_spare_servers按比例设，比如start_servers=8、min_spare_servers=4、max_spare_servers=16
改完必须重启 php-fpm（不是重载）：systemctl restart php-fpm-74（版本号按你实际填）。
MySQL 占满 CPU 怎么快速止血
不是所有 MySQL 高负载都要调参数，先砍掉最狠的慢查询。宝塔自带的“数据库”→“性能分析”只能看历史，紧急时得立刻进命令行抓活的。
连上 MySQL 后执行：SHOW PROCESSLIST;，重点关注 State 是 Sending data、Copying to tmp table 或长时间 Locked 的行。记下 ID，用 KILL [ID] 干掉。
- 临时禁用全表扫描：在 my.cnf 的
[mysqld]下加sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"（避免隐式类型转换导致索引失效） - 检查慢日志是否开启：
slow_query_log = ON+long_query_time = 1，否则你永远不知道哪条 SQL 在拖后腿 - 别盲目调
innodb_buffer_pool_size，设超过物理内存 70% 反而触发频繁 swap
Nginx 请求堆积却显示 502 怎么确认是 upstream 超时
502 不等于 PHP 挂了，很可能是 Nginx 等不及 upstream 响应直接断开。宝塔默认的 fastcgi_read_timeout 是 300 秒，但很多业务根本扛不住这么久排队。
查 Nginx 错误日志最准：tail -f /www/wwwlogs/nginx_error.log，搜关键词 "upstream timed out" 或 "no live upstreams"。
- 确认超时位置：是
fastcgi_connect_timeout（连 PHP-FPM 太慢）、fastcgi_send_timeout（发数据给 PHP 慢），还是fastcgi_read_timeout（等 PHP 返回慢） - 线上业务建议统一设为
60，而不是默认 300；配合 PHP 的max_execution_time = 60对齐 - 如果日志里反复出现
"upstream prematurely closed connection"，大概率是 PHP-FPM 进程被 OOM killer 杀了，回去看第一部分的内存排查
负载这事，没有一劳永逸的配置。每次调参后盯 10 分钟 top 和 nginx_error.log，比背十遍文档管用。最常被跳过的，是查 dmesg | grep -i "killed process" —— 那才是内存真正见底的铁证。
