Hugepages linux что это

KVM. Оптимизация работы с памятью при помощи Hugepages

Чтобы виртуальные машины, запущенные в Linux с использованием гипервизора KVM, могли размещать свою оперативную память в физической памяти хоста, размеченной при помощи Hugepages, ядро Linux хоста должно быть собрано с поддержкой Hugepages, механизм Hugepages должен быть активирован и, наконец, KVM должен быть настроен на использование Hugepages. Только сочетая эти 3-х пункта, вы сможете получить реальную поддержку Hugepages и профит от её использования.

Проверка поддержки Hugepages ядром Linux

С первым пунктов всё просто — скорее всего ваш дистрибьютор уже позаботился о поддержке Hugepages, проверть это можно, введя в терминале

gunzip -c /proc/config.gz | grep HUGETLB

Если команда не сработает, выдав «No such file or directory» или что-то похожее, связанное с отсутствием файла конфигурации, с которым ядро было собрано, можно попробовать поискать его в /boot>/p>

grep HUGETLB /boot/config-`uname -r`

Такое различие связано с методами построения дистрибутива и не влияет на конечный результат. Итак, получив наконец список параметров, следует убедиться, что для «CONFIG_HUGETLBFS» и «CONFIG_HUGETLB_PAGE» после знака «=» стоит буква «y», означающая готовность ядра Linux работать с Hugepages — это настройка по умолчанию в большинстве дистрибутивов. Если же нет, то дальше путь закрыт и «Добро пожаловать в клуб любителей пересобирать ядро Linux»

Включение Hugepages в Linux

Переходим ко второму пункту — активации механизма Hugepages в Linux. Этот этап делится на 2: выделение памяти под Hugepages и монтировании специальной файловой системы hugetlbfs — интерфейса взаимодействия программ с Hugepages.

Чтобы выделить определенное количество памяти под Hugepages, следует отредактировать файл sysctl.conf — файл, содержащий параметры ядра. В одних системах, таких как Debian версии 7-8 и Ubuntu версии 12.04 он располагается в /etc (/etc/sysctl.conf), в новых системах, таких как arch linux, в /etc вы его не найдете. Его, если нет, следует создать в /etc/sysctl.d/ под именем, например, hugepages.conf. Разобравшись с sysctl, добавляем (или изменяем) следующую строчку

где 2048 указывает ядру на то, сколько страниц памяти следует выделить для Hugepages. Посчитать этот пораметр не сложно. Предположим нам нужно запустить виртуальную машину, отдав ей 4 гигабайта. 4 гигабайта = 4096 мегабайт. 4096 мегабайт / 2 мегабайта на страницу (размер одной hugepage) = 2048 страниц. Это число следует указать после знака «=» для параметра «vm.nr_hugepages». Если вам потом потребуется дать виртуалке больше памяти, или запустить новую виртуалку, нужно будет количество страниц увеличивать. Само собой, объем памяти должен быть достаточным для проведения этой операции. Помните, что память, отданная под Hugepages, уже не сможет быть использована обычными программами, которые поддержки Hugepages лишены. И после каждого изменения этого параметра, вам следует перезагружать систему.

Есть вариант изменения количества Hugepages без перезагрузки. Для этого следует ввести команду

echo 2048 > /proc/sys/vm/nr_hugepages

После нажатие клавиши «Enter» ядро попытается аллоцировать 2048 больших страниц памяти, и, если количества свободной физической памяти будет достаточно, всё пройдет хорошо. Но только изменение параметра «vm.nr_hugepages» в sysctl.conf является перманентным (сохранится после перезагрузки), поэтому мы рекомендуем первый метод.

Проверить, что ядро зарезервировало необходимое количество страниц можно командой

cat /proc/meminfo | grep Huge

Вы увидите сколько всего больших страниц памяти готовы принимать данные, сколько свободно, сколько зарезервировано, размер страницы и т.д. Вполне логично, что на данном шаге число больших страниц будет равняться числу свободных больших страниц.

Следующим шагом мы должны смонтировать специальную файловую систему hugetlbfs — интерфейс взаимодействия программ с Higepages. Для начала проверьте, не смонтирована ли она уже, дистрибьютор мог и об этом позаботиться:

mount | grep huge

