静态资源服务高并发下易因缓存未命中等引发磁盘i/o瓶颈；需通过iostat关注%util>70%、await超标、r/s与avgrq-sz异常、热点文件定位四大信号，并结合vmtouch预热、小文件合并、挂载参数优化及日志路径分离来缓解。
静态资源服务（如 Nginx 托管的图片、JS、CSS 文件）看似“只读”，但高并发下仍可能触发严重磁盘 I/O 压力——尤其当缓存未命中、文件碎片化、小文件密集读取或日志写入激增时。评估其 IO 压力不能只看“有没有写”，而要结合请求模式与磁盘响应行为。
关注核心指标：静态服务最敏感的 4 个信号
运行 iostat -dxm 1 5（每秒采样，MB 单位，5 次输出），重点盯住以下字段：
- %util > 70%：说明磁盘持续忙碌。静态服务若长期超 85%，基本确认磁盘已成瓶颈，不是 CPU 或网络问题
- await > 20ms（SSD）或 > 50ms（HDD）：平均响应延迟超标。哪怕 %util 只有 60%，await 却达 80ms，说明请求在队列中排队，用户会感知卡顿
- r/s 高 + avgrq-sz ：典型小文件读特征（如大量 1–4KB 的图标、字体、JSON）。IOPS 压力远大于吞吐压力，容易打满随机读能力
- rkB/s 接近磁盘理论带宽（如 SATA SSD 约 500MB/s）：说明吞吐见顶。此时即使 await 正常，也意味着无法承载更多大文件（如视频片段、压缩包）并发下载
区分真实压力与“伪高负载”
静态服务常见误判场景：
- 缓存命中率低导致的 r/s 虚高：检查 free -h 和 cat /proc/meminfo | grep -i "cached\|sreclaimable"。若 PageCache 占用极低，说明系统没缓存住热点文件，每次请求都落盘
- 日志刷盘干扰：Nginx access.log 默认每条请求写一次。观察 wkB/s 是否同步飙升。可临时关闭日志或改用 buffer+flush=1s 缓冲写入验证
- ext4 barrier 或 journal 开销：在虚拟机或云盘上，svctm 显著高于 await（反常）可能提示底层存储层存在额外同步开销，非本机磁盘问题
快速定位瓶颈来源：从设备到路径
仅靠 iostat 不知是哪个目录拖慢了服务。需组合验证：
- 用 iostat -dxm 1 | grep sda 锁定高 util 设备（如 sda、nvme0n1）
- 加 -p ALL 参数查看分区级指标（如 sda1 vs sda2），确认是否日志盘和数据盘混用
- 执行 sudo lsof +D /var/www/html | awk '$5~/REG/ {print $9}' | xargs stat -c "%n %s" 2>/dev/null | sort -k2nr | head -5，找出最大/最热文件，判断是否单点大文件反复读
- 对比 iotop -oP，看 nginx worker 进程的 IO_Wait% 是否与 %wa 高度吻合
针对性优化建议（不换硬件也能见效）
- 强制内核缓存热点：对静态目录启用 echo 1 > /proc/sys/vm/vfs_cache_pressure（降低 inode/dentry 回收倾向），并用 vmtouch -t /var/www/html 预热
- 合并小文件：将大量图标打包为 WebP 雪碧图，或使用 HTTP/2 Server Push 减少请求数量
- 调整文件系统挂载选项：在 /etc/fstab 中为数据盘添加 noatime,nobarrier,commit=60（仅限 SSD 且可接受秒级日志丢失风险）
- 分离 IO 路径：把 access.log 写到 tmpfs（内存盘），或用 rsyslog + imfile 异步批量落盘
