PostgreSQL-നായി Linux-ൽ ഔട്ട്-ഓഫ്-മെമ്മറി കില്ലർ സജ്ജീകരിക്കുന്നു

ലിനക്സിൽ ഒരു ഡാറ്റാബേസ് സെർവർ അപ്രതീക്ഷിതമായി പുറത്തുകടക്കുമ്പോൾ, നിങ്ങൾ കാരണം കണ്ടെത്തേണ്ടതുണ്ട്. നിരവധി കാരണങ്ങളുണ്ടാകാം. ഉദാഹരണത്തിന്, SIGSEGV - ബാക്കെൻഡ് സെർവറിലെ ഒരു ബഗ് കാരണം പരാജയം. എന്നാൽ ഇത് അപൂർവമാണ്. മിക്കപ്പോഴും, നിങ്ങൾക്ക് ഡിസ്കിൽ സ്ഥലമോ മെമ്മറിയോ തീർന്നു. നിങ്ങളുടെ ഡിസ്കിൽ ഇടം തീർന്നാൽ, ഒരു പോംവഴി മാത്രമേയുള്ളൂ - സ്ഥലം ശൂന്യമാക്കി ഡാറ്റാബേസ് പുനരാരംഭിക്കുക.

ഓർമ്മയില്ലാത്ത കൊലയാളി

ഒരു സെർവറോ പ്രോസസ്സോ മെമ്മറി തീരുമ്പോൾ, Linux 2 പരിഹാരങ്ങൾ വാഗ്ദാനം ചെയ്യുന്നു: മുഴുവൻ സിസ്റ്റവും ക്രാഷ് ചെയ്യുക അല്ലെങ്കിൽ മെമ്മറി നശിപ്പിക്കുന്ന പ്രക്രിയ (അപ്ലിക്കേഷൻ) അവസാനിപ്പിക്കുക. തീർച്ചയായും, പ്രക്രിയ അവസാനിപ്പിച്ച് OS ക്രാഷിൽ നിന്ന് സംരക്ഷിക്കുന്നതാണ് നല്ലത്. ചുരുക്കത്തിൽ, കേർണലിനെ ക്രാഷുചെയ്യുന്നതിൽ നിന്ന് സംരക്ഷിക്കുന്നതിനുള്ള ഒരു ആപ്ലിക്കേഷനെ നശിപ്പിക്കുന്ന ഒരു പ്രക്രിയയാണ് ഔട്ട്-ഓഫ്-മെമ്മറി കില്ലർ. OS പ്രവർത്തിക്കുന്നത് നിലനിർത്താൻ ഇത് ആപ്ലിക്കേഷനെ ബലികഴിക്കുന്നു. OOM എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും അത് എങ്ങനെ നിയന്ത്രിക്കാമെന്നും ആദ്യം ചർച്ച ചെയ്യാം, തുടർന്ന് OOM കില്ലർ ഏത് ആപ്ലിക്കേഷൻ അവസാനിപ്പിക്കണമെന്ന് തീരുമാനിക്കുന്നത് എങ്ങനെയെന്ന് നോക്കാം.

