Чому у моїх файлових системах XFS раптом витрачається більше місця та повно файльних файлів?


62

Я майже 10 років використовую файлові системи XFS як розділи даних / зростання на різних серверах Linux.

Я помітив дивне явище на останніх серверах CentOS / RHEL, що працюють версії 6.2+.

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

До і після. Оновлення з 6.1 до 6.2 відбулось у суботу. xfs графік

Графік використання дисків минулого кварталу тієї ж системи, що показує коливання за останній тиждень. введіть тут опис зображення

Я почав перевіряти файлові системи на наявність великих файлів і безвідмовних процесів (файли журналів, можливо?). Я виявив, що мої найбільші файли повідомляють про різні значення від 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під час повільного періоду активності сприяв тимчасовому зменшенню використання диска (див. Середу на першому графіку вище). Однак використання повітряної кулі, як тільки відновилася важка активність системи.

Що тут відбувається?


2
Ммм ... Піаца ....
Том О'Коннор

Відповіді:


76

Я відніс цю проблему до дискусії про прихильність до дерева джерела XFS з грудня 2010 року. Патч був введений в Kernel 2.6.38 (і, очевидно, пізніше підтримується в деяких популярних ядрах дистрибуції Linux).

Помічені коливання використання диска є результатом нової функції; XFS Dynamic Speculative EOF Preallocation .

Це крок для зменшення фрагментації файлів під час потокового запису шляхом спекулятивного розподілу місця у міру збільшення розмірів файлів. Кількість попередньо виділеного простору на файл є динамічною і в першу чергу є функцією вільного простору, доступного у файловій системі (щоб не вичерпати місця повністю).

Випливає цей графік:

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)

Це цікаве доповнення до файлової системи, оскільки воно може допомогти з деякими масово фрагментованими файлами, з якими я маю справу.

Додатковий простір можна тимчасово повернути, звільнивши кеш сторінок, зубні сторони та вставки:

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%

4
Мільйон грошей і моє царство для вас
Джоель Е Салас

1
Дякую! Ми щойно перейшли з Debian Squeeze до Ubuntu і цікавились, чому du та ls демонструють такі диво різні значення для великі файли (наприклад, 50Mb vs 64Mb)
Giles Thomas

1
@ewwhite Ви вимкнули цю функцію, щоб повернути простір? Або ця стаття просто говорить, ей, саме ця особливість викликала розбіжність у розмірах, про які повідомлялося? Це звучить як "у системах баз даних, або тонко передбачених віртуальних машинах, подумайте про вимкнення цього", але я не впевнений, що ви вирішили зробити, зрештою.
JDS

2
@jds Я залишаю його. Це виключає фрагментацію і збільшує продуктивність для моїх програм.
ewwhite

3
О, чудова знахідка. Для цього було використано 750 Гб на 35 ГБ файлів. Після xfs_fsrповернення до приблизно 35 Гб. Мені доведеться стежити за цим
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.