Настройка на опциите на ядрото на Linux за оптимизиране на PostgreSQL

Оптималната производителност на PostgreSQL зависи от правилно дефинираните параметри на операционната система. Лошо конфигурираните настройки на ядрото на ОС могат да доведат до лоша производителност на сървъра на базата данни. Следователно е наложително тези настройки да бъдат конфигурирани според сървъра на базата данни и неговото натоварване. В тази публикация ще обсъдим някои важни параметри на ядрото на Linux, които могат да повлияят на производителността на сървъра на базата данни и как да ги конфигурирате.

SHMMAX / SHMALL

SHMMAX е параметър на ядрото, използван за определяне на максималния размер на един споделен сегмент от паметта, който Linux процес може да разпредели. Преди версия 9.2 PostgreSQL използва System V (SysV), която изисква настройката SHMMAX. След 9.2 PostgreSQL премина към POSIX споделена памет. Така че сега са необходими по-малко байтове споделена памет на System V.

Преди версия 9.3 SHMMAX беше най-важният параметър на ядрото. Стойността SHMMAX е посочена в байтове.

По същия начин, МАЛКО е друг параметър на ядрото, използван за определяне
системен обем от страници със споделена памет. За да видите текущите стойности на SHMMAX, SHMALL или SHMMIN, използвайте командата ipcs.

SHM* Подробности - 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) = 1

SHM* Подробности - 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 Грешка
DETAIL: Failed system call was shmget(key=1, size=2072576, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. 
You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2072576 bytes),
reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration. child process exited with exit code 1

По същия начин може да получите грешка, когато стартирате PostgreSQL сървъра с помощта на командата pg_ctl.

pg_ctl Грешка
DETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.

You can either reduce the request size or reconfigure the kernel with larger SHMMAX.; To reduce the request size (currently 14385152 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about 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

Огромни страници

Linux използва 4 KB страници с памет по подразбиране, BSD използва XNUMX KB страници с памет. Супер страници, а на Windows - Големи страници. Страницата е част от RAM, разпределена за процес. Един процес може да има няколко страници в зависимост от изискванията за памет. Колкото повече памет изисква даден процес, толкова повече страници му се разпределят. ОС поддържа таблица за разпределение на страници за процеси. Колкото по-малък е размерът на страницата, толкова по-голяма е таблицата, толкова повече време отнема намирането на страница в тази таблица със страници. Следователно големите страници позволяват да се използват големи количества памет с намалени разходи; по-малко показвания на страници, по-малко грешки в страниците, по-бързи операции за четене/запис върху по-големи буфери. Резултатът е подобрена производителност.

PostgreSQL поддържа само големи страници на Linux. По подразбиране Linux използва страници с памет от 4 KB, така че в случаите, когато има твърде много операции с паметта, е необходимо да зададете по-големи страници. Подобрения в производителността се наблюдават при използване на големи страници от 2 MB и до 1 GB. Големият размер на страницата може да бъде зададен по време на зареждане. Можете лесно да проверите параметрите на голямата страница и тяхното използване на вашата Linux машина, като използвате командата котка /proc/meminfo | grep -i огромен.

Получаване на информация за големи страници (само за 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 MB), общият брой големи страници е зададен на 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 убиец. Ето възможните стойности на параметрите vm.overcommit_memory с описание за всеки:

1. Евристичен прекомерен ангажимент (по подразбиране); базирана на ядрото евристика
2. Все пак разрешете прекомерно ангажиране
3. Не прекалявайте, не превишавайте коефициента на прекомерно ангажиране.

за връзка: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio — процент на RAM, наличен за претоварване. Стойност от 50% за система с 2 GB RAM може да разпредели до 3 GB RAM.

Стойност 2 за vm.overcommit_memory осигурява по-добра производителност за PostgreSQL. Тази стойност максимизира използването на RAM на сървърния процес без значителен риск да бъде убит от OOM killer процеса. Приложението ще може да се презарежда, но само в границите на превишаване, което намалява риска OOM killer да убие процеса. Следователно стойност 2 дава по-добра производителност от стойността по подразбиране 0. Надеждността обаче може да се подобри, като се гарантира, че паметта извън обхвата не е претоварена. Това елиминира риска процесът да бъде убит от OOM killer.

При системи без суапинг може да възникне проблем с vm.overcommit_memory равно на 2.

https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

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. Това гарантира, че фоновите процеси започват по-рано, за да се избегне блокирането на приложението, доколкото е възможно. Можете да регулирате разликата между тези две съотношения в зависимост от I/O натоварването на диска.

Общо

Можете да промените други настройки, за да подобрите производителността, но подобренията ще бъдат минимални и няма да видите голяма полза. Трябва да помним, че не всички опции се отнасят за всички видове приложения. Някои приложения работят по-добре, когато коригираме някои настройки, а други не. Трябва да намерите точния баланс между конфигурирането на тези настройки за вашето очаквано работно натоварване и тип приложение, а също така трябва да имате предвид поведението на операционната система, когато настройвате. Конфигурирането на параметри на ядрото не е толкова лесно, колкото конфигурирането на параметри на база данни; по-трудно е да се дават препоръки.

Източник: www.habr.com