Производительность ZFS: нужно ли оставлять свободное место в пуле или файловой системе?
Я знаю, что производительность ZFS сильно зависит от количества свободного места:
Сохраняйте пространство пула под 80%, чтобы поддерживать производительность пула. В настоящее время производительность пула может ухудшиться, когда пул очень заполнен, а файловые системы часто обновляются, например, на занятом почтовом сервере. Полный пул может привести к снижению производительности, но никаких других проблем. [...] Имейте в виду, что даже при статичном содержании в диапазоне 95-96% производительность записи, чтения и переноса может ухудшиться. ZFS_Best_Practices_Guide, solarisinternals.com
Теперь предположим, что у меня есть пул raidz2 10T с файловой системой ZFS volume, Теперь я создаю дочернюю файловую систему volume/test и дайте ему оговорку 5T.
Затем я монтирую обе файловые системы по NFS на некоторый хост и выполняю некоторую работу. Я понимаю, что не могу написать volume более 5 т, потому что остальные 5 т зарезервированы для volume/test,
Мой первый вопрос: как снизится производительность, если я заполню свой volume точка монтирования с ~5T? Он упадет, потому что в этой файловой системе нет свободного места для копирования ZFS и других мета-материалов? Или он останется прежним, поскольку ZFS может использовать свободное пространство в пределах пространства, зарезервированного для volume/test?
Теперь второй вопрос. Имеет ли это значение, если я изменю настройки следующим образом? volume теперь имеет две файловые системы, volume/test1 а также volume/test2, Оба получают 3T резервирование каждый (но без квот). Предположим теперь, я пишу 7T в test1, Будет ли производительность для обеих файловых систем одинаковой или будет разной для каждой файловой системы? Он упадет или останется прежним?
Спасибо!
2 ответа
Да. Вы должны оставить свободное место в вашем бассейне. Это в основном для действий копирования и записи и снимков. Производительность снижается примерно на 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 ГБ памяти 2, но вы сможете использовать его до 95% без особых проблем.
1 это немного сложнее, если вам интересно, посмотрите на пост Бонвика на космических картах для деталей
2 если вам нужен способ вычисления верхнего предела для памяти, используйте 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, хотя я полагаю, что он допустил некоторые ошибки в своих расчетах, которые, я надеюсь, исправил в моей.