При выполнении «tar» в каталоге с более чем миллиардом файлов процесс оставался в статусе D

Question

При выполнении «tar» в каталоге с более чем миллиардом файлов процесс оставался в статусе D

Я делал несколько экспериментов, чтобы узнать больше о состояниях процессов Linux.

Итак, есть каталог (с именем big_dir) с более чем миллиардом файлов в нем (каталог имеет много подкаталогов рекурсивно), а затем я запускаю tar -cv big_dir | ssh anotherServer «tar -xv -C big_dir» и узнал, выполнив top , что процесс tar остается в статусе D. Между тем, команда tar продолжает выводить пути к файлам.

Я знаю, что процесс был в статусе D, потому что он делал дисковый ввод-вывод, но почему его статус не переключился между D и R? Печать имен файлов в каталоге должна была использовать некоторое вычисление ЦП, не так ли? В противном случае, как команда find могла знать, что она должна что-то печатать?

Если я запустил dd if =/dev/zero of =/dev/null , то статус процесса dd сохранен в статусе R из top вывод. Но почему это не было в статусе D? Разве это не все время делает I/O?

1

добавлено 28 Декабрь 2012 в 11:19 автор zzhang отредактировано 28 Декабрь 2012 в 11:26

Просмотры: 4

источник

nl ja de

2 ответы

/dev/zero and /dev/null are pseudo-devices. So there's no physical device behind them.

Если я сделаю

dd if=/dev/zero of=/tmp/zeroes

то top показывает мне dd в статусе D . Однако он тратит много времени на R (в процессорное время). top будет просто отображать таблицу процессов, и, следовательно, вам может потребоваться некоторое время посмотреть ее, чтобы увидеть переходные состояния.

Я подозреваю, что для вашего примера tar выше, что время вывода на stdout незначительно по сравнению с временем на диске. Обратите также внимание на то, что вывод в stdout также будет включать в себя запись в систему окон, а в то время как процесс будет спать. например Сейчас я запускаю yes , и большая часть работы выполняется моим X-сервером. Процесс yes спал большую часть времени, когда я смотрю его (через top )

3

добавлено 28 Декабрь 2012 в 11:27 автор Brian Agnew

источник

В самом деле. Позже я проверил статус процесса в/proc и увидел «Состояние: D (спящий диск) SleepAVG: 78%».

добавлено 29 Декабрь 2012 в 08:46, автор zzhang, источник

Видеокурс по Java для начинающих

Получи видеокурс по Java для начинающих с упражнениями

автор Mats Petersson · Answer 1 · 2012-12-28T11:31Z

Я уверен, что ваш tar-процесс SOMETIMES отправляется в R, но это, вероятно, очень короткий период времени, потому что это не так много - особенно, поскольку вы отправляете данные через сеть. Если это не сетевая карта 10 Гбит/с [и все остальное на «anotherServer» действительно работает на 1 ГБ/с], это будет самая медленная часть цепочки. Сам ssh потребует немного накладных расходов, поскольку он шифрует данные.

Вероятно, понадобится несколько минут, чтобы запросить некоторые данные с диска, и несколько миллисекунд для диска, чтобы переместить его голову и прочитать фактические данные. Таким образом, у вас около 0,1% времени в «R», остальное - в «D».