真实cpu占用看单核最大%cpu值及%us/%sy是否持续>70%，按1键显示各核负载，shift+p排序查非系统进程；%wa>30%说明是io瓶颈，需用iotop或pidstat -d诊断。
top 命令怎么看真实 CPU 占用，而不是被干扰的“假高负载”
Linux 的 top 默认显示的是所有 CPU 核心的累加占用率，比如 4 核机器跑满会显示 400%，新手常误以为“120% 就很危险”，其实只是单核超载 + 其他核空闲。关键不是看总和，而是看单个 %CPU 列的最大值，以及 %us（用户态）、%sy（内核态）是否持续高于 70%。
实操建议：
- 启动
top后按1显示各 CPU 核心独立负载，观察是否某核长期 95%+，其他核接近 0 —— 这说明是单线程瓶颈，不是整体资源不足 - 按
Shift + P按 CPU 使用率排序，重点关注COMMAND列里非系统进程（如php-fpm、node、mysqld） - 注意
top默认刷新间隔是 3 秒，对瞬时毛刺不敏感；可按s改为0.5或1秒，但别设太低，否则自身开销反成干扰 - 如果
%wa（I/O wait）持续 >30%，说明不是 CPU 瓶颈，而是磁盘或网络卡住了，该切到iotop查
iotop 为什么启动报错 “unable to reset ioctl” 或 “not found”
宝塔面板默认没装 iotop，且它依赖内核的 CONFIG_TASK_DELAY_ACCT 和 CONFIG_TASK_IO_ACCOUNTING 配置，CentOS 7+/Ubuntu 16.04+ 一般自带，但部分精简镜像或 OpenVZ 虚拟机可能缺失 —— 此时 iotop 会直接报 unable to reset ioctl 或根本找不到命令。
实操建议：
- 先确认是否安装：
yum install -y iotop（CentOS）或apt install -y iotop（Ubuntu/Debian） - 安装后仍报 ioctl 错：运行
uname -r查内核版本，再执行zcat /proc/config.gz | grep IO_ACCOUNTING（需有/proc/config.gz）；若无输出，说明内核不支持，只能换用pidstat -d 1替代 - 使用时加
-o参数只显示实际 I/O 的进程（过滤掉内核线程），加-P只看物理磁盘（排除缓存影响）：iotop -o -P - 注意
iotop默认以 KB/s 显示，但单位易被忽略；右上角的TOTAL DISK READ是累计值，要看下方每行的IO列瞬时速率
如何用 top + iotop 快速锁定“吃光 IO 又不写日志”的 PHP 进程
典型场景：网站响应慢、MySQL 慢查询不多、top 里 %wa 高但看不出哪个进程在读写 —— 很可能是 PHP 脚本用 fopen() 打开大文件没关、或 file_get_contents() 加载百 MB 配置，又或者 Laravel 的 storage/logs 权限错误导致反复重试写入失败。
实操建议：
- 先用
top看%wa是否 >40%，再按Shift + M按内存排序，找出 RSS 大的 PHP 进程（如php-fpm: pool www） - 记下 PID，立刻切到
iotop -p PID，观察其READ和WRITE是否持续 >10MB/s；如果是，再执行lsof -p PID | grep -E "\.(log|txt|csv|xml)$"查打开的大文件 - 常见坑：宝塔的 PHP 进程名统一为
php-fpm，得结合ps aux --forest看子进程树，或用cat /proc/PID/cmdline | tr '\0' '\n'看真实脚本路径 - 若发现某 PHP 进程在疯狂读
/tmp下的临时文件，大概率是上传未完成就中断，PHP 临时文件没清理 —— 查upload_tmp_dir配置，手动清空对应目录
宝塔环境下 top 数据不准？检查是否被面板自身进程干扰
宝塔面板的 bt 服务、监控插件、以及 Web 页面实时刷新的 AJAX 请求，本身就会触发定时 ps、df、netstat 调用，尤其在高并发时，这些后台采集任务会让 top 看起来“总有几个进程在抖动”。这不是你的业务问题，而是监控工具自扰。
实操建议：
- 临时停掉宝塔监控：执行
bt stop（非service bt stop），再开top观察 —— 若负载明显回落，说明是面板采集毛刺 - 检查
/www/server/panel/data/下的system.db是否过大（>50MB），过大会拖慢面板自身 SQL 查询，间接抬高%sy；可定期清理/www/server/panel/logs/旧日志 - 宝塔 8.x 后默认启用“进程守护”，会自动拉起崩溃的
php-fpm子进程，导致top里看到大量刚启动又消失的 PHP 进程 —— 这属于正常行为，不用干预，除非伴随restart_count持续上涨 - 真正要盯的是
top中持续存在、RSS >200MB 且%CPU>90% 的单一进程；短时抖动（
真实线上环境里，“高负载”往往不是某个大进程在作怪，而是几十个 PHP 请求同时卡在同一个慢 SQL 或 NFS 挂载点上 —— 这时候 top 和 iotop 只能告诉你“有事”，具体哪条 SQL、哪个挂载点，还得靠 mysqladmin proc 或 mount | grep nfs 往下挖。