ലിനക്സിന്റെ പ്രധാന ജോലികളിലൊന്ന്, പ്രോസസ്സുകൾ ആവശ്യപ്പെടുമ്പോൾ മെമ്മറി അനുവദിക്കുക എന്നതാണ്. സാധാരണഗതിയിൽ, ഒരു പ്രോസസ്സോ ആപ്ലിക്കേഷനോ OS-ൽ നിന്ന് മെമ്മറി അഭ്യർത്ഥിക്കുന്നു, പക്ഷേ അത് പൂർണ്ണമായി ഉപയോഗിക്കുന്നില്ല. OS മെമ്മറി ആവശ്യപ്പെടുന്ന എല്ലാവർക്കും അത് ഉപയോഗിക്കാൻ പദ്ധതിയില്ലെങ്കിൽ, വളരെ വേഗം മെമ്മറി തീർന്നുപോകുകയും സിസ്റ്റം പരാജയപ്പെടുകയും ചെയ്യും. ഇത് ഒഴിവാക്കാൻ, OS പ്രോസസ്സിനായി മെമ്മറി റിസർവ് ചെയ്യുന്നു, പക്ഷേ യഥാർത്ഥത്തിൽ അത് റിലീസ് ചെയ്യുന്നില്ല. ഒരു പ്രോസസ്സ് യഥാർത്ഥത്തിൽ അത് ഉപയോഗിക്കാൻ പോകുമ്പോൾ മാത്രമേ മെമ്മറി അനുവദിക്കൂ. OS-ന് സൌജന്യ മെമ്മറി ഇല്ല എന്നത് സംഭവിക്കുന്നു, പക്ഷേ അത് ഒരു പ്രോസസ്സിന് മെമ്മറി നൽകുന്നു, ഒരു പ്രോസസ്സ് ആവശ്യമുള്ളപ്പോൾ, OS അതിന് കഴിയുമെങ്കിൽ അത് അനുവദിക്കും. പോരായ്മ ചിലപ്പോൾ OS മെമ്മറി റിസർവ് ചെയ്യുന്നു, എന്നാൽ ശരിയായ സമയത്ത് സൌജന്യ മെമ്മറി ഇല്ല, സിസ്റ്റം ക്രാഷ് ചെയ്യുന്നു. ഈ സാഹചര്യത്തിൽ OOM ഒരു പ്രധാന പങ്ക് വഹിക്കുകയും കേർണൽ പരിഭ്രാന്തരാകുന്നത് തടയാൻ പ്രക്രിയകൾ അവസാനിപ്പിക്കുകയും ചെയ്യുന്നു. ഒരു PostgreSQL പ്രക്രിയ അവസാനിപ്പിക്കാൻ നിർബന്ധിതമാകുമ്പോൾ, ലോഗിൽ ഒരു സന്ദേശം ദൃശ്യമാകും:

Out of Memory: Killed process 12345 (postgres).

സിസ്റ്റത്തിന് മെമ്മറി കുറവാണെങ്കിൽ അത് സ്വതന്ത്രമാക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, ഫംഗ്ഷനെ വിളിക്കുന്നു out_of_memory. ഈ ഘട്ടത്തിൽ, അവൾക്ക് ഒരു കാര്യം മാത്രമേ ചെയ്യാനുള്ളൂ - ഒന്നോ അതിലധികമോ പ്രക്രിയകൾ പൂർത്തിയാക്കുക. OOM-കില്ലർ ഉടൻ തന്നെ പ്രക്രിയ അവസാനിപ്പിക്കണമോ അതോ കാത്തിരിക്കാൻ കഴിയുമോ? വ്യക്തമായും, out_of_memory എന്ന് വിളിക്കപ്പെടുമ്പോൾ, അത് ഒരു I/O ഓപ്പറേഷനായി കാത്തിരിക്കുന്നതിനാലോ ഡിസ്കിലേക്കുള്ള പേജിംഗിലേക്കോ ആണ്. അതിനാൽ, OOM കൊലയാളി ആദ്യം പരിശോധനകൾ നടത്തുകയും അവയുടെ അടിസ്ഥാനത്തിൽ പ്രക്രിയ അവസാനിപ്പിക്കേണ്ടതുണ്ടെന്ന് തീരുമാനിക്കുകയും വേണം. ചുവടെയുള്ള എല്ലാ പരിശോധനകളും പോസിറ്റീവ് ആണെങ്കിൽ, OOM പ്രക്രിയ അവസാനിപ്പിക്കും.

പ്രക്രിയ തിരഞ്ഞെടുക്കൽ

മെമ്മറി തീരുമ്പോൾ, ഫംഗ്ഷൻ എന്ന് വിളിക്കുന്നു out_of_memory(). അതിന് ഒരു ഫങ്ഷൻ ഉണ്ട് select_bad_process(), ഫംഗ്ഷനിൽ നിന്ന് ഒരു മൂല്യനിർണ്ണയം ലഭിക്കുന്നു badness(). "ഏറ്റവും മോശമായ" പ്രക്രിയ ലക്ഷ്യമിടുന്നു. ഫംഗ്ഷൻ badness() ചില നിയമങ്ങൾക്കനുസൃതമായി ഒരു പ്രക്രിയ തിരഞ്ഞെടുക്കുന്നു.