Если вывод непустой (в Debian версии 8 и выше эта настройка по-умолчанию) и содержит запись с указанием того, куда смонтирована hugetlbfs — данный шаг можно смело пропускать. Если нет, монтируем ФС вручную:

mount -t hugetlbfs hugetlbfs /hugepages

Само собой точка монтирования — папка /hugepages, должна существовать. А чтобы hugetlbfs монтировалась автоматически при каждой загрузке, в системах на базе init, следует добавить запись в файл /etc/fstab вида

hugetlbfs /hugepages hugetlbfs defaults 0 0

Если ваша система построена на базе SystemD, вам следует создать unit-файл типа mount следующего содержания

[Unit]
Description=Huge Pages File System
DefaultDependencies=no
Before=sysinit.target
ConditionPathExists=/sys/kernel/mm/hugepages
ConditionCapability=CAP_SYS_ADMIN

[Mount]
What=hugetlbfs
Where=/hugepages
Type=hugetlbfs

Назвать его hugepages.mount (суффикс .mount обязателен) и положить в /lib/systemd/system/

Настрока KVM для работы с Hugepages

Теперь, когда все подготовительные этапы завершены: вы убедились, что ядро поддерживает Hugepages, вы посчитали необходимое количество Hugepages и передали их в качестве параметра ядру Linux, смонтировали специальную файловую систему hugetlbfs — можно приступать к настройке KVM для работы с Hugepages. На самом деле настраивать KVM-то и не нужно, нужно всего лишь немного изменить конфигурацию виртуальной машины. Если вы используете для работы с KVM библиотеку libvirt и такие программы как графический virt-manager или консольный virsh, вам следует выполнить в консоли

что позволит узнать ID интересующей вас виртуальной машины. А потом, с помощью команды

virsh stop VIRTUAL_MACHINE_ID

остановить виртуальную машину. Перезапустить libvirt

systemctl restart libvirtd.service

И, наконец, отредактировать конфигурационный файл виртуальной машины с помощью команды

virsh edit VIRTUAL_MACHINE_NAME

Добавить в начало файла (чуть дальше от начала, где-то после строк относящихся к memory) следующие строки

И запустить виртуальную машину с помощью virt-manager или команды

virsh start VIRTUAL_MACHINE_NAME

После того, как виртуальная машина будет запущена, убедитесь, что рассчетное количество Hugepages было аллоцировано процессом виртуальной машины — посмотрите на содержимое файла /proc/meminfo

grep Huge /proc/meminfo

Количество свободных страниц должно было уменьшиться на величину, равную объему оперативной памяти, отданной виртуальной машине деленной на размер Hugepage.

Если же вы вместо libvirt предпочитаете использовать qemu напрямую, просто добавьте в команду запуска виртуальной машину еще один ключик, приказывающий qemu использовать Hugepages:

qemu-. –mem-path /dev/hugepages

qemu-. –mem-path /hugepages

в зависимости от того, куда вы решили монтировать hugetlbfs

Источник

Huge Pages в PostgreSQL

В PostgreSQL начиная с версии 9.4 появилась поддержка больших страниц. Это очень хорошая новость, с большими страницами я познакомился когда работал с виртуализацией. Коротко о чем же речь. В ОС Linux работа с памятью основывается на обращении к страницам размер которых равен 4kB (на самом деле зависит от платформы, проверить можно через getconf PAGE_SIZE), так вот когда объем памяти переваливает за несколько десятков, а то и сотни гигабайт управлять ею становится сложнее, увеличиваются накладные расходы на адресацию памяти и поддержание страничных таблиц. Для облегчения жизни и были придуманы большие страницы, размер которых может быть 2MB а то и 1GB. За счет использования больших страниц можно получить ощутимый прирост скорости работы и увеличение отзывчивости в приложениях которые активно работают с памятью. Как я уже отметил, впервые я столкнулся с большими страницами при работе с виртуализацией, в частности с KVM. Проведенные в свое время тесты показали что прирост производительности виртуальных машин составил от 7 до 10% (измерялось все это дело синтетическими тестами различных сервисов типа redis/memcache/postgres/etc внутри виртуальных машин). Теперь это появилось в PostgreSQL.

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

Для начала следует убедиться что ядро поддерживает большие страницы. Проверяем конфиг ядра на предмет наличия опций CONFIG_HUGETLBFS и CONFIG_HUGETLB_PAGE.

