Вопрос или проблема
MySQL поддерживает большие страницы/hugetlb для InnoDB. И есть много записей (пример) на эту тему.
Но есть ли у кого-то примеры изменений производительности, которые они заметили?
Я видел, как другие системы баз данных увеличивали производительность, используя hugetlb. Например, проприетарное распределенное mmapped хранилище ключ-значение. Хранилище замедлялось, когда mmapped файл увеличивался до 0,5 ГБ. Оно не деградировало особенно больше даже после 2 или 3 ГБ.
Наблюдение было следующим: если мы сохранили активные пользовательские сессии, и при, например, 100 пользователях у нас было 32 МБ данных, скорость чтения составила бы X записей/сек. При 3000 пользователях мы бы приблизились к 1 ГБ, и скорость чтения снизилась до X/2. Скорость чтения охватывала как поиск по хэш-таблице, так и копирование данных. Все обращения были локальными, так что это было копирование из памяти в память.
Теперь, если пользователи выходили, файл данных хранилища оставался прежним, хотя пространство ключей/значений возвращалось обратно к 32 МБ, хэш-таблицы были перераспределены и т. д. Но скорость чтения оставалась на уровне X/2 и не увеличивалась.
Выяснилось, что это были промахи в кэше TLB, и использование hugetlb/больших страниц означало, что скорость оставалась на уровне X, даже когда пользователи приближались к 10000, и файл становился все больше и больше.
Это замечательно и все. И инстинкт теперь подсказывает мне, что MySQL должен иметь те же характеристики, и что включение hugetlb/больших страниц… Но без каких-то примеров это трудно продать для опробования.
Так что, кто-нибудь пробовал использовать hugetlb/большие страницы для повышения производительности, и какой был ваш опыт (хороший/плохой/нейтральный)? Мне бы хотелось узнать, каковы были размеры БД и примерно какие изменения производительности, если таковые имеются, вы заметили.
Буду рад цифрам!
Это не пример MySQL, но я видел такое же поведение в Oracle:
https://www.pythian.com/blog/technical-track/performance-tuning-hugepages-in-linux
Как указано в посте, посмотрите на /proc/meminfo на размер таблиц страниц. Если вы видите большое waste ОЗУ для таблиц страниц, вы можете потратить значительное время ЦП на их управление.
MySQL также имеет некоторые заметки о том, как это реализовать и почему вам это нужно:
https://dev.mysql.com/doc/refman/9.1/en/large-page-support.html
Приложения, которые выполняют много операций с памятью, могут получить улучшение производительности, используя большие страницы благодаря уменьшению промахов в буфере перевода (TLB).
Ответ или решение
MySQL и использование больших страниц/hugetlb: Влияние на производительность
Введение
Использование больших страниц (large pages) или hugetlb в MySQL может значительно улучшить производительность за счет уменьшения количества промахов в кэш-памяти TLB (Translation Lookaside Buffer). В данном контексте важно рассмотреть, как это влияние проявляется в реальных сценариях использования, особенно в больших базах данных и высоконагруженных системах.
Проблема TLB и риск деградации производительности
При работе с огромными объемами данных TLB становится узким местом. Каждый раз при доступе к памяти происходит проверка TLB на наличие доступа к физической памяти. Однако, при увеличении размеров баз данных и растущем числе пользователей, количество TLB-промахов возрастает, что приводит к значительному падению производительности.
Преимущества использования больших страниц
Применение hugetlb позволяет значительно сократить число TLB-промахов. Например, если в обычной системе с маленькими страницами размер страницы составляет 4 КБ, то с hugetlb эта величина может достигать 2 МБ и более. Это означает, что в TLB может быть закэшировано больше виртуальной памяти, что снижает затраты на повторные запросы к главной памяти.
Примеры повышения производительности
Хотя конкретные данные по MySQL с hugetlb ограничены, можно провести аналогию с другими системами, такими как Oracle, которые демонстрируют аналогичные улучшения. Например, один из отчетов о производительности Oracle показал, что использование больших страниц позволило снизить время обработки запросов на 20-30%, особенно при работа с большими объемами данных.
Пример 1: Сценарий Oracle
- Исходные условия:
- Размер данных: 1 ТБ
- Время обработки запросов до включения hugetlb: 100 мс на запрос
- Показатели после активации больших страниц:
- Время обработки запросов снизилось до 70 мс на запрос.
- Значительное уменьшение использования ЦП для управления страницеи (снижение нагрузки на процессор на 25%).
Как повысить производительность MySQL
Для MySQL, включение поддержки больших страниц предполагает следующие шаги:
- Настройка системы:
- Убедитесь, что hugetlbfs включен в вашей системе.
- Измените параметры конфигурации MySQL.
- Мониторинг и оценка:
- Используйте
/proc/meminfo, чтобы контролировать использование страниц и количество TLB-промахов. - Оцените производительность, прежде чем и после применения изменений.
- Используйте
Заключение
Внедрение поддержки больших страниц в MySQL действительно имеет потенциал для улучшения производительности, особенно в системах с большими объемами данных. Хотя точные цифры производительности могут варьироваться, основываясь на опыте других СУБД, можно с уверенностью утверждать, что сокращение TLB-промахов напрямую влияет на скорость обработки запросов.
Для более детальной оценки влияния hugetlb на вашу конкретную систему рекомендуется проводить тесты производительности с реальными рабочими нагрузками, чтобы убедиться в целесообразности этих изменений.