PostgreSQL ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനായി Linux കേർണൽ ഓപ്ഷനുകൾ കോൺഫിഗർ ചെയ്യുന്നു

ഒപ്റ്റിമൽ PostgreSQL പ്രകടനം ശരിയായി നിർവചിച്ചിരിക്കുന്ന ഓപ്പറേറ്റിംഗ് സിസ്റ്റം പാരാമീറ്ററുകളെ ആശ്രയിച്ചിരിക്കുന്നു. മോശമായി കോൺഫിഗർ ചെയ്ത OS കേർണൽ ക്രമീകരണങ്ങൾ മോശം ഡാറ്റാബേസ് സെർവർ പ്രകടനത്തിന് കാരണമാകും. അതിനാൽ, ഡാറ്റാബേസ് സെർവറിനും അതിന്റെ ജോലിഭാരത്തിനും അനുസൃതമായി ഈ ക്രമീകരണങ്ങൾ ക്രമീകരിച്ചിരിക്കുന്നത് അത്യന്താപേക്ഷിതമാണ്. ഈ പോസ്റ്റിൽ, ഡാറ്റാബേസ് സെർവർ പ്രകടനത്തെ ബാധിക്കുന്ന ചില പ്രധാനപ്പെട്ട ലിനക്സ് കേർണൽ പാരാമീറ്ററുകളും അവ എങ്ങനെ ക്രമീകരിക്കാമെന്നും ഞങ്ങൾ ചർച്ച ചെയ്യും.

SHMMAX / SHMALL

SHMMAX ഒരു ലിനക്സ് പ്രോസസിന് അനുവദിക്കാൻ കഴിയുന്ന ഒരു പങ്കിട്ട മെമ്മറി സെഗ്‌മെന്റിന്റെ പരമാവധി വലുപ്പം നിർണ്ണയിക്കാൻ ഉപയോഗിക്കുന്ന ഒരു കേർണൽ പാരാമീറ്ററാണ്. പതിപ്പ് 9.2-ന് മുമ്പ്, PostgreSQL സിസ്റ്റം V (SysV) ഉപയോഗിച്ചിരുന്നു, അതിന് SHMMAX ക്രമീകരണം ആവശ്യമാണ്. 9.2 ന് ശേഷം, PostgreSQL POSIX പങ്കിട്ട മെമ്മറിയിലേക്ക് മാറി. അതിനാൽ ഇപ്പോൾ സിസ്റ്റം 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 ഉപയോഗിക്കുന്നു സിസ്റ്റം വി ഐപിസി പങ്കിട്ട മെമ്മറി അനുവദിക്കുന്നതിന്. ഈ പരാമീറ്റർ ഏറ്റവും പ്രധാനപ്പെട്ട കേർണൽ പരാമീറ്ററുകളിൽ ഒന്നാണ്. നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന പിശക് സന്ദേശങ്ങൾ ലഭിക്കുമ്പോഴെല്ലാം, നിങ്ങൾക്ക് 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 എന്നിവയിൽ അല്പം വ്യത്യസ്തമാണ്:

• ലിനക്സ്: 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

ലിനക്സിൽ കേർണൽ പാരാമീറ്ററുകൾ മാറ്റുന്നു

# 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 എന്നതിലേക്ക് ചേർക്കുക

വലിയ പേജുകൾ

