Оптимальна продуктивність PostgreSQL залежить від правильно визначених параметрів операційної системи. Погано налаштовані параметри ядра ОС можуть призвести до зниження продуктивності сервера бази даних. Тому обов'язково, щоб ці параметри були налаштовані відповідно до сервера бази даних та його робочого навантаження. У цьому пості ми обговоримо деякі важливі параметри ядра Linux, которые могут повлиять на производительность сервера базы данных и способы их настройки.
SHMMAX/SHMALL
SHMMAX — это параметр ядра, используемый для определения максимального размера одного сегмента разделяемой памяти (shared memory), который может выделить процесс Linux. До версии 9.2 PostgreSQL использовал System V (SysV), для которой требуется настройка SHMMAX. После 9.2 PostgreSQL переключился на разделяемую память POSIX. Так что теперь требуется меньше байтов разделяемой памяти System V.
До версії 9.3 SHMMAX був найважливішим параметром ядра. Значення SHMMAX визначається в байтах.
аналогічно, SHMALL — це ще один параметр ядра, який використовується для визначення
загальносистемного обсягу сторінок пам'яті, що розділяється (shared memory). Щоб переглянути поточні значення SHMMAX, SHMALL або SHMMIN, використовуйте команду шт.
SHM* Details — Linux
$ ipcs -lm
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 1073741824
max total shared memory (kbytes) = 17179869184
min seg size (bytes) = 1SHM* Details — MacOS X
$ ipcs -M
IPC status from as of Thu Aug 16 22:20:35 PKT 2018
shminfo:
shmmax: 16777216 (max shared memory segment size)
shmmin: 1 (min shared memory segment size)
shmmni: 32 (max number of shared memory identifiers)
shmseg: 8 (max shared memory segments per process)
shmall: 1024 (max amount of shared memory in pages)
PostgreSQL використовує Система V IPC для виділення пам'яті, що розділяється. Цей параметр є одним із найважливіших параметрів ядра. Щоразу, коли ви отримуєте такі повідомлення про помилки, це означає, що у вас більш стара версія PostgreSQL і у вас дуже низьке значення SHMMAX. Очікується, що користувачі будуть коригувати і збільшувати значення відповідно до пам'яті, яку вони збираються використовувати.
Можливі помилки неправильної конфігурації
Якщо SHMMAX неправильно налаштований, ви можете отримати помилку при спробі ініціалізувати кластер PostgreSQL за допомогою команди initdb.
initdb Failure
DETAIL: Failed system call was shmget(key=1, size=2072576, 03600).
HINT: Цей error є звичайним способом, що PostgreSQL's request for shared memory segment exceeded your kernel's SHMMAX parameter.
Ви можете змінити цю потрібну величину або змінити кернал з великим SHMMAX. Щоб зменшити значення потреби (в даний час 2072576 bytes),
reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
Якщо потрібна величина є більшою малою, це може бути, що це неправильно, якщо ваш kernel's SHMMIN parameter,
У якому випадку, коли мова йде про те, що потрібно, або зміна SHMMIN є названою для.
The PostgreSQL документація містить більше інформації про shared memory configuration. Child process exited with exit code 1
Аналогічно, ви можете отримати помилку під час запуску сервера PostgreSQL, використовуючи команду pg_ctl.
pg_ctl Failure
DETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).
HINT: Цей error є звичайним способом, що PostgreSQL's request for shared memory segment exceeded your kernel's SHMMAX parameter.
Ви можете змінити потрібне значення або змінити рядок з великим SHMMAX.
Якщо потрібна величина є більшою малою, це може бути, що це неправильно, якщо ваш kernel's SHMMIN parameter,
У якому випадку, коли мова йде про те, що потрібно, або зміна SHMMIN є названою для.
The PostgreSQL документація містить більше інформації про shared memory configuration.
Розуміння відмінностей у визначеннях
Определение параметров SHMMAX/SHMALL немного отличается в Linux и MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
Команда Sysctl може бути використана для тимчасової зміни значення. Щоб встановити постійні значення, додайте запис до /etc/sysctl.conf. Подробиці наведено нижче.
Зміна параметрів ядра на MacOS X
# Get the value of SHMMAX
sudo sysctl kern.sysv.shmmax
kern.sysv.shmmax: 4096
# Get the value of SHMALL
sudo sysctl kern.sysv.shmall
kern.sysv.shmall: 4096
# Set the value of SHMMAX
sudo sysctl -w kern.sysv.shmmax=16777216
kern.sysv.shmmax: 4096 -> 16777216
# Set the value of SHMALL
sudo sysctl -w kern.sysv.shmall=16777216
kern.sysv.shmall: 4096 -> 16777216Изменение параметров ядра на Linux
# Get the value of SHMMAX
sudo sysctl kernel.shmmax
kernel.shmmax: 4096
# Get the value of SHMALL
sudo sysctl kernel.shmall
kernel.shmall: 4096
# Set the value of SHMMAX
sudo sysctl -w kernel.shmmax=16777216
kernel.shmmax: 4096 -> 16777216
# Set the value of SHMALL
sudo sysctl -w kernel.shmall=16777216
kernel.shmall: 4096 -> 16777216Не забудьте: щоб зробити зміни постійними, додайте ці значення /etc/sysctl.conf
Великі сторінки (Huge Pages)
В Linux по умолчанию используются страницы памяти 4 КБ, в BSD — Супер-сторінки, А в Windows - Large Pages. Сторінка - це частина оперативної пам'яті, виділена процесу. Процес може мати кілька сторінок, залежно від вимог до пам'яті. Що більше пам'яті потрібно процесу, то більше сторінок йому виділено. ОС підтримує таблицю виділення сторінок процесів. Чим менший розмір сторінки, тим більше таблиця, тим більше часу потрібно для пошуку сторінки у цій таблиці сторінок. Тому великі сторінки дозволяють використовувати великий обсяг пам'яті зі зменшеними витратами накладних; менше переглядів сторінок, менше помилок сторінок, швидші операції читання/запису через великі буфери. Як результат – покращення продуктивності.
PostgreSQL поддерживает большие страницы только в Linux. За замовчуванням Linux использует 4 КБ страниц памяти, поэтому в случаях, когда операций с памятью слишком много, необходимо устанавливать страницы большего размера. Наблюдается прирост производительности при использовании больших страниц размером 2 МБ и до 1 ГБ. Размер большой страницы может быть установлен во время загрузки. Вы можете легко проверить параметры большой страницы и их использование на вашем Linux-компьютере, используя команду cat /proc/meminfo | grep -i huge.
Получение информации о больших страницах (только на Linux)
Note: This is only for Linux, for other OS this operation is ignored$ cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kBУ цьому прикладі, хоча розмір великої сторінки встановлено в 2048 (2 МБ), загальна кількість великих сторінок має значення 0. Це означає, що великі сторінки вимкнено.
Скрипт визначення кількості великих сторінок
Это простой скрипт возвращает необходимое количество больших страниц. Запустите скрипт на вашем сервере Linux, пока работает PostgreSQL. Убедитесь, что для переменной среды $PGDATA заданий каталог даних PostgreSQL.
Отримання цифри потрібних великих сторінок
#!/bin/bash
pid=`head -1 $PGDATA/postmaster.pid`
echo "Pid: $pid"
peak=`grep ^VmPeak /proc/$pid/status | awk '{ print $2 }'`
echo "VmPeak: $peak kB"
hps=`grep ^Hugepagesize /proc/meminfo | awk '{ print $2 }'`
echo "Hugepagesize: $hps kB"
hp=$((peak/hps))
echo Set Huge Pages: $hpВисновок скрипта виглядає так:
Висновок скрипту
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88Значення великих сторінок, що рекомендується, — 88, тому ви повинні встановити значення 88.
Встановлення великих сторінок
sysctl -w vm.nr_hugepages=88Перевірте великі сторінки, ви побачите, що великі сторінки не використовуються (HugePages_Free = HugePages_Total).
Снова информация о больших страницах (только на Linux)
$ cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 88
HugePages_Free: 88
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kBТепер задайте параметр huge_pages on у $PGDATA/postgresql.conf і перезапустіть сервер.
И снова информация о больших страницах (только на Linux)
$ cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 88
HugePages_Free: 81
HugePages_Rsvd: 64
HugePages_Surp: 0
Hugepagesize: 2048 kBТепер ви можете бачити, що використовуються дуже мало великих сторінок. Давайте спробуємо додати деякі дані до бази даних.
Деякі операції з базою даних для утилізації великих сторінок
postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000Давайте подивимося, чи ми зараз більше великих сторінок, ніж раніше.
Еще раз информация о больших страницах (только на Linux)
$ cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 88
HugePages_Free: 18
HugePages_Rsvd: 1
HugePages_Surp: 0
Hugepagesize: 2048 kBТепер ви можете бачити, що більшість великих сторінок використовується.
Примітка: Приблизне значення HugePages, що використовується тут, дуже низьке, що не є нормальним значенням для машини на продуктовому середовищі. Будь ласка, оцініть необхідну кількість сторінок для вашої системи та встановіть їх відповідно в залежності від навантаження та ресурсів.
vm.swappiness
vm.swappiness — это еще один параметр ядра, который может влиять на производительность базы данных. Этот параметр используется для управления поведением подкачки (swappiness) (подкачки страниц в память и из нее) в Linux. Значение варьируется от 0 до 100. Он определяет, сколько памяти будет выгружено или выгружено. Ноль означает отключение обмена, а 100 означает агрессивный обмен.
Ви можете отримати хорошу продуктивність, встановивши нижчі значення.
Установка значения 0 в более новых ядрах может привести к тому, что OOM Killer (процесс очистки памяти в Linux) убьет процесс. Таким образом, можно безопасно установить значение 1, если хотите минимизировать подкачку. Значение по умолчанию в Linux — 60. Более высокое значение заставляет MMU (блок управления памятью) использовать больше пространства подкачки, чем ОЗУ, тогда как более низкое значение сохраняет больше данных/кода в памяти.
Найменше значення – хороша ставка на покращення продуктивності в PostgreSQL.
vm.overcommit_memory/vm.overcommit_ratio
Програми отримують пам'ять та звільняють її, коли вона більше не потрібна. Але в деяких випадках програма отримує занадто багато пам'яті і не звільняє її. Це може спричинити OOM killer. Ось можливі значення параметра vm.overcommit_memory з описом для кожного:
- Евристичний overcommit (за умовчанням); заснована на ядрі евристика
- Дозволити overcommit у будь-якому випадку
- Чи не перестарайтеся, не перевищуйте overcommit коефіцієнт.
Посилання:
vm.overcommit_ratio - Відсоток оперативної пам'яті, доступної для надмірного завантаження. Значення 50% у системі з 2 ГБ ОЗП може виділяти до 3 ГБ ОЗП.
Значення 2 для vm.overcommit_memory забезпечує найкращу продуктивність для PostgreSQL. Це значення максимізує використання оперативної пам'яті серверним процесом без значного ризику бути вбитим процесом OOM killer. Програма зможе перезавантажуватись, але тільки в межах перевитрати, що знижує ризик того, що OOM killer уб'є процес. Отже, значення 2 дає кращу продуктивність, ніж значення за умовчанням 0. Тим не менш, надійність може бути покращена за рахунок того, що пам'ять за межами допустимого діапазону не буде перевантажена. Це унеможливлює ризик того, що процес буде вбитий OOM-killer.
У системах без підкачки може виникнути проблема з vm.overcommit_memory 2.
vm.dirty_background_ratio/vm.dirty_background_bytes
vm.dirty_background_ratio — это процент памяти, заполненной грязными страницами, которые необходимо записать на диск. Сброс на диск производится в фоновом режиме. Значение этого параметра колеблется от 0 до 100; однако значение ниже 5 может быть неэффективным, и некоторые ядра его не поддерживают. 10 — значение по умолчанию в большинстве систем Linux. Вы можете повысить производительность для операций с интенсивной записью с меньшим коэффициентом, который будет означать, что Linux будет сбрасывать грязные страницы в фоновом режиме.
Вам потрібно встановити значення vm.dirty_background_bytes залежно від швидкості диска.
Для цих двох параметрів немає «хороших» значень, оскільки обидва залежать від апаратного забезпечення. Однак установка vm.dirty_background_ratio на значення 5 і vm.dirty_background_bytes в 25% від швидкості диска, підвищує продуктивність до ~ 25% у більшості випадків.
vm.dirty_ratio/dirty_bytes
Це те ж саме, що vm.dirty_background_ratio/dirty_background_bytes, крім того, що скидання виконується в робочому сеансі, блокуючи додаток. Тому vm.dirty_ratio має бути вищим, ніж vm.dirty_background_ratio. Це гарантує, що фонові процеси запускатимуться раніше, щоб уникнути максимально можливого блокування програми. Ви можете налаштувати різницю між цими двома співвідношеннями залежно від завантаження дискового вводу-виводу.
Підсумок
Ви можете налаштувати інші параметри для збільшення продуктивності, але покращення будуть мінімальними і вигоди особливої не отримаєте. Ми повинні пам'ятати, що не всі параметри стосуються всіх типів програм. Деякі програми працюють краще, коли ми налаштовуємо деякі параметри, а деякі ні. Ви повинні знайти правильний баланс між конфігураціями цих параметрів для очікуваного робочого навантаження та типу програми, а також при налаштуванні необхідно враховувати поведінку ОС. Налаштувати параметри ядра не так просто, як налаштувати параметри бази даних: тут важче давати свої рекомендації.
Джерело: habr.com