1. കേർണലിന് കുറച്ച് മിനിമം മെമ്മറി ആവശ്യമാണ്.
2. നിങ്ങൾ ഒരുപാട് മെമ്മറി സ്വതന്ത്രമാക്കേണ്ടതുണ്ട്.
3. കുറച്ച് മെമ്മറി ഉപയോഗിക്കുന്ന പ്രക്രിയകൾ അവസാനിപ്പിക്കേണ്ട ആവശ്യമില്ല.
4. മിനിമം നടപടിക്രമങ്ങൾ പൂർത്തിയാക്കേണ്ടതുണ്ട്.
5. ഉപയോക്താവ് തന്നെ പൂർത്തിയാക്കാൻ ആഗ്രഹിക്കുന്ന പ്രക്രിയകൾ പൂർത്തിയാക്കാനുള്ള സാധ്യത വർദ്ധിപ്പിക്കുന്ന സങ്കീർണ്ണമായ അൽഗോരിതങ്ങൾ.

ഈ പരിശോധനകളെല്ലാം പൂർത്തിയാക്കിയ ശേഷം, OOM സ്കോർ പരിശോധിക്കുന്നു (oom_score). OOM അസൈൻ ചെയ്യുന്നു oom_score ഓരോ പ്രക്രിയയും, തുടർന്ന് ഈ മൂല്യം മെമ്മറിയുടെ അളവ് കൊണ്ട് ഗുണിക്കുന്നു. വലിയ മൂല്യങ്ങളുള്ള പ്രക്രിയകൾ OOM കില്ലറിന് ഇരയാകാനുള്ള സാധ്യത കൂടുതലാണ്. റൂട്ട് യൂസറുമായി ബന്ധപ്പെട്ട പ്രക്രിയകൾക്ക് കുറഞ്ഞ സ്കോർ ഉണ്ട്, അത് അവസാനിപ്പിക്കാൻ നിർബന്ധിതരാകാനുള്ള സാധ്യത കുറവാണ്.

postgres=# SELECT pg_backend_pid();
pg_backend_pid 
----------------
    3813
(1 row)

Postgres പ്രോസസ്സ് ഐഡി 3813 ആണ്, അതിനാൽ മറ്റൊരു ഷെല്ലിൽ ഈ കേർണൽ പാരാമീറ്റർ ഉപയോഗിച്ച് സ്കോർ നേടാനാകും oom_score:

vagrant@vagrant:~$ sudo cat /proc/3813/oom_score
2

OOM-Killer പ്രക്രിയയെ ഇല്ലാതാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നില്ലെങ്കിൽ, മറ്റൊരു കേർണൽ ഓപ്ഷൻ ഉണ്ട്: oom_score_adj. നിങ്ങൾ വിലമതിക്കുന്ന ഒരു പ്രോസസ്സ് പൂർത്തിയാക്കാനുള്ള സാധ്യത കുറയ്ക്കുന്നതിന് ഒരു വലിയ നെഗറ്റീവ് മൂല്യം ചേർക്കുക.

sudo echo -100 > /proc/3813/oom_score_adj

ഒരു മൂല്യം സജ്ജമാക്കാൻ oom_score_adj, സേവന ബ്ലോക്കിൽ OOMScoreAdjust സജ്ജമാക്കുക:

[Service]
OOMScoreAdjust=-1000

അല്ലെങ്കിൽ ഉപയോഗിക്കുക oomprotect ഒരു ടീമിൽ rcctl.

rcctl set <i>servicename</i> oomprotect -1000

ഒരു പ്രക്രിയയുടെ നിർബന്ധിത അവസാനിപ്പിക്കൽ

ഒന്നോ അതിലധികമോ പ്രക്രിയകൾ ഇതിനകം തിരഞ്ഞെടുത്തിരിക്കുമ്പോൾ, OOM-കില്ലർ ഫംഗ്‌ഷനെ വിളിക്കുന്നു oom_kill_task(). ഈ ഫംഗ്ഷൻ പ്രക്രിയയിലേക്ക് ഒരു അവസാനിപ്പിക്കൽ സിഗ്നൽ അയയ്ക്കുന്നു. മെമ്മറി കുറവാണെങ്കിൽ oom_kill() പ്രോസസ്സിലേക്ക് ഒരു SIGKILL സിഗ്നൽ അയയ്‌ക്കാൻ ഈ ഫംഗ്‌ഷനെ വിളിക്കുന്നു. കേർണൽ ലോഗിലേക്ക് ഒരു സന്ദേശം എഴുതിയിരിക്കുന്നു.