В случае отсутствия этих опций, ничего не заработает и ядро следует пересобрать (актуально для Gentoo например).
Очевидно что нам понадобится PostgreSQL версии 9.4. Установку пакетов и инициализацию кластера оставляю за кадром, т.к. в зависимости от дистрибутива способ будет отличаться. Переходим сразу к файлу конфигурации postgresql.conf. За поддержку больших страниц отвечает параметр huge_page который может принимать три значения, off — не использовать большие страницы, on — использовать большие страницы, try — попытаться использовать большие страницы и в случае недоступности откатиться на использование обычных страниц. Значение try используется по-умолчанию и является безопасным вариантом. В случае on, сервис не запустится если большие страницы не определены в системе (или их недостаточно). В случае запуска можно получить такую ошибку:

FATAL: could not map anonymous shared memory: Cannot allocate memory
HINT: This error usually means that PostgreSQL’s request for a shared memory segment exceeded available memory, swap space or huge pages. To reduce the request size (currently 148324352 bytes), reduce PostgreSQL’s shared memory usage, perhaps by reducing shared_buffers or max_connections.

Итак, правим postgresql.conf (мой postgresql.conf располагается в месте стандартном для RHEL-based дистрибутивов):

Теперь включаем поддержку больших страниц в системе, по-умолчанию они не задействованы. Расчет страниц приблизительный и здесь следует опираться на то сколько памяти вы готовы выделить под нужды СУБД. Отмечу что значение измеряется в страницах размером 2Mb, если вы хотите выделить 16GB, то это будет 8000 страниц.

Официальная документация предлагает опираться на значение VmPeak из status файла который размещен в /proc/PID/ директории который соответствует номеру процесса postmaster. VmPeak как следует из названия это пиковое значение использования виртуальной памяти. Этот вариант позволяет определить минимальную планку от которой следует отталкиваться, но на мой вгляд такой способ определения тоже носит случайный характер.

Переходим к запуску PostgreSQL. В зависимости от системы инициализации способ запуска может отличаться, у меня модный-молодежный systemd.

Утилизацию больших страниц можно посмотреть здесь.

На этом собственно все, можно переходить к бенчмаркам вашими конкретными workloads. Спасибо за внимание!

Источник

G HugePages

This chapter provides an overview of Hugepages and guides Linux system administrators to configure HugePages on Linux.

G.1 Overview of HugePages

HugePages is a feature integrated into the Linux kernel 2.6. Enabling HugePages makes it possible for the operating system to support memory pages greater than the default (usually 4 KB). Using very large page sizes can improve system performance by reducing the amount of system resources required to access page table entries. HugePages is useful for both 32-bit and 64-bit configurations. HugePage sizes vary from 2 MB to 256 MB, depending on the kernel version and the hardware architecture. For Oracle Databases, using HugePages reduces the operating system maintenance of page states, and increases Translation Lookaside Buffer (TLB) hit ratio.

Transparent Hugepages is currently not an alternative to manually configure HugePages.

This section includes the following topics:

G.1.1 Tuning SGA With HugePages

Without HugePages, the operating system keeps each 4 KB of memory as a page. When it allocates pages to the database System Global Area (SGA), the operating system kernel must continually update its page table with the page lifecycle (dirty, free, mapped to a process, and so on) for each 4 KB page allocated to the SGA.

With HugePages, the operating system page table (virtual memory to physical memory mapping) is smaller, because each page table entry is pointing to pages from 2 MB to 256 MB.

Also, the kernel has fewer pages whose lifecycle must be monitored. For example, if you use HugePages with 64-bit hardware, and you want to map 256 MB of memory, you may need one page table entry (PTE). If you do not use HugePages, and you want to map 256 MB of memory, then you must have 256 MB * 1024 KB/4 KB = 65536 PTEs.

HugePages provides the following advantages:

Increased performance through increased TLB hits

Pages are locked in memory and never swapped out, which provides RAM for shared memory structures such as SGA

Contiguous pages are preallocated and cannot be used for anything else but for System V shared memory (for example, SGA)

Less bookkeeping work for the kernel for that part of virtual memory because of larger page sizes

G.1.2 Configuring HugePages on Linux

Complete the following steps to configure HugePages on the computer:

Run the following command to determine if the kernel supports HugePages:

