Производительность 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. Это необязательно. Может быть для звола, но не для NFS.

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

Снижение производительности происходит, когда ваш zpool либо очень полон, либо сильно фрагментирован. Причиной этого является механизм обнаружения свободных блоков, используемый в ZFS. В отличие от других файловых систем, таких как NTFS или ext3, нет растровых изображений блоков, показывающих, какие блоки заняты, а какие свободны. Вместо этого ZFS делит ваш zvol на (обычно 200) большие области, называемые «метаслабами», и хранит AVL-деревья ^{1 информации} о свободных блоках (карта пространства) в каждом метаслабе. Сбалансированное дерево AVL обеспечивает эффективный поиск блока, соответствующего размеру запроса.

Хотя этот механизм был выбран из соображений масштаба, к сожалению, он также оказался основной болью, когда происходит высокий уровень фрагментации и / или использования пространства. Как только все метаслабы несут значительный объем данных, вы получаете большое количество небольших областей свободных блоков, а не небольшое количество больших областей, когда пул пуст. Если затем ZFS необходимо выделить 2 МБ пространства, он начинает читать и оценивать карты пространства всех метаслаб, чтобы найти подходящий блок или способ разбить 2 МБ на более мелкие блоки. Это, конечно, занимает некоторое время. Хуже всего то, что это будет стоить очень много операций ввода-вывода, поскольку ZFS действительно будет считывать все карты пространства с физических дисков . Для любого из ваших писем.

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

Быстрое и грязное решение этой проблемы традиционно заключалось в режиме отладки metaslab (просто выпустите 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-Discussion , хотя я полагаю, что он допустил некоторые ошибки в своих расчетах, которые, я надеюсь, исправил в моей.