Я столкнулся с этой чрезвычайно странной проблемой на двух серверах, оба под управлением CentOS5, оба - ext4. Один из них - SSD, другой - обычный жесткий диск, оба SATA без RAID.
Проблема заключается в следующем: когда я запускаю rm -r в каталоге с большим количеством подкаталогов (> 1000), где каждый подкаталог имеет большое количество файлов (> 1000), диск, на котором находятся эти каталоги, периодически блокируется.
Это видно через верх. Обычно команда rm будет загружать ЦП примерно на 50-60%, но внезапно она упадет до нуля на 10-15 секунд, а затем вернется к 50-60% в течение 3-4 секунд, прежде чем снова упадет до нуля. Пока команда rm находится на 0% cpu, даже простые команды, такие как ls на рассматриваемом диске, будут зависать, и на экране ничего не отображается, пока rm снова не будет работать на 50-60%.
Когда rm работает на 0%, в верхней части я также получаю 0,0% wa.
Как вы понимаете, это постоянное зависание диска делает обработку очень медленной. Я не решаюсь винить в этом плохой диск, потому что теперь я видел такое поведение в двух разных системах.
У кого-нибудь есть идеи?
РЕДАКТИРОВАТЬ: Также хочу отметить, что когда rm работает на 0,0% процессора, jbd2 / sdc1-8 все еще активен на рассматриваемом диске.
Не решение, а обходной путь: вы можете запустить rm с ionice -c3. Если вы можете воспроизвести эту проблему, вы можете отследить ее с помощью strace -tt -o rm.strace rm ... и свяжитесь с разработчиками ext4.
Удаление миллионов файлов приводит к миллионам транзакций. Это быстро заполнит журнал. Вы видите киоски, вызванные смывом журнала.
Использование журнала большего размера должно позволить объединить больше транзакций перед промывкой, поэтому вы увидите меньше таких киосков.
Размер журнала по умолчанию обычно составляет 128 МБ. Ты можешь использовать tune2fs -J size=512 на чисто размонтированной FS, чтобы в четыре раза увеличить размер журнала
Во-первых,
В файловой системе ssd вы захотите включить игнорировать вариант. например
# mount -t ext4 -o discard /dev/ssd_dev /mnt/storage/location
Вы можете прочитать об этом здесь (RedHat SSD Tuning)
Наконец, вы можете проверить размеры блоков, поскольку размеры жестких дисков и твердотельных накопителей могут отличаться. Но если вы не хотите переустанавливать систему, я думаю, что перемонтирование с опцией disgard должно помочь.
Обновлено: медленный rm можно отнести к барьеру записи файловой системы, как описано Вот
Привет, Дэни
Я обнаружил, что при использовании рекурсивной опции для удаления большого количества файлов лучше всего написать простой сценарий bash, используя цикл for для удаления файлов по отдельности. Что-то похожее:
for f in /path/to/dir/*
do
# if file, delete it
[ -f "$f" ] && rm "$f"
done