Ubuntu 16.04 LTS - многократный или большой cp данных увеличивается, ожидая, пока системные блоки
Первоначально я обнаружил проблему, когда мне захотелось скопировать жесткий диск, а затем скопировать файл размером 100 ГБ. Между тем я много чего перепробовал и в основном вижу, что большое количество копий данных приводит к сбою системы. Следующий скрипт с некоторыми файлами в папке atemp1, суммирующими около 1 ГБ, используется, чтобы показать проблему:
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 поднимается до 99,7, пока не выйдет из строя. Пока это не происходит, ни в одном файле системного журнала нет указаний. Наконец, я использую программный рейд, ext4 и LVM. Жесткий диск составляет 4 ТБ каждый. LVM составляет 500 ГБ. Поскольку файлы удаляются, а затем копируются снова, я предполагаю, что всегда используется одна и та же часть жесткого диска и что это не дефектный сектор. - Само собой разумеется, что я уже сделал такие проверки. Кто-нибудь есть какие-либо подсказки по этому вопросу. Это проблема ядра?
2 ответа
IOWait - это показатель ЦП, измеряющий процент времени простоя ЦП, но ожидающий завершения ввода-вывода. Как ни странно - возможно иметь работоспособную систему с почти 100% -ным iowait или иметь узкое место на диске с 0% -ным iowait. Поскольку ваша система делает только повторяющиеся операции ввода-вывода с вашим сценарием, неудивительно, что вы приближаетесь к 100%. Само по себе это не ваша проблема. Поскольку в системном журнале нет никаких указаний, вам следует запустить memtest. См. 1 и 2, а затем проверить интеллектуальное состояние соответствующих дисков.
Вы также можете использовать некачественные данные или кабель питания, идущий к используемому накопителю.
Дополнительная литература: https://serverfault.com/questions/12679/can-anyone-explain-precisely-what-iowait-is
Через некоторое время тестирования я, наконец, заменил свою материнскую плату на 200++ евро (с процессором) на плату стоимостью <100 евро, и она работает без проблем. Как побочный эффект, платы Ethernet получают хорошие числа (enp1s0 и enp2s0) вместо ens3 и rename2 ранее. Само собой разумеется, что старая материнская плата иногда меняла названия плат Ethernet, что было катастрофой, которую я, однако, мог бы решить с помощью некоторых параметров для загрузки порта Ethernet. - Я не хочу раскрывать название материнской платы, но если у вас есть подобные проблемы, вы можете связаться со мной.