Производительность ZFS: нужно ли оставлять свободное место в пуле или файловой системе?
Я знаю, что производительность ZFS сильно зависит от количества свободного места:
Используйте пространство пула менее 80% для поддержания производительности пула. В настоящее время производительность пула может снижаться, когда пул очень заполнен, а файловые системы часто обновляются, например, на загруженном почтовом сервере. Полные пулы могут привести к снижению производительности, но никаких других проблем. [...] Имейте в виду, что даже при в основном статическом содержимом в диапазоне 95-96% производительность записи, чтения и перенастройки может пострадать. ZFS_Best_Practices_Guide, solarisinternals.com (archive.org)
Теперь предположим, что у меня есть пул raidz2 из 10T, на котором размещена файловая система ZFS. volume. Теперь создаю дочернюю файловую систему volume/test и дайте ему оговорку в 5т.
Затем я монтирую обе файловые системы через NFS на какой-то хост и выполняю некоторую работу. Я понимаю что не могу писать volume более 5T, потому что оставшиеся 5T зарезервированы для volume/test.
Мой Первый вопрос есть, как упадет производительность, если я набью свой volume точка монтирования с ~ 5T? Он упадет, потому что в этой файловой системе нет свободного места для копирования при записи ZFS и других метаданных? Или он останется прежним, поскольку ZFS может использовать свободное пространство в пространстве, зарезервированном для volume/test?
Сейчас второй вопрос. Будет ли разница, если я изменю настройку следующим образом? volume теперь есть две файловые системы, volume/test1 и volume/test2. Каждому из них предоставляется 3T резервирование (но без квот). Допустим, я пишу 7Т на test1. Будет ли производительность для обеих файловых систем одинаковой или будет разной для каждой файловой системы? Он упадет или останется прежним?
Спасибо!
Снижение производительности происходит, когда ваш zpool либо очень полный, либо очень фрагментированный. Причиной этого является механизм обнаружения свободных блоков, используемый в ZFS. В отличие от других файловых систем, таких как NTFS или ext3, здесь нет битовой карты блоков, показывающей, какие блоки заняты, а какие свободны. Вместо этого ZFS делит ваш zvol на (обычно 200) более крупные области, называемые «метаслабами», и хранит AVL-деревья.1 свободной блочной информации (космической карты) в каждой метаслабе. Сбалансированное дерево AVL позволяет эффективно искать блок, соответствующий размеру запроса.
Хотя этот механизм был выбран из соображений масштаба, к сожалению, он также оказался серьезной проблемой, когда происходит высокий уровень фрагментации и / или использования пространства. Как только все метаслабы несут значительный объем данных, вы получаете большое количество небольших областей свободных блоков, в отличие от небольшого количества больших областей, когда пул пуст. Если ZFS затем необходимо выделить 2 МБ пространства, он начинает чтение и оценку карт пространства всех метаслаб, чтобы найти подходящий блок или способ разбить 2 МБ на более мелкие блоки. Это, конечно, требует времени. Что еще хуже, так это то, что это будет стоить много операций ввода-вывода, поскольку ZFS действительно будет читать все карты пространства. с физических дисков. Для любой ваших писаний.
Падение производительности может быть значительным. Если вам нравятся красивые картинки, взгляните на сообщение в блоге в Delphix в котором некоторые числа взяты из (упрощенного, но все же действительного) пула zfs. Я беззастенчиво краду один из графиков - посмотрите на синие, красные, желтые и зеленые линии на этом графике, которые (соответственно) представляют пулы с емкостью 10%, 50%, 75% и 93% от пропускной способности записи в КБ / с при фрагментировании со временем: 
Быстрое и грязное решение этой проблемы традиционно было отладка метаслаборатории режим (просто выдайте 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-обсуждения, хотя я считаю, что он допустил некоторые ошибки в своих расчетах, которые я надеюсь исправить в моих.
Да. Вам нужно оставить свободное место в вашем бассейне. Это в основном для операций копирования при записи и снимков. Производительность снижается при загрузке примерно 85%. Можно подняться выше, но ощутимый удар.
Не связывайтесь с оговорками. Особенно с NFS. Это необязательно. Может для звола, но не NFS.
Однако я не вижу путаницы. Если у вас 10T, не используйте более 85%. Определите размер ваших акций соответствующим образом, используя квоты чтобы ограничить их использование. Или не используйте квоты и следите за общим бассейн использование.