Out of Memory: Killed process [pid] [name].

OOM-കില്ലർ എങ്ങനെ നിയന്ത്രിക്കാം

Linux-ൽ, നിങ്ങൾക്ക് OOM-Killer പ്രവർത്തനക്ഷമമാക്കാനോ പ്രവർത്തനരഹിതമാക്കാനോ കഴിയും (രണ്ടാമത്തേത് ശുപാർശ ചെയ്തിട്ടില്ലെങ്കിലും). പ്രവർത്തനക്ഷമമാക്കാനോ പ്രവർത്തനരഹിതമാക്കാനോ പാരാമീറ്റർ ഉപയോഗിക്കുക vm.oom-kill. റൺടൈമിൽ OOM-കില്ലർ പ്രവർത്തനക്ഷമമാക്കാൻ, കമാൻഡ് പ്രവർത്തിപ്പിക്കുക sysctl.

sudo -s sysctl -w vm.oom-kill = 1

OOM-Killer പ്രവർത്തനരഹിതമാക്കുന്നതിന്, അതേ കമാൻഡിൽ മൂല്യം 0 വ്യക്തമാക്കുക:

sudo -s sysctl -w vm.oom-kill = 0

ഈ കമാൻഡിന്റെ ഫലം ശാശ്വതമായി സംരക്ഷിക്കപ്പെടില്ല, പക്ഷേ ആദ്യത്തെ റീബൂട്ട് വരെ മാത്രം. നിങ്ങൾക്ക് കൂടുതൽ സ്ഥിരോത്സാഹം ആവശ്യമുണ്ടെങ്കിൽ, ഫയലിലേക്ക് ഈ വരി ചേർക്കുക /etc/sysctl.conf:

echo vm.oom-kill = 1 >>/etc/sysctl.conf

പ്രവർത്തനക്ഷമമാക്കാനും പ്രവർത്തനരഹിതമാക്കാനുമുള്ള മറ്റൊരു മാർഗം ഒരു വേരിയബിൾ എഴുതുക എന്നതാണ് panic_on_oom. മൂല്യം എപ്പോഴും ചെക്ക് ഇൻ ചെയ്യാവുന്നതാണ് /proc.

$ cat /proc/sys/vm/panic_on_oom
0

നിങ്ങൾ മൂല്യം 0 ആയി സജ്ജമാക്കുകയാണെങ്കിൽ, മെമ്മറി തീരുമ്പോൾ, കേർണൽ പാനിക് ഉണ്ടാകില്ല.

$ echo 0 > /proc/sys/vm/panic_on_oom

നിങ്ങൾ മൂല്യം 1 ആയി സജ്ജമാക്കുകയാണെങ്കിൽ, മെമ്മറി തീരുമ്പോൾ, ഒരു കേർണൽ പാനിക് സംഭവിക്കും.

echo 1 > /proc/sys/vm/panic_on_oom

OOM-കില്ലർ ഓണാക്കാനും ഓഫാക്കാനും മാത്രമല്ല. ലിനക്‌സിന് യഥാർത്ഥത്തിൽ അനുവദിക്കാതെ തന്നെ ലഭ്യമായതിനേക്കാൾ കൂടുതൽ മെമ്മറി പ്രോസസ്സുകൾക്കായി റിസർവ് ചെയ്യാനാകുമെന്ന് ഞങ്ങൾ ഇതിനകം പറഞ്ഞിട്ടുണ്ട്, ഈ സ്വഭാവം നിയന്ത്രിക്കുന്നത് ഒരു ലിനക്സ് കേർണൽ പാരാമീറ്ററാണ്. വേരിയബിൾ ഇതിന് ഉത്തരവാദിയാണ് vm.overcommit_memory.

അതിനായി നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന മൂല്യങ്ങൾ വ്യക്തമാക്കാൻ കഴിയും:

