最初,我在想将硬盘压缩成 tar 格式,然后复制一个 100 GB 的文件时,意识到了这个问题。与此同时,我尝试了很多方法,基本上发现大量数据复制会导致系统故障。以下脚本包含文件夹 atemp1 中的一些文件,总计约 1 GB,用于显示该问题:
while (true);
do
cnt=$(($cnt+1))
echo $cnt cp >> cnt.log
cp -dupR atemp1/* atemp2/
top -b -n 1 | head -n 5 >> cnt.log
echo $cnt rm >> cnt.log
rm atemp2/*
done
因此脚本什么都不做,只是一直复制相同的内容。查看日志文件的某些行,结果如下:
%Cpu(s): 3.9 us, 20.5 sy, 0.0 ni, 54.5 id, 20.0 wa, 0.0 hi, 0.6 si, 0.6 st
%Cpu(s): 3.3 us, 23.5 sy, 0.0 ni, 44.8 id, 27.0 wa, 0.0 hi, 0.5 si, 1.0 st
%Cpu(s): 2.2 us, 29.4 sy, 0.0 ni, 26.6 id, 40.0 wa, 0.0 hi, 0.3 si, 1.6 st
%Cpu(s): 2.0 us, 30.3 sy, 0.0 ni, 23.8 id, 42.0 wa, 0.0 hi, 0.3 si, 1.7 st
%Cpu(s): 1.9 us, 30.7 sy, 0.0 ni, 22.4 id, 43.0 wa, 0.0 hi, 0.2 si, 1.7 st
%Cpu(s): 1.8 us, 31.2 sy, 0.0 ni, 20.9 id, 44.0 wa, 0.0 hi, 0.2 si, 1.8 st
%Cpu(s): 1.3 us, 33.4 sy, 0.0 ni, 13.3 id, 50.0 wa, 0.0 hi, 0.2 si, 2.0 st
%Cpu(s): 1.0 us, 34.7 sy, 0.0 ni, 8.9 id, 53.0 wa, 0.0 hi, 0.1 si, 2.2 st
%Cpu(s): 1.0 us, 34.9 sy, 0.0 ni, 7.9 id, 54.0 wa, 0.0 hi, 0.1 si, 2.2 st
%Cpu(s): 0.9 us, 35.0 sy, 0.0 ni, 6.8 id, 55.0 wa, 0.0 hi, 0.1 si, 2.2 st
%Cpu(s): 0.9 us, 35.3 sy, 0.0 ni, 5.5 id, 56.0 wa, 0.0 hi, 0.1 si, 2.2 st
%Cpu(s): 0.7 us, 36.7 sy, 0.0 ni, 3.2 id, 57.0 wa, 0.0 hi, 0.1 si, 2.3 st
因此 wa 会持续上升,直到系统停止。实际上,在并行终端上观察 top 时,我看到 wa 上升到 99.7,直到它失败。发生这种情况时,任何系统日志文件中都没有任何迹象。最后,我正在使用软件 raid、ext4 和 LVM。每个 HDD 为 4 TB。LVM 为 500 GB。由于文件被删除然后再次复制,我假设始终使用相同的 HDD 部分,并且它不是缺陷扇区。- 不用说,我已经做过这样的检查。有人知道这个问题吗?这是内核问题吗?
答案1
IOWait 是一个 CPU 指标,用于测量 CPU 处于空闲状态但等待 I/O 完成的时间百分比。奇怪的是 - 系统可能处于接近 100% iowait 的状态,也可能出现磁盘瓶颈,iowait 为 0%。由于您的系统只使用脚本进行重复 I/O,因此看到 wa 接近 100% 并不奇怪。这本身不是您的问题。由于您没有在系统日志中收到任何指示,因此您应该运行 memtest 参见1和2进而检查智能有关驱动器的状态。
您可能还使用了有问题的数据线或电源线连接到正在使用的驱动器。
进一步阅读:https://serverfault.com/questions/12679/can-anyone-explain-precisely-what-iowait-is
答案2
经过一段时间的测试,我终于将 200 欧元以上的主板(带 CPU)换成了不到 100 欧元的主板,而且它运行正常。副作用是以太网板也获得了不错的数字(enp1s0 和 enp2s0),而不是之前的 ens3 和 rename2。不用说,旧主板有时会更改以太网板的名称,这是一场灾难,但我可以通过以太网端口启动的一些参数设置来解决这个问题。- 我不想透露主板名称,但如果您有类似的问题,可以联系我。