ലിനക്സ് സ്ഥിരസ്ഥിതിയായി 4 KB മെമ്മറി പേജുകൾ ഉപയോഗിക്കുന്നു, BSD XNUMX KB മെമ്മറി പേജുകൾ ഉപയോഗിക്കുന്നു. സൂപ്പർ പേജുകൾ, ഒപ്പം വിൻഡോസിൽ - വലിയ പേജുകൾ. ഒരു പ്രക്രിയയ്ക്കായി നീക്കിവച്ചിരിക്കുന്ന റാമിന്റെ ഒരു ഭാഗമാണ് പേജ്. മെമ്മറി ആവശ്യകതകൾ അനുസരിച്ച് ഒരു പ്രോസസ്സിന് ഒന്നിലധികം പേജുകൾ ഉണ്ടാകാം. ഒരു പ്രോസസ്സിന് കൂടുതൽ മെമ്മറി ആവശ്യമാണ്, അതിന് കൂടുതൽ പേജുകൾ അനുവദിക്കും. പ്രക്രിയകൾക്കായി OS ഒരു പേജ് അലോക്കേഷൻ ടേബിൾ പരിപാലിക്കുന്നു. പേജ് വലുപ്പം ചെറുതാണെങ്കിൽ, പട്ടിക വലുതായിരിക്കും, ആ പേജ് പട്ടികയിൽ ഒരു പേജ് കണ്ടെത്താൻ കൂടുതൽ സമയമെടുക്കും. അതിനാൽ വലിയ പേജുകൾ ഓവർഹെഡ് കുറച്ചതിനൊപ്പം വലിയ അളവിലുള്ള മെമ്മറി ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു; കുറച്ച് പേജ് കാഴ്‌ചകൾ, കുറച്ച് പേജ് തകരാറുകൾ, വലിയ ബഫറുകളിൽ വേഗത്തിലുള്ള വായന/എഴുത്ത് പ്രവർത്തനങ്ങൾ. മെച്ചപ്പെട്ട പ്രകടനമാണ് ഫലം.

PostgreSQL ലിനക്സിൽ വലിയ പേജുകളെ മാത്രമേ പിന്തുണയ്ക്കൂ. സ്ഥിരസ്ഥിതിയായി, Linux 4 KB മെമ്മറി പേജുകൾ ഉപയോഗിക്കുന്നു, അതിനാൽ വളരെയധികം മെമ്മറി പ്രവർത്തനങ്ങൾ ഉള്ള സന്ദർഭങ്ങളിൽ, വലിയ പേജുകൾ സജ്ജീകരിക്കേണ്ടത് ആവശ്യമാണ്. 2 MB, 1 GB വരെയുള്ള വലിയ പേജുകൾ ഉപയോഗിക്കുമ്പോൾ പ്രകടന നേട്ടങ്ങൾ നിരീക്ഷിക്കപ്പെടുന്നു. ബൂട്ട് സമയത്ത് വലിയ പേജ് വലുപ്പം സജ്ജമാക്കാൻ കഴിയും. കമാൻഡ് ഉപയോഗിച്ച് നിങ്ങളുടെ Linux മെഷീനിലെ വലിയ പേജ് പാരാമീറ്ററുകളും അവയുടെ ഉപയോഗവും നിങ്ങൾക്ക് എളുപ്പത്തിൽ പരിശോധിക്കാം cat /proc/meminfo | grep -ഞാൻ വളരെ വലുതാണ്.

വലിയ പേജുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ നേടുന്നു (ലിനക്സ് മാത്രം)

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-ൽ big_pages പാരാമീറ്റർ "on" ആയി സജ്ജമാക്കി സെർവർ പുനരാരംഭിക്കുക.

ഒരിക്കൽ കൂടി, വലിയ പേജുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ (ലിനക്സ് മാത്രം)

$ 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 ഡാറ്റാബേസ് പ്രകടനത്തെ ബാധിക്കുന്ന മറ്റൊരു കേർണൽ പാരാമീറ്ററാണ്. ലിനക്സിൽ സ്വാപ്പിനസ് (മെമ്മറിയിലും പുറത്തും പേജുകൾ സ്വാപ്പ് ചെയ്യുന്നു) നിയന്ത്രിക്കാൻ ഈ ഓപ്ഷൻ ഉപയോഗിക്കുന്നു. മൂല്യം 0 മുതൽ 100 ​​വരെയാണ്. എത്ര മെമ്മറി പേജ് അല്ലെങ്കിൽ പേജ് ഔട്ട് ചെയ്യപ്പെടുമെന്ന് ഇത് നിർണ്ണയിക്കുന്നു. പൂജ്യം എന്നാൽ വിനിമയമില്ല, 100 എന്നാൽ ആക്രമണാത്മക വിനിമയം.

കുറഞ്ഞ മൂല്യങ്ങൾ ക്രമീകരിക്കുന്നതിലൂടെ നിങ്ങൾക്ക് മികച്ച പ്രകടനം നേടാനാകും.