Some Linux systems do not support HugePages by default. For such systems, build the Linux kernel using the CONFIG_HUGETLBFS and CONFIG_HUGETLB_PAGE configuration options. CONFIG_HUGETLBFS is located under File Systems and CONFIG_HUGETLB_PAGE is selected when you select CONFIG_HUGETLBFS .

Edit the memlock setting in the /etc/security/limits.conf file. The memlock setting is specified in KB, and the maximum locked memory limit should be set to at least 90 percent of the current RAM when HugePages memory is enabled and at least 3145728 KB (3 GB) when HugePages memory is disabled. For example, if you have 64 GB RAM installed, then add the following entries to increase the maximum locked-in-memory address space:

You can also set the memlock value higher than your SGA requirements.

Log in as oracle user again and run the ulimit -l command to verify the new memlock setting:

Run the following command to display the value of Hugepagesize variable:

Complete the following procedure to create a script that computes recommended values for hugepages configuration for the current shared memory segments:

Create a text file named hugepages_settings.sh .

Add the following content in the file:

Run the following command to change the permission of the file:

Run the hugepages_settings.sh script to compute the values for hugepages configuration:

Before running this script, ensure that all the applications that use hugepages run.

Set the following kernel parameter, where value is the HugePages value that you determined in step 7:

To ensure that HugePages is allocated after system restarts, add the following entry to the /etc/sysctl.conf file, where value is the HugePages value that you determined in step 7:

Run the following command to check the available hugepages :

Restart the instance.

Run the following command to check the available hugepages (1 or 2 pages free):

If you cannot set your HugePages allocation using nr_hugepages , then your available memory may be fragmented. Restart your server for the Hugepages allocation to take effect.

G.1.3 Restrictions for HugePages Configurations

HugePages has the following limitations:

You must unset both the MEMORY_TARGET and MEMORY_MAX_TARGET initialization parameters. For example, to unset the parameters for the database instance, use the command ALTER SYSTEM RESET .

Automatic Memory Management (AMM) and HugePages are not compatible. When you use AMM, the entire SGA memory is allocated by creating files under /dev/shm . When Oracle Database allocates SGA with AMM, HugePages are not reserved. To use HugePages on Oracle Database 12 c , You must disable AMM.

If you are using VLM in a 32-bit environment, then you cannot use HugePages for the Database Buffer cache. You can use HugePages for other parts of the SGA, such as shared_pool , large_pool , and so on. Memory allocation for VLM (buffer cache) is done using shared memory file systems ( ramfs/tmpfs/shmfs ). Memory file systems do not reserve or use HugePages.

HugePages are not subject to allocation or release after system startup, unless a system administrator changes the HugePages configuration, either by modifying the number of pages available, or by modifying the pool size. If the space required is not reserved in memory during system startup, then HugePages allocation fails.

Ensure that HugePages is configured properly as the system may run out of memory if excess HugePages is not used by the application.

If there is insufficient HugePages when an instance starts and the initialization parameter use_large_pages is set to only , then the database fails to start and an alert log message provides the necessary information on Hugepages.

G.1.4 Disabling Transparent HugePages

Transparent HugePages memory is enabled by default with Red Hat Enterprise Linux 6, SUSE 11, and Oracle Linux 6 with earlier releases of Oracle Linux Unbreakable Enterprise Kernel 2 (UEK2) kernels. Transparent HugePages memory is disabled by default in later releases of UEK2 kernels.

Transparent HugePages can cause memory allocation delays at runtime. To avoid performance issues, Oracle recommends that you disable Transparent HugePages on all Oracle Database servers. Oracle recommends that you instead use standard HugePages for enhanced performance.

Transparent HugePages memory differs from standard HugePages memory because the kernel khugepaged thread allocates memory dynamically during runtime. Standard HugePages memory is pre-allocated at startup, and does not change during runtime.

To check if Transparent HugePages is enabled run one of the following commands as the root user:

Red Hat Enterprise Linux kernels:

The following is a sample output that shows Transparent HugePages is being used as the [always] flag is enabled.

If Transparent HugePages is removed from the kernel then the /sys/kernel/mm/transparent_hugepage or /sys/kernel/mm/redhat_transparent_hugepage files do not exist.

To disable Transparent HugePages perform the following steps:

Источник