Повышение производительности: SLRU, BufferMapping

SLRU cache settings

Описание

В ядре PostgreSQL предусмотрены настройки размеров кеша SLRU с помощью новых GUC-параметры для того, чтобы узлы с высоким уровнем параллелизма и большими диапазонами идентификаторов транзакций («multixacts»/«subtransactions») в работе одновременно могли выиграть от увеличения объема кеша. Принцип определяется:

• Разделением кеша на «банки памяти» (терминология кеша CPU). Такие алгоритмы, как поиск «жертвы» при вытеснении страницы из буфера, влияют только на один конкретный «банк». Это устраняет проблему, связанную с тем, что линейный поиск определенного буфера во всем кеше (занимает слишком много времени). В данном подходе нужно просматривать только в определенном банке данных, размер которого невелик.
• Использованием каждого «банка» отдельного LWLock. Это позволяет повысить масштабируемость.

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

Настройка

Новые GUC-параметры соответствуют названиям, введенным в представлении pg_stat_slru.

Параметры можно задать:

• postgresql.conf для конфигурации сервера standalone;
• postgres.yml для конфигурации cluster;
• в командной строке при запуске сервера.

Конфигурационные параметры

Информация о параметрах представлена в интегрированном переведенном разделе оригинальной документации PostgreSQL. Читайте раздел «Потребление ресурсов» документа «Программирование и администрирование сервера PostgreSQL».

BufferMapping

Описание

Сведения

Функциональность доступна только для редакций Enterprise и Enterprise для ERP-систем.

В СУБД Pangolin страницы отношений хранятся в буферном кеше. Он располагается в общей памяти сервера и доступен всем процессам. Когда менеджеру буферов требуется прочитать страницу, он сначала пытается найти ее в буферном кеше. Для быстрого поиска нужного буфера используется хеш-таблица «Shared Buffer Lookup Table», хранящая номера буферов.

Для увеличения гранулярности хеш-таблица поделена на 128 частей (бакетов), доступ к каждой из которых защищается своей отдельной легкой блокировкой. Эти легкие блокировки объединены в последовательность блокировок LWLock::BufferMapping для данной хеш-таблицы. Перед обращением к хеш-таблице процесс должен захватить легкую блокировку, на которую выпал ключ хеширования: идентификатор файла отношения, тип слоя и номер страницы внутри файла этого слоя. Блокировка захватывается в двух режимах: в разделяемом режиме – для чтения и в исключительном – для изменений.

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

Настройка

В данной работе вводится новый GUC-параметр log2_num_buf_partitions для установки числа бакетов хеш-таблицы и, соответственно, количества легких блокировок в группе LWLock:BufferMapping. Увеличение значения параметра при интенсивной нагрузке позволяет снизить вероятность ожидания процессов на событии LWLock:BufferMapping за счет увеличения гранулярности блокировок.

Параметр можно задать:

• postgresql.conf для конфигурации сервера standalone;
• postgres.yml для конфигурации cluster;
• в командной строке при запуске сервера.

Изменение параметра требует перезапуска сервера.

Конфигурационные параметры

Параметр	Тип данных	Описание	Значение по умолчанию	Допустимые значения
log2_num_buf_partitions	integer	Задает число бакетов хеш-таблицы и, соответственно, количества легких блокировок в группе LWLock:BufferMapping	7 (128 частей)	7 (128 частей) – 16 (65536 частей) Значение параметра – это степень, в которую нужно возвести число 2, для получения фактического количества частей хеш-таблицы. Рекомендуемое значение на высокой нагрузке: 10-12