У меня есть несколько серверов, которые мы используем в качестве узлов гипервизора KVM. Мы хотим включить огромные страницы и использовать эти функции для решения вопросов, связанных с производительностью.
Я посмотрел в Интернете, как включить огромные страницы, и это довольно ясно и просто, но я не могу найти, как определить значение счетчика огромных страниц, которое следует использовать.
Чтобы дать вам некоторое представление, это система, которая у нас есть (одинакова для всего кластера):
$ free -g
total used free shared buff/cache available
Mem: 503 5 497 0 1 495
Swap: 0 0 0
Мы хотим включить огромные страницы размером 1 ГБ, но количество HugePages - это то, что мы не знаем, как определить. Как это число определяется, на основе памяти, любой ввод будет оценен.
Рассматриваемая конфигурация:
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX hugepagesz=1G hugepages=<what goes here> transparent_hugepage=never"
Для тестирования полностью загрузите один из этих хостов гипервизора с типичной рабочей нагрузкой на небольших страницах. Итак, не устанавливайте hugepages начать.
Сделайте несколько образцов /proc/meminfo. Смотрите, если PageTables: становится слишком большой частью памяти, с тяжелым системным процессором, это накладные расходы. Накладные расходы могут быть неприемлемыми, но 500 ГБ - это много, и огромные страницы должны приносить пользу.
DirectMap1G: это то, что ядро отслеживает с помощью карт размером 1 ГБ, в кБ. Необязательно явные огромные страницы, ядро просто могло найти смежные. Разделите экспериментальное значение на 1048576, чтобы получить начальное значение для гигантских страниц.
Запись DirectMap2M: Кроме того, это карты размером 2 МБ, на случай, если большой размер страницы подойдет лучше.
Распределение огромных страниц не может составлять 100% памяти хоста, используется только 4 КБ, а хосты виртуальных машин не должны чрезмерно загружать гостевую память. Примерно хотя бы несколько процентов для ядра, кешей, административных программ и немного бесплатно. Остальное можно было бы использовать для огромных страниц.
Документы RHEL предлагают скрипт ранней загрузки ткнуть / sys / devices / system / node / node * / hugepages / hugepages-1048576kB / nr_hugepages с количеством страниц. Обратите внимание, что если у вас несколько узлов NUMA, вам нужно настроить сценарий, чтобы ввести значение в каждый из них.
hugepages в командной строке ядра остается вариантом, но вам придется поддерживать числа, специфичные для размера памяти хоста, с конфигурацией загрузчика.
Говоря о конфигурации загрузчика, я согласен с transparent_hugepage=never. THP требует значительных накладных расходов на дефрагментацию страниц и их перетасовку. Нежелательно для больших блоков памяти с известной рабочей нагрузкой.