Назад | Перейти на главную страницу

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

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

У меня тоже мало квазий

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

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

grep Hugepagesize /proc/meminfo

Hugepagesize: 2048 kB

getconf PAGESIZE

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

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

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

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

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

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

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

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

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

Вопросы:

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

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

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

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

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

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

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

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

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

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