Linux временно думает, что диск заполнен

359
TTT

Я работаю на сервере Linux с CentOS 6.5 и NFS NAS в сети QDR Infiniband. Я запускаю bashскрипт, который в основном создает каталог, создает внутри него символические ссылки и catобъединяет один маленький файл в каждый каталог. Это делается для нескольких сотен каталогов.

В выходном журнале я заметил, что одна из символических ссылок и последующие catне удалось запустить, утверждая, что диск заполнен. Это было совершенно ясно, нет. Запустив этот же скрипт для нескольких тысяч каталогов, я начал получать очень большое количество этих сообщений. Я проверил, и диск выглядел переполненным, поэтому я немедленно убил свой сценарий, но затем через несколько минут диск вернулся в нормальное состояние.

Вот последовательные dfкоманды, которые я видел: первая, во время работы скрипта, вторая сразу после его уничтожения, а третья несколько секунд спустя /home3(NAS) - это та, над которой я работаю:

[swfl 07:40:56 JPM]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_misisss6-lv_root 135G 25G 104G 19% / tmpfs 12G 0 12G 0% /dev/shm /dev/sda1 485M 69M 392M 15% /boot misisss-nasib3:/home 26T 26T 1.0M 100% /home3 misisss-nas1:/shared 77G 437M 73G 1% /shared misisss-nasib2:/home 15T 15T 95G 100% /home2 You have new mail in /var/spool/mail/swfl  [swfl 07:41:39 JPM]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_misisss6-lv_root 135G 25G 104G 19% / tmpfs 12G 0 12G 0% /dev/shm /dev/sda1 485M 69M 392M 15% /boot misisss-nasib3:/home 26T 26T 1.0M 100% /home3 misisss-nas1:/shared 77G 437M 73G 1% /shared misisss-nasib2:/home 15T 15T 94G 100% /home2  [swfl 07:41:58 JPM]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_misisss6-lv_root 135G 25G 104G 19% / tmpfs 12G 0 12G 0% /dev/shm /dev/sda1 485M 69M 392M 15% /boot misisss-nasib3:/home 26T 21T 4.2T 84% /home3 misisss-nas1:/shared 77G 437M 73G 1% /shared misisss-nasib2:/home 15T 15T 93G 100% /home2 

В то время загрузка большинства ядер была относительно небольшой, а использование дисков от низкого до умеренного. У меня не запущено программное обеспечение для мониторинга, поэтому я не могу дать цифры IOps или что-то в этом роде, но я проделал работу, похожую на эту, но с гораздо более высокой интенсивностью без проблем.

Короче говоря, было бы очень трудно поверить, что я подавлял какую-то часть системы выполняемой работой. Хлебные крошки, где искать проблемы?

ОБНОВЛЕНИЕ 1 Работая watch 'df -h; df -i'для отслеживания инодов и использования диска, я вижу резкое падение дискового пространства (все в порядке ~ 5 секунд, затем несколько ТБ исчезают в течение 10-20 секунд), пока я не начну получать ошибки, но в одес почти столько же.

Я могу видеть, что оды имеют довольно высокий коэффициент использования (30-70%). У меня ~ 16 миллиардов инодов, и я создаю ~ 40000 файлов / каталогов. После того, как я завершу процесс, дисковое пространство начнет медленно расти (несколько ГБ) в течение 10-20 секунд, а затем отскочит обратно на несколько ТБ до первоначального уровня.

0
Проверьте на исчерпание инода. Daniel B 9 лет назад 0

1 ответ на вопрос

1
TTT

Заметив, что дисковое пространство высвободилось за 5-минутный цикл, мы смогли выявить проблему. Такое поведение может быть уникальным для файловой системы, которую мы используем, для файловой системы XFS .

XFS позволяет указать заранее выделенный размер файла. Мы смонтировали файловую систему с помощью allocsize=1G, учитывая, что эта файловая система была построена с учетом больших файлов, и мы хотели избежать фрагментации. Вы также можете указать частоту обновления для файловой системы, чтобы затем возвращаться и пересматривать использование из предварительно распределенных значений. Значение по умолчанию 5 минут было тем, почему мы видели это циклическое поведение. Некоторая связанная информация об этом поведении может быть найдена здесь .

Итак, когда я создал файл, а затем выполнил catдля него, этого второго действия над файлом было достаточно, чтобы система инициировала предварительное выделение 1 ГБ для этого файла. Таким образом, зацикливание нескольких тысяч таких файлов на очень высокой скорости привело к тому, что все дисковое пространство оказалось исчерпанным, прежде чем модуль хранения смог отрегулировать эти выделения.

Мы удалили эту опцию монтирования, чтобы позволить файловой системе идти с динамическим предварительным размещением, что более разумно в отношении меньших файлов и доступной емкости файловой системы.