0: വളരെയധികം മെമ്മറി റിസർവ് ചെയ്യണമോ എന്ന് കേർണൽ തന്നെ തീരുമാനിക്കുന്നു. ലിനക്സിന്റെ മിക്ക പതിപ്പുകളിലും ഇത് സ്ഥിരസ്ഥിതിയാണ്.
1: കേർണൽ എപ്പോഴും അധിക മെമ്മറി റിസർവ് ചെയ്യും. ഇത് അപകടകരമാണ്, കാരണം മെമ്മറി തീർന്നുപോയേക്കാം, കാരണം, മിക്കവാറും, ഒരു ദിവസം പ്രക്രിയകൾക്ക് അത് ആവശ്യമായി വരും.
2: പാരാമീറ്ററിൽ പറഞ്ഞിരിക്കുന്നതിനേക്കാൾ കൂടുതൽ മെമ്മറി കേർണൽ റിസർവ് ചെയ്യില്ല overcommit_ratio.

ഈ പരാമീറ്റർ ഉപയോഗിച്ച്, ഓവർ റിസർവ് ചെയ്യാൻ അനുവദിക്കുന്ന മെമ്മറിയുടെ ശതമാനം നിങ്ങൾ വ്യക്തമാക്കുന്നു. അതിന് ഇടമില്ലെങ്കിൽ, മെമ്മറി അനുവദിക്കില്ല, സംവരണം നിഷേധിക്കപ്പെടും. PostgreSQL-ന് ശുപാർശ ചെയ്യുന്ന ഏറ്റവും സുരക്ഷിതമായ ഓപ്ഷനാണിത്. OOM-കില്ലറിനെ മറ്റൊരു ഘടകം ബാധിക്കുന്നു - വേരിയബിൾ നിയന്ത്രിക്കുന്ന സ്വാപ്പിംഗ് കഴിവ് cat /proc/sys/vm/swappiness. പേജിംഗ് എങ്ങനെ കൈകാര്യം ചെയ്യണമെന്ന് ഈ മൂല്യങ്ങൾ കേർണലിനോട് പറയുന്നു. ഉയർന്ന മൂല്യം, OOM പ്രക്രിയ അവസാനിപ്പിക്കാനുള്ള സാധ്യത കുറവാണ്, പക്ഷേ I/O പ്രവർത്തനങ്ങൾ കാരണം ഇത് ഡാറ്റാബേസിൽ പ്രതികൂല സ്വാധീനം ചെലുത്തുന്നു. തിരിച്ചും - കുറഞ്ഞ മൂല്യം, OOM-കില്ലർ ഇടപെടലിനുള്ള സാധ്യത കൂടുതലാണ്, പക്ഷേ ഡാറ്റാബേസ് പ്രകടനവും കൂടുതലാണ്. സ്ഥിരസ്ഥിതി മൂല്യം 60 ആണ്, എന്നാൽ മുഴുവൻ ഡാറ്റാബേസും മെമ്മറിയിൽ യോജിക്കുന്നുവെങ്കിൽ, മൂല്യം 1 ആയി സജ്ജീകരിക്കുന്നതാണ് നല്ലത്.

ഫലങ്ങൾ

OOM-കില്ലറിലെ "കൊലയാളി" നിങ്ങളെ ഭയപ്പെടുത്താൻ അനുവദിക്കരുത്. ഈ സാഹചര്യത്തിൽ, കൊലയാളി നിങ്ങളുടെ സിസ്റ്റത്തിന്റെ രക്ഷകനായിരിക്കും. ഇത് ഏറ്റവും മോശം പ്രക്രിയകളെ "കൊല്ലുന്നു" കൂടാതെ സിസ്റ്റത്തെ ക്രാഷിൽ നിന്ന് രക്ഷിക്കുന്നു. PostgreSQL അവസാനിപ്പിക്കാൻ OOM-Killer ഉപയോഗിക്കേണ്ടിവരുന്നത് ഒഴിവാക്കാൻ, ഇതിനായി സജ്ജമാക്കുക vm.overcommit_memory മൂല്യം 2. OOM-കില്ലർ ഇടപെടേണ്ടതില്ലെന്ന് ഇത് ഉറപ്പുനൽകുന്നില്ല, പക്ഷേ ഇത് PostgreSQL പ്രക്രിയ അവസാനിപ്പിക്കാൻ നിർബന്ധിതമാക്കുന്നതിനുള്ള സാധ്യത കുറയ്ക്കും.

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