Hugepages linux что это
KVM. Оптимизация работы с памятью при помощи Hugepages
Чтобы виртуальные машины, запущенные в Linux с использованием гипервизора KVM, могли размещать свою оперативную память в физической памяти хоста, размеченной при помощи Hugepages, ядро Linux хоста должно быть собрано с поддержкой Hugepages, механизм Hugepages должен быть активирован и, наконец, KVM должен быть настроен на использование Hugepages. Только сочетая эти 3-х пункта, вы сможете получить реальную поддержку Hugepages и профит от её использования.
Проверка поддержки Hugepages ядром Linux
Если команда не сработает, выдав «No such file or directory» или что-то похожее, связанное с отсутствием файла конфигурации, с которым ядро было собрано, можно попробовать поискать его в /boot>/p>
Включение Hugepages в Linux
где 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 /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
Настрока KVM для работы с Hugepages
что позволит узнать ID интересующей вас виртуальной машины. А потом, с помощью команды
virsh stop VIRTUAL_MACHINE_ID
остановить виртуальную машину. Перезапустить libvirt
systemctl restart libvirtd.service
И, наконец, отредактировать конфигурационный файл виртуальной машины с помощью команды
virsh edit VIRTUAL_MACHINE_NAME
Добавить в начало файла (чуть дальше от начала, где-то после строк относящихся к memory) следующие строки
И запустить виртуальную машину с помощью virt-manager или команды
virsh start VIRTUAL_MACHINE_NAME
grep Huge /proc/meminfo
Количество свободных страниц должно было уменьшиться на величину, равную объему оперативной памяти, отданной виртуальной машине деленной на размер Hugepage.
Если же вы вместо libvirt предпочитаете использовать qemu напрямую, просто добавьте в команду запуска виртуальной машину еще один ключик, приказывающий qemu использовать Hugepages:
qemu-. –mem-path /dev/hugepages
qemu-. –mem-path /hugepages
в зависимости от того, куда вы решили монтировать hugetlbfs
Преимущества и недостатки HugePages
Перевод статьи подготовлен для студентов курса «Администратор Linux».
Ранее я рассказал о том, как проверить и включить использование Hugepages в Linux.
Эта статья будет полезна, только если у вас действительно есть, где использовать Hugepages. Я встречал множество людей, которые обманываются перспективой того, что Hugepages волшебным образом повысят производительность. Тем не менее hugepaging является сложной темой, и при неправильном использовании он способен понизить производительность.
Часть 1: проверяем, что hugepages включены в Linux (оригинал здесь)
Проблема:
Необходимо проверить, включены ли HugePages в вашей системе.
Решение:
Оно довольно простое:
Вы получите что-то вроде этого:
Вы увидите список доступных опций (always, madvise, never), при этом текущая активная опция будет заключена в скобки (по умолчанию madvise).
madvise означает, что transparent hugepages включены только для областей памяти, которые явно запрашивают hugepages с помощью madvise(2).
always означает, что transparent hugepages включены всегда и для всех процессов. Обычно это повышает производительность, но если у вас есть вариант использования, где множество процессов потребляет небольшое количество памяти, то общая нагрузка на память может резко возрасти.
never означает, что transparent hugepages не будут включаться даже при запросе с помощью madvise. Чтобы узнать больше, обратитесь к документации ядра Linux.
Как изменить значение по умолчанию
Вариант 1: Напрямую изменить sysfs (после перезагрузки параметр вернется к значению по умолчанию):
Вариант 2: Измените системное значение по умолчанию, перекомпилировав ядро с измененной конфигурацией (этот вариант рекомендуется только если вы используете собственное ядро):
Часть 2: Преимущества и недостатки HugePages
Мы попытаемся выборочно объяснить преимущества, недостатки и возможные ошибки при использовании Hugepages. Поскольку технологически сложная и педантичная статья, вероятно, будет тяжелой для понимания людям, которые обманываются считая Hugepages панацеей, я пожертвую точностью в угоду простоты. Просто стоит иметь ввиду, что множество тем действительно сложны и поэтому сильно упрощены.
Обратите внимание, что мы говорим о 64-х разрядных x86 системах, работающих на Linux, и что я просто предполагаю, что система поддерживает transparent hugepages (так как не является недостатком то, что hugepages не подменяются), как это случается практически в любой современной среде Linux.
В ссылках ниже я прикреплю больше технического описания.
Виртуальная память
Если вы программист C++, вы знаете, что у объектов в памяти есть конкретные адреса (значения указателя).
Однако эти адреса необязательно отражают физические адреса в памяти (адреса в ОЗУ). Они представляют собой адреса в виртуальной памяти. Процессор имеет специальный модуль MMU (memory management unit), который помогает ядру сопоставлять виртуальную память с физическим местоположением.
Такой подход имеет множество преимуществ, но самые основные из них:
Что такое страницы?
Виртуальная память поделена на страницы. Каждая отдельная страница указывает на определенную физическую память, она может указывать на область в оперативной памяти, а может на адрес, назначенный физическому устройству, например видеокарте.
Большинство страниц, с которыми вы имеете дело, указывают либо на ОЗУ, либо подменяются (swap), то есть хранятся на жестком диске или SSD. Ядро управляет физическим расположением каждой страницы. Если осуществляется доступ к подмененной странице, ядро останавливает поток, который пытается получить доступ к памяти, считывает страницу с жесткого диска/SSD в оперативную память, а затем продолжает выполнение потока.
Этот процесс прозрачен для потока, то есть он не обязательно читает напрямую с жесткого диска/SSD. Размер нормальных страниц – 4096 байт. Размер Hugepages – 2 мегабайта.
Буфер ассоциативной трансляции (TLB)
Когда программа обращается к некоторой странице памяти, центральный процессор должен знать, с какой физической страницы считывать данные (то есть иметь виртуальную карту адресов).
В ядре есть структура данных (таблица страниц), которая содержит всю информацию об используемых страницах. С помощью этой структуры данных можно сопоставить виртуальный адрес с физическим адресом.
Однако таблица страниц довольно сложна и работает медленно, поэтому мы просто не можем каждый раз анализировать всю структуру данных, когда какой-либо процесс обращается к памяти.
К счастью в нашем процессоре есть TLB, который кэширует сопоставление виртуальных и физических адресов. Это значит, что несмотря на то, что нам нужно проанализировать таблицу страниц при первой попытке получить доступ, все последующие обращения к странице могут обрабатываться в TLB, что обеспечивает быструю работу.
Поскольку он реализован в качестве физического устройства (что делает его в первую очередь быстрым), его емкость ограничена. Поэтому, если вы захотите получить доступ к большему количеству страниц, TLB не сможет хранить сопоставление для всех них, вследствие чего ваша программа будет работать намного медленнее.
Hugepages приходят на помощь
Итак, что мы можем сделать, чтобы избежать переполнения TLB? (Мы предполагаем, что программе все еще нужен тот же объем памяти).
Вот тут-то и появляются Hugepages. Вместо 4096 байт, требующих всего одну запись в TLB, одна запись в TLB теперь может указывать на колоссальные 2 мегабайта. Будем предполагать, что TLB имеет 512 записей, здесь без Hugepages мы можем сопоставить:
Тогда как с ними мы можем сопоставить:
Именно поэтому Hugepages – это круто. Они могут повысить производительность без значительного приложения усилий. Но здесь есть существенные оговорки.
Подмена Hugepages
Ядро автоматически отслеживает частоту использования каждой страницы памяти. Если физической памяти (ОЗУ) недостаточно, ядро переместит менее важные (реже используемые) страницы на жесткий диск, чтобы освободить часть ОЗУ для более важных страниц.
В принципе, то же самое касается и Hugepages. Однако ядро может менять местами только целые страницы, а не отдельные байты.
Предположим, у нас есть такая программа:
В этом случае ядру нужно будет подменить (прочитать) целых 2 мегабайта информации с жесткого диска/SSD только для того чтобы вы прочитали один байт. Что касается обычных страниц, с жесткого диска/SSD надо прочитать всего 4096 байт.
Поэтому, если hugepage подменяется, ее чтение происходит быстрее, только если вам нужно получить доступ ко всей странице. Это значит, что если вы пытаетесь получить доступ случайным образом к различным частям памяти и просто считываете пару килобайт, вам следует использовать обычные страницы и больше ни о чем не беспокоиться.
С другой стороны, если вам нужно получать доступ к большой части памяти последовательно, hugepages увеличат вашу производительность. Тем не менее, вам нужно проверить это самостоятельно (а не на примере абстрактного ПО) и посмотреть, что будет работать быстрее.
Аллокация в памяти
Программисту может показаться, что вы “запрашиваете” 30 байт памяти из операционной системы и возвращаете указатель на некоторую виртуальную память. Но на самом деле malloc () — это просто функция C, которая вызывает изнутри функции brk и sbrk для запроса или освобождения памяти из операционной системы.
При этом для вас все происходит незаметно, так почему это должно вас волновать? А потому, что вызов free() не означает, что память обязательно возвращается сразу же операционной системе.
Обратите внимание, что фрагментация памяти является невероятно сложной темой, и даже незначительные изменения в программе могут значительно повлиять на нее. В большинстве случаев программы не вызывают значительной фрагментации памяти, но вы должны иметь ввиду, что если с фрагментацией в некоторой области кучи возникла проблема, hugepages могут только усугубить ситуацию.
Выборочное применение hugepages
После прочтения статьи, вы определили, какие части вашей программы могут извлечь выгоду из применения hugepages, а какие – нет. Так следует ли вообще включать hugepages?
Для начала, проверьте, что hugepages работают в режиме madvise(), с помощью инструкции в начале статьи.
Обратите внимание, что этот метод — просто рекомендации ядру по управлению памятью. Это не означает, что ядро будет автоматически использовать hugepages для заданной памяти.
Что почитать?
Есть вопрос? Напишите в комментариях!
What are the huge pages in Linux?
Published: November 2, 2017 | Modified: June 25, 2020
Learn about huge pages in Linux. Understand what is huge pages, how to configure it, how to check the current state, and how to disable it.
In this article, we will walk you through details about huge pages so that you will be able to answer: what are huge pages in Linux? How to enable/disable huge pages? How to determine huge page value? in Linux like RHEL6, RHEL7, Ubuntu, etc.
Lets start with Huge pages basics.
What is Huge page in Linux?
Huge pages are helpful in virtual memory management in the Linux system. As the name suggests, they help is managing huge size pages in memory in addition to standard 4KB page size. You can define as huge as 1GB page size using huge pages.
During system boot, you reserve your memory portion with huge pages for your application. This memory portion i.e. these memory occupied by huge pages is never swapped out of memory. It will stick there until you change your configuration. This increases application performance to a great extent like Oracle database with pretty large memory requirements.
Why use huge page?
In virtual memory management, the kernel maintains a table in which it has a mapping of the virtual memory address to a physical address. For every page transaction, the kernel needs to load related mapping. If you have small size pages then you need to load more numbers of pages resulting kernel to load more mapping tables. This decreases performance.
Using huge pages means you will need fewer pages. This decreases the number of mapping tables to load by the kernel to a great extent. This increases your kernel-level performance which ultimately benefits your application.
In short, by enabling huge pages, the system has fewer page tables to deal with and hence less overhead to access/maintain them!
How to configure huge pages?
Run below command to check current huge pages details.
Run below script to get how much huge pages your system needs currently. The script is from Oracle and can be found.
You can save it in /tmp as hugepages_settings.sh and then run it like below :
Output will be similar to some number as shown in above sample output.
This means your system needs 124 huge pages of 2MB each! If you have set 4MB as page size then the output would have been 62. You got the point, right?
Configure hugepages in kernel
Notice that we added 2 extra pages in the kernel since we want to keep a couple of pages spare than the actual required number.
Now, huge pages have been configured in the kernel but to allow your application to use them you need to increase memory limits as well. The new memory limit should be 126 pages x 2 MB each = 252 MB i.e. 258048 KB.
You need to edit below settings in /etc/security/limits.conf
Sometimes these settings are configured in app-specific files like for Oracle DB its in /etc/security/limits.d/99-grid-oracle-limits.conf
That’s it! You might want to restart your application to make use of these new huge pages.
How to disable hugepages?
HugePages are generally enabled by default. Use the below command to check the current state of huge pages.
[always] flag in output shows that hugepages are enabled on system.
For RedHat based systems file path is /sys/kernel/mm/redhat_transparent_hugepage/enabled
Влияние Transparent Huge Pages на производительность системы
Статья публикуется от имени Ахальцева Иоанна, Jiga
Tinkoff.ru сегодня — это не просто банк, это IT-компания. Она предоставляет не только банковские услуги, но ещё выстраивает экосистему вокруг них.
Мы в Tinkoff.ru заключаем партнерство с различными сервисами для повышения качества обслуживания своих клиентов, и помогаем становиться этим сервисам лучше. Например, мы проводили нагрузочное тестирование и анализ производительности одного из таких сервисов, которые помогли найти узкие места в системе — включенные Transparent Huge Pages в конфигах ОС.
Если вы хотите узнать каким способом провести анализ производительности системы и что из этого получилось у нас, то добро пожаловать под кат.
Описание проблемы
На текущий момент архитектура сервиса представляет собой:
Основная проблема, которую мы обнаружили во время очередной распродажи под высокой нагрузкой — высокая утилизация cpu, при том что время работы процессора в режиме ядра (system time) росло и было больше, чем время работы в пользовательском режиме (user time).
Определение первичных характеристик системы
Для начала мы собрали нагрузочный контур с ресурсами близкими к продуктивным, и составили профиль нагрузки, соответствующий нормальной нагрузке в обычный день.
При определении первичных характеристик системы подходит сценарий с линейно-возрастающей нагрузкой с http конфигурацией:
На данном этапе реализовали сценарий открытия главной страницы и скачивание всех ресурсов
Результаты данного теста показали максимальную производительность в 1500 rps, дальнейшее увеличение интенсивности нагрузки привело к деградации системы, связанной с увеличивающимся softirq time.
Softirq представляет собой механизм отложенных прерываний и описан в файле kernel/softirq.с. При этом они забивают очередь команд к процессору, не давая делать полезные вычисления в пользовательском режиме. Обработчики прерываний также могут откладывать дополнительную работу с сетевыми пакетами в потоках ОС (system time). Кратко о работе сетевого стека и оптимизациях можно почитать в отдельной статье.
Подозрение на основную проблему не подтвердилось, потому что на проде при меньшей сетевой активности был куда больший system time.
Пользовательские сценарии
Следующим шагом было решено развивать пользовательские сценарии и добавить, что-то большее, чем простое открытие страницы с картинками. В профиль вошли тяжелые операции, которые задействовали в полной мере код сайта и базы данных, а не веб-сервер отдающий статические ресурсы.
Тест со стабильной нагрузкой запущен на меньшей интенсивности от максимальной, в конфигурацию добавлен переход по редиректам:
Наиболее полное задействование систем показало увеличение метрики system time, а также её рост во время теста стабильности. Проблема с продуктивной среды была воспроизведена
Сетевое взаимодействие с Redis
При анализе проблем очень важно иметь мониторинг всех компонентов системы, чтобы понимать как она работает и какое влияние на неё оказывает подаваемая нагрузка.
При появлении мониторинга Redis, стало возможно смотреть не на общие метрики системы, а на её конкретные компоненты. Также был изменён сценарий на стресс-тестирование, что совместно с дополнительным мониторингом помогло приблизиться к локализации проблемы.
В мониторинге Redis увидели аналогичную картину с утилизацией cpu, а точнее system time значительно больше user time, при том что основная утилизация cpu приходилась на операцию SET, то есть выделение оперативной памяти для хранения значения.
Для исключения влияния сетевого взаимодействия с Redis было решено проверить гипотезу и переключить Redis на UNIX сокет, вместо tcp сокета. Сделано это было прямо во фреймворке, через который php-fpm подключается к БД. В файле /yiisoft/yii/framework/caching/CRedisCache.php заменили строчку с host:port на хардкодный redis.sock. Подробнее про быстродействие сокетов можно почитать в статье.
К сожалению, большого эффекта это не возымело. Утилизация CPU немного стабилизировалась, но не решило нашей проблемы — большая часть утилизации CPU приходилась на вычисления в режиме ядра.
Бенчмарк с помощью stress и выявление проблемы THP
Для локализации проблемы помогла утилита stress — простой генератор рабочей нагрузки для POSIX-систем, которая может нагрузить отдельные компоненты системы, например, CPU, Memory, IO.
Тестирование предполагается на оборудовании и версии ОС:
Установка утилиты выполняется с помощью команды:
Смотрим как утилизируется CPU под нагрузкой, запускаем тест, который создаёт воркеров для расчёта квадратных корней с продолжительностью в 300 сек:
На графике видно полную утилизацию в пользовательском режиме — это значит, что загружены все ядра процессора и выполняются полезные вычисления, а не системные обслуживающие вызовы.
Следующим шагом рассмотрим использование ресурсов при интенсивной работе с io. Запускаем тест на 300 сек с созданием 12 воркеров, которые выполняют sync(). Команда sync записывает данные, буферизованные в памяти, на диск. Ядро хранит данные в памяти во избежание частых (обычно медленных) дисковых операций чтения и записи. Команда sync() гарантирует, что все, что хранилось в памяти, будет записано на диск.
Видим, что процессор в основном занимается обработкой вызовов в режиме ядра и немного в iowait, также видно >35k ops записи на диск. Такое поведение похоже на проблему с высоким system time, причины которой мы анализируем. Но здесь присутствует несколько отличий: это iowait и iops больший, чем на продуктивном контуре, соответственно это не подходит под наш случай.
Настало время для проверки памяти. Запускаем 20 воркеров, которые будут выделять и освобождать память 300 сек, с помощью команды:
Сразу видим высокую утилизацию CPU в системном режиме и немного в пользовательском режиме, а также использование оперативной памяти больше 2 Гб.
Данный случай очень похож на проблему с продом, которая подтверждается большим использованием памяти на нагрузочных тестах. Следовательно проблему необходимо искать в работе памяти. Выделение и освобождение памяти происходит с помощью вызовов malloc и free соответственно, которые в итоге будут обработаны системными вызовами ядра, а значит отобразятся в утилизации CPU как системное время.
В большинстве современных операционных систем виртуальная память организуется с помощью страничной адресации, при таком подходе вся область памяти делится на страницы фиксированной длины, например 4096 байт (является дефолтом для многих платформ), и при выделении, например, 2 Гб памяти, менеджеру памяти придётся оперировать более чем 500000 страниц. В таком подходе появляются большие накладные расходы на управление и для их уменьшения были придуманы технологии Huge pages и Transparent Huge Pages, с их помощью можно увеличить размер страницы, например до 2МБ, что существенно сократит количество страниц в куче памяти. Разница технологий заключается лишь в том, что для Huge pages мы должны явно настроить окружение и научить программу с ними работать, в то время как Transparent Huge Pages работает «прозрачно» для программ.
THP и решение проблемы
Если погуглить информацию о Transparent Huge Pages, то можно увидеть в результатах поиска множество страниц с вопросами «Как выключить THP».
Как оказалось эту «крутую» фичу внесла в ядро Linux корпорация Red Hat, суть фичи, в том что приложения могут прозрачно работать с памятью, как будто они работают с настоящими Huge Page. Согласно бенчмаркам THP на 10% ускоряют абстрактное приложение, подробнее можно посмотреть в презентации, но на деле всё по другому. В некоторых случаях THP вызывает ничем не мотивированное увеличение потребления CPU в систем. Подробнее можно ознакомиться с рекомендациями от Oracle.
Идём и проверяем наш параметр. Как и оказалось THP включен по умолчанию, — выключаем с помощью команды:
Подтверждаем с помощью теста перед выключением THP и после, на профиле нагрузки:
Такую картину мы наблюдали до выключения THP
После выключения THP мы можем наблюдать уже уменьшенную утилизацию ресурсов.
Основная проблема была локализована. Причиной являлся включенный по умолчанию в ОС
механизм прозрачных больших страниц. После выключения опции THP утилизация cpu в системном режиме снизилась не менее чем в 2 раза, что освободило ресурсы для пользовательского режима. Во время анализа основной проблемы, также были найдены «узкие места» взаимодействия с сетевым стеком ОС и Redis, что является поводом для более глубокого исследования. Но это уже совсем другая история.
Заключение
В заключение хотелось бы дать несколько советов, для успешного поиска проблем с производительностью: