评估磁盘利用率分布平衡性需关注i/o负载而非仅空间占用，应通过iostat -dx 2对比各盘r/s、w/s、rkb/s、wkb/s及%util指标是否均衡，%util持续＞80%即表明负载倾斜严重。

评估 Linux 存储系统的磁盘利用率分布平衡性，核心是看多个磁盘或逻辑卷之间是否存在明显负载倾斜——不是单看某块盘用了多少%，而是对比它们的 I/O 压力、吞吐量和响应延迟是否协同、均匀。单纯用 df -h 看空间占用百分比，容易误判：一块盘 90% 满但几乎不读写，另一块 40% 满却持续高 IOPS，后者才是真正瓶颈。

查实际 I/O 负载分布（非仅空间）

运行 iostat -dx 2 观察各设备的实时指标：

• r/s + w/s（每秒读/写次数）：对比各磁盘的 IOPS 是否接近；若 sda 的 r/s 是 sdb 的 5 倍，说明读请求严重集中
• rkB/s + wkB/s（每秒读/写 KB）：检查大块吞吐是否均衡，尤其对备份、日志归档类业务
• %util：连续多次采样中，若某盘 %util 长期 >80% 而其他盘
• await（平均等待毫秒）：若某盘 await 显著高于其余（如 25ms vs 2ms），即使 %util 不高，也说明该路径排队严重，可能是 RAID 控制器、多路径策略或 LVM 条带未生效

验证底层存储拓扑是否支持均衡

很多“不平衡”其实源于配置缺陷，而非应用本身：

宝塔Linux面板11.8.1

宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。

下载

• 用 lsblk 查结构：确认 LVM 逻辑卷是否跨多个 PV（物理卷），且每个 PV 对应不同物理磁盘；若所有 LV 都只建在 sda1 上，再怎么调应用也无济于事
• 查多路径状态：sudo multipath -ll 看是否所有路径 active，有无 failed 或 ghost 路径导致流量被锁死在单条链路上
• 检查 RAID 条带宽度与文件系统块大小匹配度：例如 RAID5 条带 64KB，但应用以 4K 随机写为主，易造成热点盘；此时需调整 mkfs 参数（如 XFS 的 -d su=64k,sw=8）对齐

结合应用行为定位倾斜根源

用 iotop -oP 和 lsof -p PID 锁定高 I/O 进程及其目标设备：

• 若 MySQL 的 ibdata1 和 binlog 全落在同一块盘上，而 redo log 在另一块——这属于人为配置失衡，应按功能分离挂载点
• 发现某个 rsync 进程持续往 /backup 目录写入，而该目录恰好挂载在唯一一块 HDD 上，SSD 盘空闲——这是任务调度未适配硬件层级
• 容器环境需额外检查：docker volume inspect 或 podman volume ls，确认卷是否绑定到预期的宿主机路径，避免多个容器共用一个低速本地卷

量化平衡性（简单可执行）

写一行命令快速计算标准差，辅助判断：

iostat -dx 1 3 | awk '/^sd/ {print $14}' | sort -n | awk '{a[NR]=$1; sum+=$1} END {avg=sum/NR; for(i=1;i
<p>输出 StdDev 若 >15（%util 单位），基本可判定分布离散度过高；</p>