可用iotop监控Nginx worker进程IO，需以root运行并筛选活跃进程；高WRITE通常源于日志写入、proxy_cache落盘或静态文件服务配置不当，应结合配置与iostat综合判断。
直接用 iotop 监控 Nginx 进程的磁盘 IO 是可行的，但要注意：Nginx 本身不直接大量读写磁盘（静态文件由内核 page cache 缓冲，日志可异步），真正产生可观 IO 的往往是其子进程（如 worker 进程）或相关操作（如 access_log、error_log 写入，或 proxy_cache 磁盘缓存落盘）。关键不是“能不能看”，而是“怎么看准、看得清”。
确认 Nginx 进程已运行并获取 PID
先查主进程和 worker 进程 PID，因为 iotop 默认按线程/进程实时排序，Nginx 主进程（master）通常 IO 极低，真正干活的是 worker：
-
ps aux | grep nginx—— 查看所有 nginx 进程，注意nginx: worker process行 -
pgrep -f "nginx: worker"—— 快速列出所有 worker 进程 PID - 也可查配置：
grep "worker_processes" /etc/nginx/nginx.conf预估 worker 数量
以 root 权限运行 iotop 并聚焦 Nginx worker
iotop 需要 root 权限才能监控其他用户进程的 IO。启动后用交互命令快速定位：
-
sudo iotop—— 启动默认视图（按 IO 排序） - 按下 Shift+P 切换为按进程（而非线程）视图，避免被线程刷屏
- 按下 O（大写字母 O）只显示有 IO 活动的进程，减少干扰
- 按下 p 可切换显示/隐藏 idle 进程，让活跃 worker 更醒目
此时观察 IO>0 列，找到 PID 对应的 nginx: worker process 行，重点关注 READ 和 WRITE 速率（如 12.45 MB/s）及 IO% 占比。
结合 Nginx 配置判断 IO 来源
看到高 WRITE 并不意味 Nginx 有问题，需对照配置排查真实原因：
-
日志写入：检查
access_log /var/log/nginx/access.log是否开启；若使用buffer或gzip选项，会累积后批量写入，可能造成短时高 IO -
磁盘缓存：若启用
proxy_cache_path ... levels=1:2 keys_zone=mycache:10m use_temp_path=off;，且缓存未命中需回源并落盘，会触发大量 WRITE -
静态文件服务：若未启用
sendfile on;或tcp_nopush on;，小文件可能绕过零拷贝，经用户态缓冲写入，增加 IO 压力 -
错误日志级别：
error_log /var/log/nginx/error.log debug;在高并发下会产生海量日志，直接拖垮磁盘
辅助验证与持续观察技巧
单次快照易误判，建议组合使用：
- 用
sudo iotop -p $(pgrep -f "nginx: worker" | tr '\n' ',' | sed 's/,$//')—— 直接监控所有 worker 进程，PID 列表自动注入 - 加
-o参数只显示有 IO 的进程：sudo iotop -o -p $(pgrep -f "nginx: worker") - 配合
iostat -x 1查看设备级 IO（如sda的%util,await），确认是否真为磁盘瓶颈，而非网络或 CPU 限制 - 临时关闭 access_log（
access_log off;）并重载配置（nginx -s reload），观察 WRITE 是否显著下降，可快速定位日志是否主因
不复杂但容易忽略。
