PostgreSQL માટે Linux માં આઉટ-ઓફ-મેમરી કિલર સેટ કરી રહ્યું છે

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

આઉટ-ઓફ-મેમરી કિલર

જ્યારે સર્વર અથવા પ્રક્રિયાની મેમરી સમાપ્ત થાય છે, ત્યારે Linux 2 ઉકેલો પ્રદાન કરે છે: સમગ્ર સિસ્ટમને ક્રેશ કરો અથવા પ્રક્રિયા (એપ્લિકેશન) કે જે મેમરીને ખાઈ રહી છે તેને સમાપ્ત કરો. અલબત્ત, પ્રક્રિયાને સમાપ્ત કરવી અને 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 પ્રક્રિયા ID 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-Killer ફંક્શનને કૉલ કરે છે 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 કર્નલ પેરામીટર દ્વારા નિયંત્રિત થાય છે. આ માટે ચલ જવાબદાર છે 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