как узнать, должны ли мои серверы использовать огромные страницы (размер страницы памяти)

как узнать, должны ли мои серверы использовать огромные страницы (размер страницы памяти)

у нас есть несколько серверов в кластере, и мы хотим знать, в каких случаях нам вообще нужно настраивать огромные страницы?

У меня также есть несколько вопросов.

  1. доза «размер страницы памяти» равна Огромным страницам?

На моем сервере Linux я ввел следующую команду, чтобы проверить размер страницы памяти по умолчанию

grep Hugepagesize /proc/meminfo

Hugepagesize: 2048 kB

getconf PAGESIZE

4096
  1. Но как все видят, мы получаем разные результаты. Почему?

  2. Каковы риски при использовании огромных страниц?

  3. доза Отключить прозрачную огромную страницу - означает отключить опцию ОГРОМНЫЕ СТРАНИЦЫ?

решение1

Огромные страницы интересны, когда приложениям нужны большие отображения, к которым они будут делать случайный доступ, потому что это худший возможный случай для буфера Translation Lookaside (TLB). Вы жертвуете гранулярностью отображения для записей TLB.

Страницы, включая hugepages, могут быть сопоставлены только с блоком физической памяти того же размера и выровнены по этому размеру. Таким образом, hugepage размером 2 МБ необходимо сопоставить с границей 2 МБ в физической памяти, а hugepage размером 1 ГБ необходимо сопоставить с границей 1 ГБ, поскольку младшие биты адресуют данные внутри страницы, и здесь нельзя добавить смещение.

Это означает, что hugepages обычно резервируются при запуске системы, когда физическая память еще не фрагментирована. Приложения, которые знают о hugepage, могут использовать их hugetlbfsдля их выделения.

Вам нужно решить с помощью параметра ядра, должны ли огромные страницы быть размером 2 МБ или 1 ГБ, вы не можете смешивать их. Обычные страницы размером 4 КБ всегда доступны.

Наиболее распространенным вариантом использования являются виртуальные машины (qemu/kvm могут использовать hugepages), где это позволяет хранить все отображение памяти виртуальной машины в небольшом количестве записей TLB, которые, следовательно, никогда не удаляются, поэтому доступ к памяти внутри виртуальной машины требует поиска в таблице страниц только внутри гостевого контекста.

Некоторые системы баз данных также поддерживают огромные страницы, но это, как правило, полезно только при работе с большими наборами данных и индексами.

Вопросы:

  1. Существуют обычные (4 КБ) страницы и огромные (2 МБ или 1 ГБ) страницы. Когда вы запрашиваете размер страницы, вы получаете размер для обычных страниц, когда вы запрашиваете огромный размер страницы, вы получаете настройку для огромных страниц. И обычные, и огромные страницы могут использоваться параллельно, но вы не можете смешивать разные размеры огромных страниц.

  2. Вы получаете разные результаты, потому что это две разные вещи. Размер обычных страниц фиксируется на аппаратном уровне, поэтому это не настройка.

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

  4. Прозрачные огромные страницы пытаются сделать память доступной в качестве буферов и кэшей (в отличие от #3) и пытаются предоставить огромные страницы приложениям, отображающим большие блоки памяти, чтобы приложения, не поддерживающие огромные страницы, все равно могли извлечь из них выгоду — в основном, приложению, запрашивающему блок памяти размером 2 МБ/1 ГБ, будет предоставлена ​​огромная страница, если это возможно. Помогает это или ухудшает производительность, зависит от ваших приложений. Если у вас есть приложение, поддерживающее огромные страницы, и вы хотите вручную назначить память, вам нужно отключить THP, в то время как система с приложением базы данных, не поддерживающим огромные страницы, скорее всего, выиграет.

решение2

Очевидные случаи использования огромных страниц — когда PageTables (видимые в /proc/meminfo) становятся десятками ГБ. Это означает большие накладные расходы памяти и ЦП только на отслеживание памяти. Это происходит с гигантскими кусками памяти, большим количеством процессов или и тем, и другим. Часто в приложениях баз данных.

Огромные страницы значительно сокращают эти накладные расходы, поскольку теперь одна запись таблицы страниц адресует гораздо больше памяти, скажем, 2048 КБ вместо 4 КБ. (На других платформах существуют другие размеры, например, AIX на POWER поддерживает большие страницы размером 16 МБ.)

Огромные страницы в Linux не могут использоваться для кэширования файлов, и раздражают и неэффективны для пары МБ для malloc() для неразделяемой памяти. Поэтому администратору приходится выделять огромные пулы страниц, которые могут использоваться только для некоторых целей. Это недостаток использования огромных страниц.

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

И последнее замечание по поводу огромных страниц в Linux: мне кажется раздражающим управление ими.

  • Общая память использует один интерфейс, а для остальных используется библиотека hugetlbfs и файловая система.
  • Вы можете «тратить впустую» память, выделяя слишком большие страницы и не настраивая приложение на ее использование.
  • Это количество страниц необходимо масштабировать в соответствии с размером каждого хоста, поскольку это количество страниц, а не процент памяти.
  • Часто возможность выделения больших страниц ограничивается нахождением в одной группе, переключение пользователей базы данных может привести к неожиданной трате памяти.

Связанный контент