പുതിയ കേർണലുകളിൽ ഇത് 0 ആയി സജ്ജീകരിക്കുന്നത് OOM കില്ലർ (ലിനക്സിന്റെ മെമ്മറി ക്ലീനിംഗ് പ്രോസസ്) പ്രക്രിയയെ ഇല്ലാതാക്കാൻ കാരണമായേക്കാം. അതിനാൽ നിങ്ങൾക്ക് സ്വാപ്പിംഗ് കുറയ്ക്കണമെങ്കിൽ അത് 1 ആയി സജ്ജീകരിക്കുന്നത് സുരക്ഷിതമാണ്. ലിനക്സിലെ ഡിഫോൾട്ട് മൂല്യം 60 ആണ്. ഉയർന്ന മൂല്യം MMU (മെമ്മറി മാനേജ്മെന്റ് യൂണിറ്റ്) റാമിനേക്കാൾ കൂടുതൽ സ്വാപ്പ് സ്പേസ് ഉപയോഗിക്കുന്നതിന് കാരണമാകുന്നു, അതേസമയം കുറഞ്ഞ മൂല്യം മെമ്മറിയിൽ കൂടുതൽ ഡാറ്റ/കോഡ് നിലനിർത്തുന്നു.

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 — ഓവർലോഡിന് ലഭ്യമായ റാമിന്റെ ശതമാനം. 50 GB RAM ഉള്ള ഒരു സിസ്റ്റത്തിൽ 2% മൂല്യത്തിന് 3 GB വരെ റാം അനുവദിക്കാം.

vm.overcommit_memory എന്നതിനായുള്ള 2 മൂല്യം PostgreSQL-ന് മികച്ച പ്രകടനം നൽകുന്നു. ഈ മൂല്യം 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. ആപ്ലിക്കേഷനെ പരമാവധി തടയുന്നത് ഒഴിവാക്കാൻ പശ്ചാത്തല പ്രക്രിയകൾ നേരത്തെ ആരംഭിക്കുന്നുവെന്ന് ഇത് ഉറപ്പാക്കുന്നു. ഡിസ്ക് I/O ലോഡ് അനുസരിച്ച് നിങ്ങൾക്ക് ഈ രണ്ട് അനുപാതങ്ങൾ തമ്മിലുള്ള വ്യത്യാസം ക്രമീകരിക്കാം.

ഫലം

പ്രകടനം മെച്ചപ്പെടുത്താൻ നിങ്ങൾക്ക് മറ്റ് ക്രമീകരണങ്ങൾ മാറ്റാവുന്നതാണ്, എന്നാൽ മെച്ചപ്പെടുത്തലുകൾ വളരെ കുറവായിരിക്കും, നിങ്ങൾക്ക് കൂടുതൽ പ്രയോജനം ലഭിക്കില്ല. എല്ലാ ഓപ്ഷനുകളും എല്ലാത്തരം ആപ്ലിക്കേഷനുകൾക്കും ബാധകമല്ലെന്ന് നാം ഓർക്കണം. ഞങ്ങൾ ചില ക്രമീകരണങ്ങൾ ക്രമീകരിക്കുമ്പോൾ ചില ആപ്പുകൾ നന്നായി പ്രവർത്തിക്കുന്നു, ചിലത് അങ്ങനെയല്ല. നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ജോലിഭാരത്തിനും ആപ്ലിക്കേഷൻ തരത്തിനുമായി ഈ ക്രമീകരണങ്ങൾ കോൺഫിഗർ ചെയ്യുന്നതിനുള്ള ശരിയായ ബാലൻസ് നിങ്ങൾ കണ്ടെത്തേണ്ടതുണ്ട്, ട്യൂൺ ചെയ്യുമ്പോൾ OS സ്വഭാവവും നിങ്ങൾ പരിഗണിക്കണം. കേർണൽ പാരാമീറ്ററുകൾ ക്രമീകരിക്കുന്നത് ഡാറ്റാബേസ് പാരാമീറ്ററുകൾ ക്രമീകരിക്കുന്നത് പോലെ എളുപ്പമല്ല; ശുപാർശകൾ നൽകുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാണ്.

അവലംബം: www.habr.com