Вопрос: Почему мои файловые системы XFS неожиданно потребляют больше места и заполнены разреженными файлами?


Я бежал Файловые системы XFS как разделы данных / роста на протяжении почти 10 лет на разных серверах Linux.

Я заметил странное явление с недавними серверами CentOS / RHEL с версией 6.2+.

Стабильное использование файловой системы сильно изменилось после перехода на новую версию ОС от EL6.0 и EL6.1. Системы, первоначально установленные с EL6.2 +, демонстрируют одинаковое поведение; показывающие дикие колебания в использовании диска на разделах XFS (см. синий line на графике ниже).

До и после. Обновление с 6.1 до 6.2 произошло в субботу. xfs graph

График использования диска прошлой четверти той же системы, показывающий колебания за последнюю неделю. enter image description here

Я начал проверять файловые системы для больших файлов и процессов runaway (файлы журналов, может быть?). Я обнаружил, что мои самые большие файлы сообщали разные значения из du а также ls, Бег du с и без --apparent-size переключатель иллюстрирует разницу.

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

Быстрая проверка с использованием Утилита ncdu по всей файловой системе:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

Файловая система полна редкие файлы, с почти 70 ГБ потерянного пространства по сравнению с предыдущей версией ОС / ядра!

Я просмотрел Red Hat Bugzilla и журналы изменений, чтобы увидеть, есть ли какие-либо сообщения о том же поведении или новые объявления о XFS.

Нада.

Я пошел из версии ядра 2.6.32-131.17.1.el6 в 2.6.32-220.23.1.el6 во время обновления; никаких изменений в номере второстепенной версии.

Я проверил фрагментацию файла с помощью filefrag инструмент. Некоторые из самых больших файлов в разделе XFS имели тысячи экстентов. Выполнение онлайн-дефрагментации с помощью xfs_fsr -v в течение медленного периода активности помогли временно сократить использование диска (см. среду на первом графике выше). Однако использование возобновилось, как только активная активность системы возобновилась.

Что здесь происходит?


58
2017-07-09 15:27


Источник


Ммм ... Пьяцца .... - Tom O'Connor


Ответы:


Я проследил этот вопрос до обсуждения вопроса о фиксации Дерево исходных текстов XFS с декабря 2010 года. Патч был введен в Kernel 2.6.38 (и, очевидно, позже был включен в некоторые популярные Linux-дистрибутивы).

Наблюдаемые колебания использования диска являются результатом новой функции; XFS Динамическое спекулятивное предварительное распределение EOF,

Это шаг к уменьшению фрагментации файлов во время потоковой записи путем спекулятивного выделения пространства по мере увеличения размеров файлов. Объем пространства, выделенного для каждого файла, является динамическим и в первую очередь зависит от свободного места, доступного в файловой системе (чтобы исключить исчерпание пробела целиком).

Он следует этому графику:

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

Это интересное дополнение к файловой системе, поскольку это может помочь с некоторыми из сильно фрагментированных файлов, с которыми я сталкиваюсь.

Дополнительное пространство можно временно освободить, освободив pagecache, dentries и inodes с помощью:

sync; echo 3 > /proc/sys/vm/drop_caches

Эта функция может быть полностью отключена путем определения allocsize значение во время монтирования файловой системы. Значение по умолчанию для XFS allocsize=64k,

Влияние этих изменений, вероятно, будет ощущаться системами мониторинга / порогового значения (как я его поймал), но также затронул системы баз данных и может привести к непредсказуемым или нежелательным результатам для тонких резервных виртуальных машин и массивов хранения (они будут использовать больше места, чем вы ожидаете).

В целом, это застало меня врасплох, потому что не было явного объявления о смене файловой системы на уровне распространения или даже при мониторинге Список рассылки XFS,


редактировать:
Производительность на томах XFS с этой функцией значительно улучшена. Я вижу согласованную фрагментацию <1% на томах, которая ранее отображалась до 50% фрагментации. Производительность записи повышается во всем мире!

Статистика из одного набора данных, сравнивая устаревшую XFS с версией в EL6.3.

Старый:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

Новое:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%

71
2017-07-09 15:27



Миллион оборотов и мое королевство для вас - Joel E Salas
Спасибо! Мы только что перешли от Debian Squeeze к Ubuntu и задавались вопросом, почему du и ls демонстрируют такие дико различающиеся значения для довольно больших файлов (например, 50Mb против 64Mb) - Giles Thomas
@ewwhite Вы отключили эту функцию, чтобы вернуть пространство? Или эта статья просто говорит, эй, эта особенность - это то, что вызывает несоответствие в размерах, сообщаемых? Это звучит так: «на системах баз данных или в тонких резервных виртуальных машинах, подумайте об отключении», но я не уверен, что вы решили сделать в конечном итоге. - JDS
@jds Я оставляю его. Он устраняет фрагментацию и повышает производительность моих приложений. - ewwhite
О, прекрасная находка. Это использовало 750 ГБ на 35 ГБ файлов. После xfs_fsr он возвращается примерно до 35 ГБ. Я должен буду следить за этим