Оптималната производителност на 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, използвайте командата ipcs.
SHM* Подробности — Linux
$ ipcs -lm
------ Ограничения на споделената памет --------
максимален брой сегменти = 4096
макс. размер на сегмент (кбайта) = 1073741824
макс. обща споделена памет (кбайта) = 17179869184
мин. размер на сегмент (байта) = 1SHM* Подробности — MacOS X
$ ipcs -M
IPC статус от на с Б като Четвъртък, 16 Авг 2018 22:20:35 PKT
shminfo:
shmmax: 16777216 (макс.size споделен сегмент памет)
shmmin: 1 (мин. споделен сегмент памет)
shmmni: 32 (макс.броя на идентификатори за споделена памет)
shmseg: 8 (макс.споделени сегменти памет на процес)
shmall: 1024 (макс. количество споделена памет в страници)
PostgreSQL използва System V IPC за заделяне на споделена памет. Този параметър е един от най-важните параметри на ядрото. Всяко път, когато получавате следните съобщения за грешки, това означава, че имате по-стара версия на PostgreSQL и много ниска стойност на SHMMAX. Очаква се потребителите да регулират и увеличат стойността в съответствие с споделената памет, която възнамеряват да използват.
Възможни грешки при неправилна конфигурация
Ако SHMMAX е неправилно конфигуриран, може да получите грешка при опит за инициализиране на кластера PostgreSQL с помощта на командата initdb.
Неуспех на initdb
ДЕТАЙЛ: Неуспешен системен повик беше shmget(key=1, size=2072576, 03600).
СЪВЕТ: Тази грешка обикновено означава, че искането на PostgreSQL за сегмент на споделена памет надхвърли параметъра SHMMAX на вашето ядро.
Можете или да намалите размера на запитването, или да преподредите ядрото с по-голям SHMMAX. За да намалите размера на запитването (в момента 2072576 байта),
намалете използването на обща памет от PostgreSQL, може би чрез намаляване на shared_buffers или max_connections.
Ако размерът на запитването вече е малък, е възможно той да е по-малък от параметъра SHMMIN на вашето ядро,
в такъв случай е необходимо да се увеличи размерът на запитването или да се преподреди SHMMIN.
Документацията на PostgreSQL съдържа повече информация относно конфигурацията на обща памет. Процесът на дете затвори с код на прекратяване 1
Подобно, можете да получите грешка при стартиране на сървъра PostgreSQL, използвайки командата pg_ctl.
pg_ctl Неуспех
ДЕТАЙЛ: Неуспешен системен повик беше shmget(key=5432001, size=14385152, 03600).
СЪВЕТ: Тази грешка обикновено означава, че искането на PostgreSQL за сегмент на споделена памет надхвърли параметъра SHMMAX на вашето ядро.
Можете или да намалите размера на запитването, или да преподредите ядрото с по-голям SHMMAX.; За да намалите размера на запитването (в момента 14385152 байта), намалете използването на обща памет от PostgreSQL, може би чрез намаляване на shared_buffers или max_connections.
Ако размерът на запитването вече е малък, е възможно той да е по-малък от параметъра SHMMIN на вашето ядро,
в такъв случай е необходимо да се увеличи размерът на запитването или да се преподреди SHMMIN.
Документацията на PostgreSQL съдържа повече информация относно конфигурацията на обща памет.
Разбиране на разликите в определенията
Определението на параметрите 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 — Големи страници. Страницата е част от оперативната памет, отделена на процеса. Процесът може да има няколко страници в зависимост от изискванията за памет. Колкото повече памет изисква процесът, толкова повече страници му се отделят. ОС поддържа таблица за разпределение на страниците за процесите. Колкото по-малък е размерът на страницата, толкова по-голяма е таблицата, толкова повече време отнема за търсене на страница в тази таблица за страници. Следователно, големите страници позволяват използването на голям обем памет с намалени разходи; по-малко преглеждания на страници, по-малко грешки на страници, по-бързи операции за четене/запис чрез големи буфери. В резултат на това — подобряване на производителността.
PostgreSQL поддържа големи страници само в Linux. По подразбиране Linux използва 4 КБ страници памет, затова в случаи, когато има много операции с памет, е необходимо да се зададат страници с по-голям размер. Наблюдава се увеличение на производителността при използване на големи страници с размер 2 МБ до 1 ГБ. Размерът на голямата страница може да бъде зададен при стартиране. Можете лесно да проверите параметрите на голямата страница и тяхното използване на вашия Linux компютър, използвайки командата cat /proc/meminfo | grep -i huge.
Получаване на информация за големи страници (само в Linux)
Забележка: Това важи само за Linux, за другите ОС тази операция се игнорира$ 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 (блок за управление на паметта) да използва повече пространство за сваткване, отколкото RAM, докато по-ниската стойност запазва повече данни/код в паметта.
По-ниската стойност е добра ставка за подобряване на производителността в PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Приложенията получават памет и я освобождават, когато вече не им е нужна. Но в някои случаи приложението получава твърде много памет и не я освобождава. Това може да предизвика OOM killer. Ето възможните стойности на параметъра vm.overcommit_memory с описание за всяка:
- Евристичен overcommit (по подразбиране); базирана на ядрото евристика
- Позволете overcommit във всеки случай
- Не прекалявайте, не надвишавайте коефициента на overcommit.
Връзка:
vm.overcommit_ratio — процент оперативната памет, достъпна за прекомерно натоварване. Стойността 50% в система с 2 ГБ RAM може да осигури до 3 ГБ RAM.
Стойността 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
