Недавно я установил Munin на веб-сервере разработки, чтобы отслеживать использование системы. Я заметил, что использование inode системы растет примерно на 7-8% в день, хотя использование диска почти не увеличилось. Я предполагаю, что что-то записывает кучу маленьких файлов, но я не могу найти что/куда.
Я знаю, как узнать использование дискового пространства, но не могу найти способ суммировать использование inode.
Есть ли хороший способ определить использование inode по каталогу, чтобы можно было найти источник использования?
решение1
Не ждите, что это произойдёт быстро...
cd в каталог, где, как вы подозреваете, может быть подкаталог с большим количеством inode. Если этот скрипт занимает много времени, вы, вероятно, нашли, где в файловой системе искать. /var — хорошее начало...
В противном случае, если вы перейдете в верхний каталог в этой файловой системе, запустите это и дождетесь завершения, вы найдете каталог со всеми инодами.
find . -type d |
while
read line
do
echo "$( find "$line" -maxdepth 1 | wc -l) $line"
done |
sort -rn | less
Я не беспокоюсь о стоимости сортировки. Я запустил тест, и сортировка неотсортированного вывода по 350 000 каталогам заняла 8 секунд. Первоначальный поиск занял . Реальная стоимость — это открытие всех этих каталогов в цикле while. (сам цикл занимает 22 секунды). (Тестовые данные запускались в подкаталоге с 350 000 каталогов, в одном из которых был миллион файлов, в остальных — от 1 до 15 каталогов).
Разные люди указывали, что ls не очень хорош в этом, потому что он сортирует вывод. Я пробовал echo, но это тоже не очень хорошо. Кто-то еще указывал, что stat дает эту информацию (количество записей каталога), но она непереносима. Оказывается, find -maxdepth очень быстро открывает каталоги и подсчитывает .files, так что... вот оно... всем по очкам!
решение2
Если проблема в одном каталоге со слишком большим количеством файлов, вот простое решение:
# Let's find which partition is out of inodes:
$ df -hi
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 2.4M 2.4M 0 100% /
...
# Okay, now we know the mount point with no free inodes,
# let's find a directory with too many files:
$ find / -xdev -size +100k -type d
Идея этой findстроки заключается в том, что размер каталога пропорционален количеству файлов непосредственно внутри этого каталога. Итак, здесь мы ищем каталоги с кучей файлов внутри.
Если вы не хотите угадывать число и предпочитаете перечислить все подозрительные каталоги, упорядоченные по «размеру», это тоже просто:
# Remove the "sort" command if you want incremental output
find / -xdev -size +10k -type d -printf '%s %p\n' | sort -n
решение3
Гррр, для комментирования требуется 50 репутаций. Так что этот ответ на самом деле является комментарием к ответу Криса.
Поскольку спрашивающему, вероятно, интересны не все каталоги, а только самые худшие, то использование сортировки, скорее всего, окажется очень дорогим излишеством.
find . -type d |
while
read line
do
echo "$(ls "$line" | wc -l) $line"
done |
perl -a -ne'next unless $F[0]>=$max; print; $max=$F[0]' | less
Эта версия не такая полная, как ваша, но она печатает строки, если они больше предыдущего максимума, что значительно снижает количество выводимого шума и экономит расходы на сортировку.
Недостатком этого является то, что если у вас есть два очень больших каталога и в первом из них на один инода больше, чем во втором, вы никогда не увидите второй.
Более полным решением было бы написать более умный скрипт perl, который отслеживает 10 лучших просмотренных значений и выводит их в конце. Но это слишком долго для быстрого ответа на serverfault.
Кроме того, некоторые среднеумные скрипты perl позволят вам пропустить цикл while - на большинстве платформ ls сортирует результаты, и это также может быть очень затратно для больших каталогов. Сортировка ls здесь не нужна, поскольку все, что нас волнует - это количество.
решение4
Это не прямой ответ на ваш вопрос, но поиск недавно измененных файлов небольшого размера с помощью find может сузить область поиска:
find / -mmin -10 -size -20k