Продуктивність ZFS: чи потрібно зберігати вільний простір у пулі чи файловій системі?

Я знаю, що продуктивність ZFS сильно залежить від кількості вільного місця:

Тримайте простір у басейні до 80%, щоб підтримувати продуктивність басейну. В даний час продуктивність пулу може погіршитися, коли пул дуже заповнений і файлові системи часто оновлюються, наприклад, на зайнятому поштовому сервері. Повний пул може спричинити покарання за ефективність, але жодних інших проблем. [...] Майте на увазі, що навіть при вмісті в основному статичного вмісту в діапазоні 95-96% ефективність запису, читання та повторного перенесення може постраждати. ZFS_Best_Practices_Guide, solarisinternals.com (archive.org)

Тепер, припустимо, у мене є пул raidz2 10T, який розміщує файлову систему ZFS volume. Тепер я створюю дочірню файлову систему volume/testі надаю їй застереження 5T.

Потім я монтую обидві файлові системи в NFS до якогось хоста і виконую деяку роботу. Я розумію, що я не можу писати volumeбільше ніж 5T, оскільки решта 5T зарезервована для volume/test.

Перше моє запитання - як знизиться продуктивність, якщо я заповнив свою volumeточку монтажу ~ 5T? Чи впаде він, бо у цій файловій системі немає вільного місця для копіювання на запис ZFS та інших мета-матеріалів? Або це залишиться тим самим, оскільки ZFS може використовувати вільний простір у просторі, відведеному для volume/test?

Тепер друге питання . Чи має значення це, якщо я змінити налаштування наступним чином? volumeтепер має дві файлові системи volume/test1та volume/test2. Обидві отримують 3T бронювання кожен (але квот немає). Припустимо, зараз я пишу на 7T test1. Чи буде продуктивність для обох файлових систем однаковою, чи буде різною для кожної файлової системи? Чи впаде, чи залишиться колишньою?

Спасибі!

Так. Потрібно зберегти вільний простір у вашому басейні. Це в основному для дій, що копіюються, і записів на знімку. Продуктивність знижується на рівні близько 85%. Ви можете піти вище, але є певний вплив.

Не возиться із застереженнями. Особливо з NFS. Це не обов'язково. Можливо, для zvol, але не для NFS.

Я не бачу розгубленості. Якщо у вас 10T, не використовуйте більше 85%. Розмістіть свої акції відповідно, використовуючи квоти, щоб обмежити їх використання. Або не використовуйте жодних квот і не стежте за загальним використанням басейну .

Погіршення продуктивності відбувається, коли ваш zpool або дуже заповнений, або дуже фрагментований. Причиною цього є механізм виявлення вільного блоку, застосований у ZFS. На відміну від інших файлових систем, таких як NTFS або ext3, не існує блокової растрової карти, яка показує, які блоки зайняті, а які безкоштовні. Натомість ZFS ділить ваш zvol на (як правило, 200) більші області, які називаються "металабораторіями", і зберігає AVL-дерева ¹ вільної блокової інформації (космічна карта) у кожному метаслабі. Збалансоване дерево AVL дозволяє ефективно шукати блок, що відповідає розміру запиту.

Хоча цей механізм був обраний з міркувань масштабу, на жаль, він також виявився головним болем, коли виникає високий рівень фрагментації та / або використання простору. Як тільки всі металабораторії несуть значну кількість даних, ви отримуєте велику кількість невеликих площ вільних блоків на відміну від невеликої кількості великих площ, коли пул порожній. Якщо ZFS тоді потрібно виділити 2 Мб простору, він починає зчитувати та оцінювати всі космічні карти метаслаб, щоб або знайти відповідний блок, або спосіб розбити 2 Мб на більш дрібні блоки. Це, звичайно, потребує певного часу. Гірше те, що це коштуватиме багато операцій вводу / виводу, оскільки ZFS дійсно зчитує всі космічні карти з фізичних дисків . Для будь-якого з ваших записів.

Падіння продуктивності може бути значним. Якщо ви любите гарні фотографії, погляньте на публікацію в блозі на Delphix, яка має кілька номерів, знятих із (спрощеного, але все-таки дійсного) пулу zfs. Я безсоромно краду один із графіків - дивіться на сині, червоні, жовті та зелені лінії на цьому графіку, які (відповідно) представляють пули на 10%, 50%, 75% та 93%, ємність проти пропускної здатності запису в КБ / с при цьому стає фрагментарним:

Швидким та брудним виправленням цього традиційно був режим налагодження металабораторії (просто видайтеecho metaslab_debug/W1 | mdb -kw під час виконання, щоб миттєво змінити налаштування). У цьому випадку всі космічні карти зберігатимуться в оперативній пам'яті ОС, знімаючи вимогу щодо надмірного і дорогого вводу / виводу при кожній операції запису. Зрештою, це також означає, що вам потрібно більше пам'яті, особливо для великих басейнів, тому це свого роду оперативна пам’ять для зберігання коней. Ваш 10 ТБ пул, ймовірно, обійдеться вам у 2-4 Гб пам'яті ² , але ви зможете довести його до 95% використання без особливих клопотів.

¹ це трохи складніше, якщо вам цікаво, подивіться дописи Бонвіка на космічних картах для деталей

² якщо вам потрібен спосіб обчислити верхню межу пам’яті, використовуйте zdb -mm <pool>для отримання кількості segmentsпоточних даних, що використовуються в кожному метаслабі, розділіть їх на два, щоб моделювати найгірший сценарій (за кожним зайнятим сегментом буде слідувати вільний ), помножте його на розмір запису для вузла AVL (два вказівника пам'яті та значення, враховуючи 128-бітну природу zfs та 64-бітну адресацію, становитиме 32 байти, хоча, здається, люди зазвичай вважають 64 байти для деяких причина).

zdb -mm tank | awk '/segments/ {s+=$2}END {s*=32/2; printf("Space map size sum = %d\n",s)}'

Довідка: основний контур міститься в цій публікації Маркуса Коверо в списку розсилки zfs-обговорення , хоча, я вважаю, він допустив деякі помилки в своєму розрахунку, які, я сподіваюся, виправив у моєму.