Настройка параметраў ядра Linux для аптымізацыі PostgreSQL

Настройка параметраў ядра Linux для аптымізацыі PostgreSQL Аптымальная прадукцыйнасць 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* 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) = 1

SHM* 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 МПК для вылучэння падзялянай памяці. Гэты параметр з'яўляецца адным з найболей важных параметраў ядра. Кожны раз, калі вы атрымліваеце наступныя паведамленні пра памылкі, гэта азначае, што ў вас больш старая версія PostgreSQL і ў вас вельмі нізкае значэнне SHMMAX. Чакаецца, што карыстачы будуць карэктаваць і павялічваць значэнне ў адпаведнасці з падзялянай памяццю, якую яны збіраюцца выкарыстоўваць.

Магчымыя памылкі няправільнай канфігурацыі

Калі SHMMAX наладжаны няправільна, вы можаце атрымаць памылку пры спробе ініцыялізаваць кластар PostgreSQL з дапамогай каманды initdb.

initdb Failure
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 Failure
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

Вялікія старонкі (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 з апісаннем для кожнага:

  1. Эўрыстычны overcommit (па змаўчанні); заснаваная на ядры эўрыстыка
  2. Дазволіць overcommit у любым выпадку
  3. Не перашчыруйце, не перавышайце overcommit каэфіцыент.

спасылка: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio - працэнт аператыўнай памяці, даступнай для празмернай загрузкі. Значэнне 50% у сістэме з 2 ГБ АЗП можа вылучаць да 3 ГБ АЗП.

Значэнне 2 для vm.overcommit_memory забяспечвае лепшую прадукцыйнасць для PostgreSQL. Гэта значэнне максымізуе выкарыстанне аператыўнай памяці серверным працэсам без які-небудзь значнай рызыкі быць забітым працэсам 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. Гэта гарантуе, што фонавыя працэсы будуць запускацца раней, каб пазбегнуць максімальна магчымага блакавання прыкладання. Вы можаце наладзіць розніцу паміж гэтымі двума суадносінамі ў залежнасці ад загрузкі дыскавага ўводу-высновы.

Вынік

Вы можаце наладзіць іншыя параметры для павелічэння прадукцыйнасці, але паляпшэнні будуць мінімальнымі і выгады асаблівай не атрымаеце. Мы павінны памятаць, што не ўсе параметры адносяцца да ўсіх тыпаў прыкладанняў. Некаторыя прыкладанні працуюць лепш, калі мы наладжваем некаторыя параметры, а некаторыя - не. Вы павінны знайсці правільны баланс паміж канфігурацыямі гэтых параметраў для чаканай працоўнай нагрузкі і тыпу прыкладання, а таксама пры наладзе неабходна ўлічваць паводзіны АС. Наладзіць параметры ядра не так проста, як наладзіць параметры базы даных: тут складаней даваць свае рэкамендацыі.

Крыніца: habr.com

Дадаць каментар