PostgreSQL ઑપ્ટિમાઇઝ કરવા માટે Linux કર્નલ વિકલ્પોને રૂપરેખાંકિત કરી રહ્યાં છે

શ્રેષ્ઠ PostgreSQL કામગીરી યોગ્ય રીતે વ્યાખ્યાયિત ઓપરેટિંગ સિસ્ટમ પરિમાણો પર આધાર રાખે છે. ખરાબ રીતે રૂપરેખાંકિત OS કર્નલ સેટિંગ્સ ખરાબ ડેટાબેઝ સર્વર પ્રદર્શનમાં પરિણમી શકે છે. તેથી, તે આવશ્યક છે કે આ સેટિંગ્સ ડેટાબેઝ સર્વર અને તેના વર્કલોડ અનુસાર ગોઠવવામાં આવે. આ પોસ્ટમાં, અમે કેટલાક મહત્વપૂર્ણ Linux કર્નલ પરિમાણોની ચર્ચા કરીશું કે જે ડેટાબેઝ સર્વર પ્રદર્શનને અસર કરી શકે છે અને તેમને કેવી રીતે ગોઠવવું.

SHMMAX / SHMALL

SHMMAX કર્નલ પેરામીટર છે જેનો ઉપયોગ સિંગલ શેર્ડ મેમરી સેગમેન્ટનું મહત્તમ માપ નક્કી કરવા માટે થાય છે કે જે Linux પ્રક્રિયા ફાળવી શકે છે. સંસ્કરણ 9.2 પહેલા, PostgreSQL એ સિસ્ટમ V (SysV) નો ઉપયોગ કર્યો હતો, જેને SHMMAX સેટિંગની જરૂર છે. 9.2 પછી, PostgreSQL એ POSIX શેર્ડ મેમરી પર સ્વિચ કર્યું. તેથી હવે સિસ્ટમ V શેર કરેલી મેમરીના ઓછા બાઇટ્સ જરૂરી છે.

આવૃત્તિ 9.3 પહેલા, SHMMAX એ સૌથી મહત્વપૂર્ણ કર્નલ પરિમાણ હતું. SHMMAX મૂલ્ય બાઇટ્સમાં ઉલ્લેખિત છે.

તેવી જ રીતે SHMALL નક્કી કરવા માટે વપરાતું બીજું કર્નલ પરિમાણ છે
વહેંચાયેલ મેમરી પૃષ્ઠોનું સિસ્ટમ-વ્યાપી વોલ્યુમ. વર્તમાન SHMMAX, SHMALL, અથવા SHMMIN મૂલ્યો જોવા માટે, આદેશનો ઉપયોગ કરો આઈપીસી.

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 ઉપયોગ કરે છે સિસ્ટમ વી આઈપીસી વહેંચાયેલ મેમરી ફાળવવા માટે. આ પરિમાણ સૌથી મહત્વપૂર્ણ કર્નલ પરિમાણોમાંનું એક છે. જ્યારે પણ તમે નીચેના ભૂલ સંદેશાઓ પ્રાપ્ત કરો છો, તેનો અર્થ એ છે કે તમારી પાસે 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.

વ્યાખ્યાઓમાં તફાવતોને સમજવું

Linux અને MacOS X પર SHMMAX/SHMALL પરિમાણોને વ્યાખ્યાયિત કરવું થોડું અલગ છે:

• 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 મેમરી પૃષ્ઠોનો ઉપયોગ કરે છે. સુપર પાના, અને વિન્ડોઝ પર - મોટા પાના. પૃષ્ઠ એ પ્રક્રિયા માટે ફાળવેલ RAM નો એક ભાગ છે. મેમરી જરૂરિયાતોને આધારે પ્રક્રિયામાં બહુવિધ પૃષ્ઠો હોઈ શકે છે. પ્રક્રિયાને જેટલી વધુ મેમરીની જરૂર હોય છે, તેટલા વધુ પૃષ્ઠો ફાળવવામાં આવે છે. OS પ્રક્રિયાઓ માટે પૃષ્ઠ ફાળવણી કોષ્ટક જાળવી રાખે છે. પૃષ્ઠનું કદ જેટલું નાનું છે, ટેબલ જેટલું મોટું છે, તે પૃષ્ઠ કોષ્ટકમાં પૃષ્ઠ શોધવામાં તેટલો વધુ સમય લે છે. તેથી મોટા પૃષ્ઠો ઓછી ઓવરહેડ સાથે મોટી માત્રામાં મેમરીનો ઉપયોગ કરવાની મંજૂરી આપે છે; ઓછા પૃષ્ઠ દૃશ્યો, ઓછા પૃષ્ઠ ખામીઓ, મોટા બફર્સ પર ઝડપી વાંચન/લેખવાની કામગીરી. પરિણામ સુધારેલ પ્રદર્શન છે.

PostgreSQL ફક્ત Linux પર મોટા પેજને સપોર્ટ કરે છે. મૂળભૂત રીતે, Linux 4 KB મેમરી પૃષ્ઠોનો ઉપયોગ કરે છે, તેથી એવા કિસ્સાઓમાં કે જ્યાં ઘણી બધી મેમરી ઑપરેશન હોય, મોટા પૃષ્ઠો સેટ કરવા જરૂરી છે. 2 MB અને 1 GB સુધીના મોટા પૃષ્ઠોનો ઉપયોગ કરતી વખતે પ્રદર્શન લાભ જોવા મળે છે. મોટા પૃષ્ઠનું કદ બુટ સમયે સેટ કરી શકાય છે. તમે આદેશનો ઉપયોગ કરીને તમારા Linux મશીન પર મોટા પૃષ્ઠ પરિમાણો અને તેમના વપરાશને સરળતાથી ચકાસી શકો છો cat /proc/meminfo | grep -i વિશાળ.

