Я бегаю du -sh во множестве каталогов, чтобы найти дисковые "сучки". У меня есть два идентичных сервера (Dell PE2850s), оба с RHEL5, и для работы потребуется значительно больше времени. du на одном сервере поверх другого.
Например, делая du -sh /opt/foobar займет 5 минут на сервере A (на котором около 25 ГБ), а на сервере B та же команда с тем же объемом данных отправит мне ответ почти мгновенно. Я не вижу ничего бросающе очевидного при беге сверху и т. Д.
Любые советы высоко ценится.
Если у вас есть огромное количество файлов в этом каталоге и содержимое каталога постоянно меняется, сама запись в каталоге со временем фрагментируется. Затем, когда ОС читает содержимое каталога, будет много-много ненужных поисков диска. Это особенно характерно для файловых систем ext * (ext4 может быть лучше) и старых файловых систем ReiserFS v3.x (если они были заполнены на 85% или около того).
Решение довольно простое:
cp -pr origdir newdir
mv origdir origdir.bak
mv newdir origdir
Конечно, если все кэшируется в ОЗУ, это не имеет большого значения; обычно Linux довольно агрессивно кэширует часто используемые файлы и каталоги. Если вы действительно хотите сохранить содержимое этих каталогов в ОЗУ, вы можете поместить что-то вроде ls -lah /your/dir 2>&1 >/dev/null в ваш cron.
РЕДАКТИРОВАТЬ: О, одна вещь пришла мне в голову. Если на вашем сервере есть RAID-контроллер с резервным питанием от батареи и кеш-памятью, убедитесь, что батарея в порядке. Я видел ситуации, когда батарея разряжена, а контроллер полностью отключает кеш, что очень сильно снижает производительность. Например, серверы HP могут сообщать в журналах iLO что-то о батарее контроллера; на фактической панели мониторинга работоспособности сервера все в порядке и зеленое, но только запись в журнале расскажет вам об этом.
Предлагаю попробовать простую команду du без переключателей. В конце концов вы увидите, какой каталог замедляет процесс. Может быть неисправный диск или какая-то другая причина ...