આઉટ-ઓફ-મેમરી કિલર સેટ કરી રહ્યું છે 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 પ્રક્રિયા 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 ઉપલબ્ધ કરતાં પ્રક્રિયાઓ માટે વધુ મેમરી અનામત રાખી શકે છે, પરંતુ વાસ્તવમાં તેને ફાળવી શકતી નથી, અને આ વર્તણૂક કર્નલ પરિમાણ દ્વારા નિયંત્રિત થાય છે. 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