Optimuma agado de PostgreSQL dependas de taŭge difinitaj agordoj de operaciumo. Malbone agorditaj OS-kernaj parametroj povas konduki al malrapida agado de la datumbaza servilo. Tial, estas nepre, ke ĉi tiuj agordoj estu agordita laŭ la datumbaza servilo kaj ĝia laborkvanto. En ĉi tiu afiŝo, ni diskutos kelkajn el la gravaj Linukso-kernaj parametroj, kiuj povas influi datumbazan servilon kaj kiel agordi ilin.
SHMMAX / SHMALL
SHMMAX estas kernparametro uzata por determini la maksimuman grandecon de ununura komuna memorsegmento kiun Linuksa procezo povas asigni. Antaŭ versio 9.2, PostgreSQL uzis System V (SysV), kiu postulas la agordon SHMMAX. Post 9.2 PostgreSQL ŝanĝis al POSIX komuna memoro. Do nun necesas malpli da bajtoj de komuna memoro Sistemo V.
Antaŭ versio 9.3, SHMMAX estis la plej grava kerna parametro. La SHMMAX-valoro estas donita en bajtoj.
Simile, SHMALL estas alia kerna parametro uzata por determini
tuta sistema grandeco de komunaj memorpaĝoj. Por vidi la nunajn valorojn SHMMAX, SHMALL aŭ SHMMIN, uzu la komandon ipcs.
SHM* Detaloj - Linukso
$ 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* Detaloj - 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 uzas Sistemo V IPC por asigni komunan memoron. Ĉi tiu agordo estas unu el la plej gravaj kernaj opcioj. Kiam ajn vi ricevas la jenajn erarmesaĝojn, tio signifas, ke vi havas pli malnovan version de PostgreSQL kaj havas tre malaltan SHMMAX-valoron. Uzantoj estas atenditaj alĝustigi kaj pliigi la valoron laŭ la komuna memoro, kiun ili intencas uzi.
Eblaj Misagordaj Eraroj
Se SHMMAX estas malĝuste agordita, vi povas ricevi eraron kiam vi provas pravalorigi PostgreSQL-grupon per la komando. initdb.
initdb Fiasko
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
Simile, vi povas ricevi eraron kiam vi ekfunkciigas la PostgreSQL-servilon per la komando pg_ctl.
pg_ctl Fiasko
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.
Komprenante Diferencoj en Difinoj
La difino de SHMMAX/SHMALL-opcioj estas iomete malsama en Linukso kaj MacOS X:
- Linukso: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
teamo sysctl povas esti uzata por provizore ŝanĝi la valoron. Por agordi konstantajn valorojn, aldonu eniron al /etc/sysctl.conf. Detaloj estas sube.
Ŝanĝi Kernelajn Opciojn ĉe 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Ŝanĝante Kernelajn Opciojn en Linukso
# 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 -> 16777216Ne forgesu: por fari ŝanĝojn konstantaj aldonu ĉi tiujn valorojn al /etc/sysctl.conf
Grandegaj Paĝoj
Linukso defaŭlte al 4 KB-paĝoj, BSD defaŭlte Bonegaj Paĝoj, kaj sur Vindozo Grandaj Paĝoj. Paĝo estas parto de RAM asignita al procezo. Procezo povas havi plurajn paĝojn depende de memorpostuloj. Ju pli da memoro bezonas procezo, des pli da paĝoj estas asignitaj al ĝi. La OS konservas paĝan asignotabelon por procezoj. Ju pli malgranda la paĝa grandeco, des pli granda la tabelo, des pli longe necesas serĉi paĝon en tiu paĝa tabelo. Tial grandaj paĝoj permesas uzi grandan kvanton da memoro kun reduktita superkompeto; malpli da paĝvidoj, malpli da paĝaj misfunkciadoj, pli rapidaj leg-/skribaj operacioj per pli grandaj bufroj. La rezulto estas plibonigita rendimento.
PostgreSQL nur subtenas grandajn paĝojn en Linukso. Defaŭlte, Linukso uzas 4 KB da memorpaĝoj, do en kazoj kie estas tro da memoroperacioj, necesas instali pli grandajn paĝojn. Estas pliiĝo en rendimento kiam oni uzas grandajn paĝojn de 2 MB kaj ĝis 1 GB. Granda paĝa grandeco povas esti agordita je ŝarĝo. Vi povas facile kontroli la grandajn paĝajn opciojn kaj ilian uzadon en via Linuksa maŝino uzante la komandon kato /proc/meminfo | grep -i grandega.
Akiri informojn pri grandaj paĝoj (nur Linukso)
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 kBEn ĉi tiu ekzemplo, kvankam la granda paĝa grandeco estas agordita al 2048 (2 MB), la totala nombro de grandaj paĝoj estas 0. Tio signifas, ke grandaj paĝoj estas malŝaltitaj.
Skripto por determini la nombron da grandaj paĝoj
Ĉi tiu simpla skripto resendas la bezonatan nombron da grandaj paĝoj. Rulu la skripton sur via Linuksa servilo dum PostgreSQL funkcias. Certiĝu, ke la mediovariablo estas agordita al $PGDATA la datumdosierujo de PostgreSQL estas specifita.
Akiri la Nombron de Grandaj Paĝoj Bezonataj
#!/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: $hpLa eligo de la skripto aspektas jene:
Skripto Eligo
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88La rekomendinda valoro por grandaj paĝoj estas 88, do vi devus agordi ĝin al 88.
Instalante grandajn paĝojn
sysctl -w vm.nr_hugepages=88Kontrolu grandajn paĝojn nun, vi vidos, ke neniuj grandaj paĝoj estas uzataj (HugePages_Free = HugePages_Total).
Grandaj paĝaj informoj denove (nur Linukso)
$ 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 kBNun agordu la opcion huge_pages al "on" en $PGDATA/postgresql.conf kaj rekomencu la servilon.
Grandaj Paĝaj Informoj Denove (nur en Linukso)
$ 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 kBNun vi povas vidi, ke tre malmultaj grandaj paĝoj estas uzataj. Ni provu nun aldoni kelkajn datumojn al la datumbazo.
Iuj datumbazaj operacioj por recikli grandajn paĝojn
postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000Ni vidu, ĉu ni nun uzas pli grandajn paĝojn ol ni antaŭe.
Pliaj informoj pri grandaj paĝoj (nur Linukso)
$ 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 kBNun vi povas vidi, ke la plej multaj el la grandaj paĝoj estas uzataj.
Noto: La ekzempla valoro por HugePages uzata ĉi tie estas tre malalta, kio ne estas normala por produktmaŝino. Bonvolu taksi la bezonatan nombron da paĝoj por via sistemo kaj agordi ilin laŭe laŭ la ŝarĝo kaj rimedoj.
vm.swappiness
vm.swappiness estas alia kerna agordo kiu povas influi datumbazan rendimenton. Ĉi tiu agordo estas uzata por kontroli la interŝanĝan konduton (paĝigado de paĝoj en kaj el memoro) en Linukso. La valoro varias de 0 ĝis 100. Ĝi determinas kiom da memoro estos paĝita aŭ malŝarĝita. Nulo signifas neniun kundividon, kaj 100 signifas agreseman kundividon.
Vi povas akiri bonan rendimenton fiksante pli malaltajn valorojn.
Agordi ĝin al 0 sur pli novaj kernoj povas kaŭzi la OOM Killer (la memorpuriga procezo de Linukso) mortigi la procezon. Do estas sekure agordi la valoron al 1 se vi volas minimumigi paĝigon. La defaŭlta valoro en Linukso estas 60. Pli alta valoro igas la MMU (Memory Management Unit) uzi pli da interŝanĝa spaco ol RAM, dum pli malalta valoro konservas pli da datumoj/kodon en memoro.
Pli malalta valoro estas bona veto por agado-plibonigoj en PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Aplikoj akiras memoron kaj liberigas ĝin kiam ĝi ne plu bezonas. Sed en iuj kazoj, la aplikaĵo ricevas tro da memoro kaj ne liberigas ĝin. Ĉi tio povas ekigi OOM-murdinton. Jen la eblaj parametraj valoroj vm.overcommit_memory kun priskribo por ĉiu:
- Heŭristika trokomisi (defaŭlte); heŭristiko bazita en kerno
- Permesu superengaĝiĝon ĉiuokaze
- Ne troigu ĝin, ne superu la superengaĝiĝon.
Referenco:
vm.overcommit_ratio - procento de RAM disponebla por troŝarĝado. Valoro de 50% en sistemo kun 2 GB da RAM povas asigni ĝis 3 GB da RAM.
Agordi vm.overcommit_memory al 2 provizas la plej bonan rendimenton por PostgreSQL. Ĉi tiu valoro maksimumigas la RAM-uzadon de la servila procezo sen iu ajn grava risko esti mortigita de la murdprocezo de OOM. La aplikaĵo povos rekomenci, sed nur ene de la supera limo, kio reduktas la riskon, ke la OOM-murdinto mortigos la procezon. Tial, valoro de 2 donas pli bonan efikecon ol la defaŭlta valoro de 0. Tamen, fidindeco povas esti plibonigita certigante ke memoro ekster la permesita intervalo ne estas troŝarĝita. Ĉi tio forigas la riskon ke la procezo estu mortigita de la OOM-murdinto.
Sur ne-paĝigaj sistemoj, povas esti problemo kun vm.overcommit_memory agordita al 2.
vm.malpura_fona_proporcio / vm.malpura_fona_bajtoj
vm.malpura_fona_proporcio estas la procento de memoro plenigita kun malpuraj paĝoj kiuj devas esti skribitaj al disko. Flushing al disko estas farita en la fono. La valoro de ĉi tiu parametro varias de 0 ĝis 100; tamen, valoro sub 5 eble ne efikas kaj iuj kernoj ne subtenas ĝin. 10 estas la defaŭlta valoro en plej multaj Linuksaj sistemoj. Vi povas plibonigi rendimenton por skribintensaj operacioj per pli malgranda faktoro, kio signifos, ke Linukso forĵetos malpurajn paĝojn en la fono.
Vi devas agordi la valoron vm.malpuraj_fonaj_bajtoj depende de la rapideco de via disko.
Ne ekzistas "bonaj" valoroj por ĉi tiuj du parametroj, ĉar ambaŭ dependas de aparataro. Tamen, agordi vm.dirty_background_ratio al 5 kaj vm.dirty_background_bytes al 25% de diskrapideco plibonigas rendimenton ĝis ~25% en la plej multaj kazoj.
vm.malpura_proporcio / malpuraj_bajtoj
Ĉi tio estas la sama kiel vm.malpura_fona_proporcio / malpura_fona_bajtoj, krom ke la restarigo estas farita en laborsesio, blokante la aplikaĵon. Tial vm.dirty_ratio devus esti pli alta ol vm.malpura_fona_proporcio. Ĉi tio certigas, ke fonaj procezoj komenciĝas pli frue por eviti bloki la aplikaĵon kiel eble plej multe. Vi povas ĝustigi la diferencon inter ĉi tiuj du proporcioj surbaze de disko I/O-ŝarĝo.
La rezulto
Vi povas agordi aliajn agordojn por plibonigi rendimenton, sed la plibonigoj estos minimumaj kaj vi ne ricevos multe da profito. Ni devas memori, ke ne ĉiuj opcioj validas por ĉiuj specoj de aplikoj. Iuj aplikaĵoj funkcias pli bone kiam ni ĝustigas iujn agordojn kaj iuj ne. Vi devas trovi la ĝustan ekvilibron inter la agordoj de ĉi tiuj agordoj por la atendata laborkvanto kaj aplikaĵa tipo, kaj la konduto de la OS devas esti konsiderata dum agordado. Agordi kernajn parametrojn ne estas tiel facila kiel agordi datumbazajn parametrojn: estas pli malfacile fari rekomendojn ĉi tie.
fonto: www.habr.com