Какие метаданные в основном загружаются / удаляются из ARC в моей системе ZFS?

Question

Я пытаюсь проверить, как используется ARC моего пула ZFS, мотивируя это «мне нужно больше оперативной памяти, даже если это дорого».

У меня есть быстрый ECC на 128 ГБ, и я использую твердотельные накопители NVMe для L2ARC, но он все еще делает много небольших операций чтения-вывода, связанных со смесью DDT/spacemaps. Система рассчитана на ДДТ и имеет коэффициент дедупликации примерно 3,5x ~ 4х, поэтому, пожалуйста, не отвечайте «ДДТ - это баад», я знаю, но нужен ДДТ, поэтому я работаю над тем, чтобы минимизировать оставшуюся частоту чтения, гарантируя, по крайней мере, что метаданные ddt/spacemap в основном сохраняются в ARC, когда система нагревается.

Я ожидаю, что будет использоваться оперативная память: DDT составляет около 35-40 ГБ, и я использовал sysctl, чтобы зарезервировать 85 ГБ ARC для метаданных. Я также установил больший размер блока spacemap и дефрагментировал пул (скопировал в новый пул), что, похоже, очень помогает. Но поскольку я не вижу метрик для определения количества загруженных или удаленных метаданных различных типов (ddt/spacemap/other), и нет инструментов для установки размера блока ZFS ddt или предварительной загрузки записей DDT в ARC, я в неведении относительно точного воздействия, или поможет ли больше оперативной памяти, или других систематических способов добиться большего.

Я искал решения. zdb , arc-stats т. д. не дают разбивки ситуации ARC метаданных, а представляют собой единовременную сумму для всех метаданных.

Есть ли простой способ получить представление о том, что происходит, чтобы оценить, поможет ли больше ОЗУ, даже если оно не точное, или как лучше понять (даже если неточно) разбивку значений ddt/spacemap/"другие" метаданные MRU/MFU загружаются /кэшируются /выселяются?

Answer 1

Я не думаю, что для этой цели есть какой-либо встроенный инструмент, такой как arcstats, тем более, что вы работаете во FreeBSD, который, как я предполагаю, не имеет mdb (от illumos / Solaris).

Самое простое решение - дать немного больше оперативной памяти и посмотреть, поможет ли это. Конечно, это стоит денег, но это может быть дешевле, чем ваше время, чтобы выяснить ответ (если вам платят за эту работу).

Следующая самая простая вещь, которую можно попробовать - это сузиться с ограничениями памяти ARC при выполнении некоторой тестовой рабочей нагрузки. Влияние, которое они оказывают на рабочие нагрузки, часто не является интуитивно понятным, поэтому я рекомендую начать со всех настроек по умолчанию, а затем постепенно менять их, чтобы сделать их более сложными. Возможно, что, например, когда вы пытаетесь установить минимальную память, зарезервированную для метаданных, вы на самом деле устанавливаете максимальную ошибку по ошибке, что приведет к перебоям, как вы описали, поэтому обязательно внимательно прочитайте «документы» для этих настроек.

Наконец, если вы немного отважны и достаточно уверены в своей способности анализировать сложные данные, чтобы определить ответ на свой вопрос, вы также можете использовать DTrace для этого. Этот зонд срабатывает каждый раз, когда в ARC происходит промах кэша:

DTRACE_PROBE4(arc__miss, arc_buf_hdr_t *, hdr, blkptr_t *, bp,
    uint64_t, lsize, zbookmark_phys_t *, zb);

Таким образом, вы могли бы написать сценарий D, который прослушивает :::arc_miss и использовать args[0] , args[1] и / или обратную трассировку, чтобы выяснить, какие типы запросов пропускают кэш.

Я подозреваю, что самый простой способ - это посмотреть на тип blockptr_t в args[1] . К сожалению, это несколько раздражает, потому что это часть битового поля. Определение объекта указателя блока можно найти здесь, и вы хотите, чтобы ваш сценарий DTrace выводил то же самое, что BP_GET_TYPE(args[1]) , а затем интерпретировал эти значения, сравнивая со значениями dmu_object_type отсюда .

С другой стороны, я могу порекомендовать более простой сценарий, который потенциально более сложен для интерпретации. Он будет собирать трассировку каждый раз при срабатывании зонда, а затем вы сможете пост-обработать трассы для создания графика пламени для более легкой интерпретации. Имена методов в ZFS в целом довольно описательны (по крайней мере, все они имеют аббревиатуры, например, ddt для «таблицы дедупликации», которую вы можете искать в Интернете), так что вы, вероятно, сможете выяснить, что делают вызывающие пользователи таким образом.

Если появляется масса значений, которые не являются данными файлов или каталогов, вам, вероятно, нужно хранить больше метаданных в кэше. Вы можете сделать это либо, выделив ему больше места с помощью перестраиваемых настроек, либо предоставив машине больше оперативной памяти.