മെമ്മറിക്ക് പുറത്താകുന്ന കില്ലർ സജ്ജീകരിക്കുന്നു Linux പോസ്റ്റ്ഗ്രെഎസ്ക്യുഎല്ലിനായി

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

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

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

പ്രധാന ജോലികളിൽ ഒന്ന് Linux — പ്രോസസ്സുകൾ അഭ്യർത്ഥിക്കുമ്പോൾ മെമ്മറി അനുവദിക്കുക. സാധാരണയായി, ഒരു പ്രോസസ്സ് അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ 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-കില്ലർ ഓണാക്കാനും ഓഫാക്കാനും കഴിയും. Linux ലഭ്യമായതിനേക്കാൾ കൂടുതൽ മെമ്മറി പ്രോസസ്സുകൾക്കായി കരുതിവച്ചേക്കാം, പക്ഷേ യഥാർത്ഥത്തിൽ അത് അനുവദിക്കുന്നില്ല, കൂടാതെ ഈ സ്വഭാവം ഒരു കേർണൽ പാരാമീറ്ററാണ് നിയന്ത്രിക്കുന്നത്. Linuxഇതിന് വേരിയബിൾ ഉത്തരവാദിയാണ്. vm.overcommit_memory.

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

0: വളരെയധികം മെമ്മറി റിസർവ് ചെയ്യണോ വേണ്ടയോ എന്ന് കേർണൽ തന്നെയാണ് തീരുമാനിക്കുന്നത്. മിക്ക പതിപ്പുകളിലും ഇത് സ്ഥിരസ്ഥിതി മൂല്യമാണ്. Linux.
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