今天晚上我过得很糟糕。我不得不将 LVM2 LV 从一个 PV 移动到另一个 PV（源 PV 由 NFS 存储的 vdisk 支持，目标 PV 由 iscsi LUN 支持）。移动此 VG 的小型 LV（几 GB）很顺利，但我有一个 400GB 的 LV，过了一会儿，这使我的客户机达到 150 以上的负载平均值，以至于它卡住了，我不得不硬重启它。
我尝试在将内存和 CPU 大小增加一倍（16GB 和 4vcpu）后恢复 pvmove。负载几乎立即变得非常高。达到 5 分钟负载平均值中的 60，我决定终止 pvmove 进程（祈祷）。进程被正确终止，或者至少根据 ps 和 top 它不再位于进程表中，但负载不断增加。在我决定重新启动是我唯一的选择之前，负载已超过 90。虽然 pvmove 进程不再运行，但负载从未减少，CPU 几乎完全在等待 IO，如下所示（在我终止进程后大约 40 分钟，该进程最多运行了 5 分钟）。
top - 21:18:44 up 12:26, 1 user, load average: 93.07, 92.53, 89.07
Tasks: 405 total, 1 running, 402 sleeping, 2 stopped, 0 zombie
Cpu(s): 0.1%us, 0.1%sy, 0.0%ni, 0.0%id, 99.8%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16021672k total, 15363796k used, 657876k free, 427060k buffers
Swap: 2095100k total, 36k used, 2095064k free, 11856520k cached
我仍然打开了 ssh 终端，并且它有响应。对文件系统的操作似乎响应相当快（列出目录），但重新启动守护进程花费了非常长的时间，而且无法打开新的 ssh 连接。
有没有人可以解释这种行为，特别是为什么当进程不再存在时负载仍然会增加？
我怀疑我的 iscsi 启动器还不足以完成此类操作。但我迫切希望听到其他人在此类主题上的经验。PS：我发现过类似的问题，但在我看来并没有得到明确的回答：
https://serverfault.com/questions/268907/high-load-and-oom-killer-on-domus-while-pvmove#=
问候。
答案1
看到那个 ~99%wa 值了吗？这就是你的问题。你遇到了严重存储子系统中的资源争用。
您需要实施一些监控，以便您可以收集指标并确定瓶颈是在网络级别、物理磁盘级别还是其他地方。