Конфигурирање на опциите за кернелот на Linux за да се оптимизира PostgreSQL

Оптималната изведба на PostgreSQL зависи од правилно дефинираните параметри на оперативниот систем. Лошо конфигурираните поставки на кернелот на ОС може да резултираат со слаби перформанси на серверот на базата на податоци. Затоа, императив е овие поставки да се конфигурираат според серверот на базата на податоци и неговиот обем на работа. Во овој пост, ќе разговараме за некои важни параметри на кернелот на Линукс кои можат да влијаат на перформансите на серверот на базата на податоци и како да ги конфигурираат.

SHMMAX / SHMALL

SHMMAX е параметар на кернелот што се користи за одредување на максималната големина на еден сегмент на споделена меморија што може да го додели процесот на Linux. Пред верзијата 9.2, PostgreSQL користеше System V (SysV), за што е потребна поставка SHMMAX. По 9.2, PostgreSQL се префрли на споделена меморија на POSIX. Така, сега се потребни помалку бајти заедничка меморија на System V.

Пред верзијата 9.3, SHMMAX беше најважниот параметар на јадрото. Вредноста SHMMAX е наведена во бајти.

Слично на тоа SHMALL е уште еден параметар на јадрото што се користи за одредување
волумен на страници за споделена меморија низ целиот систем. За да ги видите тековните вредности 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. Големата големина на страницата може да се постави при подигање. Можете лесно да ги проверите параметрите на големите страници и нивната употреба на вашата машина Линукс користејќи ја командата мачка /proc/meminfo | греп -и огромен.

Добивање информации за големи страници (само за Линукс)

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

Сега поставете го параметарот large_pages на „вклучено“ во $PGDATA/postgresql.conf и рестартирајте го серверот.

Уште еднаш, информации за големи страници (само за Линукс)

$ 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

Ајде да видиме дали сега користиме повеќе големи страници отколку порано.

Повеќе информации за големите страници (само за Линукс)

$ 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.замена

vm.замена е уште еден параметар на јадрото кој може да влијае на перформансите на базата на податоци. Оваа опција се користи за контрола на однесувањето на замена (замена на страници во и надвор од меморијата) на Linux. Вредноста се движи од 0 до 100. Определува колкава количина на меморија ќе се страницира или исфрли. Нула значи дека нема размена, а 100 значи агресивна размена.

Може да добиете добри перформанси со поставување пониски вредности.

Поставувањето на ова на 0 на поновите кернели може да предизвика OOM Killer (процесот на чистење на меморијата на Линукс) да го убие процесот. Значи, безбедно е да го поставите на 1 ако сакате да го минимизирате менувањето. Стандардната вредност во Linux е 60. Повисоката вредност предизвикува MMU (единица за управување со меморија) да користи повеќе простор за размена од RAM меморијата, додека пониската вредност задржува повеќе податоци/код во меморијата.

Пониска вредност е добар залог за подобрени перформанси во PostgreSQL.

vm.overcommit_memory / vm.overcommit_ratio

Апликациите добиваат меморија и ја ослободуваат кога веќе не е потребна. Но, во некои случаи, апликацијата добива премногу меморија и не ја ослободува. Ова може да предизвика убиец на OOM. Еве ги можните вредности на параметрите vm.overcommit_memory со опис за секое:

1. Хеуристичко надминување (стандардно); хеуристика базирана на јадро
2. Како и да е, дозволете го прекумерното обврзување
3. Не претерувајте, не го надминувајте соодносот на overcommit.

Ссылка: 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 убиец. Апликацијата ќе може повторно да се вчита, но само во границите на пречекорување, што го намалува ризикот убиецот на OOM да го убие процесот. Затоа, вредноста 2 дава подобри перформанси од стандардната вредност од 0. Сепак, доверливоста може да се подобри ако се осигура дека меморијата надвор од опсегот не е преоптоварена. Ова го елиминира ризикот процесот да биде убиен од убиец на OOM.

На системи без замена, може да се појави проблем со 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 ќе ги измие валканите страници во заднина.

Треба да ја поставите вредноста 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. Ова осигурува дека процесите во заднина започнуваат порано за да се избегне блокирање на апликацијата колку што е можно повеќе. Можете да ја прилагодите разликата помеѓу овие два соодноси во зависност од оптоварувањето на В/И на дискот.

Вкупно

Можете да ги прилагодите другите поставки за да ги подобрите перформансите, но подобрувањата ќе бидат минимални и нема да видите голема корист. Мораме да запомниме дека не сите опции важат за сите видови апликации. Некои апликации работат подобро кога приспособуваме некои поставки, а некои не. Мора да ја пронајдете вистинската рамнотежа помеѓу конфигурирањето на овие поставки за очекуваниот обем на работа и типот на апликацијата, а исто така мора да го земете предвид однесувањето на ОС при подесување. Конфигурирањето на параметрите на јадрото не е толку лесно како конфигурирањето на параметрите на базата на податоци; потешко е да се даваат препораки.

Извор: www.habr.com