મોટા પૃષ્ઠો વિશે માહિતી મેળવવી (ફક્ત લિનક્સ)

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 પર સેટ છે. આનો અર્થ એ છે કે મોટા પૃષ્ઠો અક્ષમ છે.

મોટા પૃષ્ઠોની સંખ્યા નક્કી કરવા માટેની સ્ક્રિપ્ટ

આ સરળ સ્ક્રિપ્ટ જરૂરી સંખ્યામાં મોટા પાના આપે છે. જ્યારે PostgreSQL ચાલી રહ્યું હોય ત્યારે તમારા Linux સર્વર પર સ્ક્રિપ્ટ ચલાવો. ખાતરી કરો કે પર્યાવરણ ચલ માટે $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).

મોટા પાના ફરી જોવામાં આવ્યા (ફક્ત લિનક્સ)

$ 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

હવે $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.swappiness

vm.swappiness અન્ય કર્નલ પરિમાણ છે જે ડેટાબેઝ પ્રભાવને અસર કરી શકે છે. આ વિકલ્પનો ઉપયોગ Linux માં અદલાબદલી (મેમરીમાંથી અને બહાર પૃષ્ઠો સ્વેપિંગ) ના વર્તનને નિયંત્રિત કરવા માટે થાય છે. કિંમત 0 થી 100 સુધીની છે. તે નક્કી કરે છે કે કેટલી મેમરી પેજ કરવામાં આવશે અથવા પેજ આઉટ કરવામાં આવશે. શૂન્ય એટલે કોઈ વિનિમય નહીં અને 100 એટલે આક્રમક વિનિમય.

તમે નીચા મૂલ્યો સેટ કરીને સારું પ્રદર્શન મેળવી શકો છો.

નવા કર્નલ પર આને 0 પર સેટ કરવાથી OOM કિલર (લિનક્સની મેમરી ક્લિનિંગ પ્રક્રિયા) પ્રક્રિયાને સમાપ્ત કરી શકે છે. તેથી જો તમે સ્વેપિંગને ઓછું કરવા માંગતા હોવ તો તેને 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 GB RAM ધરાવતી સિસ્ટમ પર 2% નું મૂલ્ય 3 GB સુધીની RAM ફાળવી શકે છે.

vm.overcommit_memory માટે 2 નું મૂલ્ય PostgreSQL માટે વધુ સારું પ્રદર્શન પૂરું પાડે છે. આ મૂલ્ય OOM કિલર પ્રક્રિયા દ્વારા માર્યા જવાના કોઈપણ નોંધપાત્ર જોખમ વિના સર્વર પ્રક્રિયાના RAM વપરાશને મહત્તમ કરે છે. એપ્લિકેશન ફરીથી લોડ કરવામાં સક્ષમ હશે, પરંતુ માત્ર ઓવરરનની મર્યાદામાં, જે OOM કિલર પ્રક્રિયાને મારી નાખવાના જોખમને ઘટાડે છે. તેથી, 2 નું મૂલ્ય 0 ની ડિફોલ્ટ મૂલ્ય કરતાં વધુ સારું પ્રદર્શન આપે છે. જો કે, રેન્જની બહારની મેમરી ઓવરલોડ નથી તેની ખાતરી કરીને વિશ્વસનીયતા સુધારી શકાય છે. આ OOM કિલર દ્વારા પ્રક્રિયાને મારવાના જોખમને દૂર કરે છે.

અદલાબદલી વિના સિસ્ટમો પર, 2 ની બરાબર vm.overcommit_memory સાથે સમસ્યા આવી શકે છે.

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 ની નીચેનું મૂલ્ય બિનઅસરકારક હોઈ શકે છે અને કેટલાક કર્નલ તેને સપોર્ટ કરતા નથી. મોટાભાગની Linux સિસ્ટમો પર 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. આ સુનિશ્ચિત કરે છે કે એપ્લિકેશનને શક્ય તેટલું અવરોધિત કરવાનું ટાળવા માટે પૃષ્ઠભૂમિ પ્રક્રિયાઓ વહેલી શરૂ થાય છે. તમે ડિસ્ક I/O લોડના આધારે આ બે ગુણોત્તર વચ્ચેના તફાવતને સમાયોજિત કરી શકો છો.

પરિણામ

તમે પ્રદર્શનને સુધારવા માટે અન્ય સેટિંગ્સમાં ફેરફાર કરી શકો છો, પરંતુ સુધારાઓ ન્યૂનતમ હશે અને તમને વધુ લાભ દેખાશે નહીં. આપણે યાદ રાખવું જોઈએ કે તમામ વિકલ્પો તમામ પ્રકારની એપ્લિકેશનોને લાગુ પડતા નથી. જ્યારે અમે કેટલીક સેટિંગ્સને સમાયોજિત કરીએ છીએ ત્યારે કેટલીક એપ્લિકેશન્સ વધુ સારી રીતે કાર્ય કરે છે અને કેટલીક નથી. તમારે તમારા અપેક્ષિત વર્કલોડ અને એપ્લિકેશન પ્રકાર માટે આ સેટિંગ્સને ગોઠવવા વચ્ચે યોગ્ય સંતુલન મેળવવું આવશ્યક છે, અને તમારે ટ્યુનિંગ કરતી વખતે OS વર્તનને પણ ધ્યાનમાં લેવું આવશ્યક છે. કર્નલ પરિમાણોને રૂપરેખાંકિત કરવું એ ડેટાબેઝ પરિમાણોને રૂપરેખાંકિત કરવા જેટલું સરળ નથી; ભલામણો કરવી તે વધુ મુશ્કેલ છે.

સોર્સ: www.habr.com