Jinsi ya kupunguza matumizi ya CPU na RAM kwa systemd

Kuwekea mchakato kikomo cha kumbukumbu na CPU kwa kutumia systemd drop-in

Unaweka kikomo cha kumbukumbu na CPU kwa mchakato kwenye Linux VPS kwa kuongeza mistari michache kwenye unit inayouendesha mchakato huo. MemoryMax= ni kikomo cha juu cha kumbukumbu. CPUQuota= ni kikomo cha muda wa processor. Vyote vinasimamiwa na cgroup v2 (control groups, version 2), kipengele cha kernel ambacho systemd tayari inakitumia kufuatilia kila huduma kwenye seva.

sudo systemctl edit myapp.service

Hii inafungua faili ya drop-in yenye maelekezo kwenye maoni. Ongeza mistari hii hapo juu:

[Service]
MemoryHigh=512M
MemoryMax=768M
MemorySwapMax=0
CPUQuota=80%
TasksMax=128

sudo systemctl daemon-reload
sudo systemctl restart myapp.service
systemctl show myapp.service -p MemoryHigh -p MemoryMax -p CPUQuotaPerSecUSec -p TasksMax

systemctl show lazima irudishe namba zako kwa kutumia vipimo vya kernel vyenyewe: MemoryMax=805306368 na CPUQuotaPerSecUSec=800ms. Ikiwa inachapisha MemoryMax=infinity, basi drop-in haikupakiwa. Hakikisha faili imetua kwenye /etc/systemd/system/myapp.service.d/override.conf, na kwamba inaanza na kichwa cha habari cha [Service], kwa sababu mstari wa mipangilio usio na sehemu (section) hapo juu huifanya systemd kuandika Assignment outside of section. Ignoring. kwenye logi na kuanzisha huduma bila vikomo vyovyote.

Sehemu iliyobaki ya mwongozo huu inaelezea jinsi ya kuchagua namba hizo, na nini kinaweza kwenda vibaya baada ya kuwekwa.

Kwa nini mchakato unaokimbia bila mpangilio hugandisha VPS hata kama haujajaza kumbukumbu

Mchakato unaofikia kikomo cha kumbukumbu hufa ndani ya sekunde moja na huduma huanza upya. Hiyo ndiyo hali nzuri. Hali mbaya ni ile ambapo hakuna kinachokufa: seva inajibu ping, SSH inakubali muunganisho, lakini prompt ya shell haionekani. Mashine iko hai na ina shughuli nyingi, na hakuna kazi kati ya hizo inayofaa.

Huu hapa ni utaratibu wake, kwa sababu si dhahiri. Kumbukumbu ya bure inapopungua, kernel hurejesha kurasa (pages) badala ya kutoa mpya. Kurasa za bei nafuu zaidi kurejeshwa ni zile zinazotegemea faili, na page cache huhifadhi msimbo wa executable wa kila kitu kinachoendeshwa. Kwa hivyo, kernel huondoa kurasa za maandishi za sshd, na maagizo yanayofuata ambayo sshd huendesha ni page fault inayolazimika kusoma baiti hizo kutoka kwenye hifadhi. Kila mchakato huishia kusubiri diski badala ya kuendesha. Kurasa hizo hizo huondoka na kurudi katika mzunguko, jambo linaloitwa thrashing.

Mambo mawili hufanya hali hii kuwa mbaya zaidi kwenye VPS kuliko kwenye kompyuta ya mkononi. Hifadhi mara nyingi huunganishwa kupitia mtandao au inashirikiwa, kwa hivyo kila fault hugharimu milisekunde nyingi zaidi kuliko kifaa cha ndani cha NVMe. Na kernel haipimi muda, inapima kushindwa: mradi tu urejeshaji unaendelea kutoa ukurasa, hata kwa polepole, kernel huamini kuwa inapiga hatua na haitoi amri ya out of memory (OOM) killer. Seva inaweza kukaa katika hali hiyo kwa dakika nyingi kabla ya kitu chochote kuuawa.

Unaweza kutazama hali hiyo ikitokea. Kernel hutoa taarifa za pressure stall information (PSI) kwenye Linux 4.20 na matoleo mapya zaidi:

cat /proc/pressure/memory
cat /proc/pressure/io

some avg10=63.72 avg60=41.02 avg300=12.33 total=13729481
full avg10=48.15 avg60=30.44 avg300=8.90 total=9114233

Mstari wa full ndio unaohusika. full avg10=48.15 inamaanisha kuwa katika sekunde kumi zilizopita, 48% ya muda kila kazi inayoweza kuendeshwa kwenye seva ilikuwa imekwama ikisubiri kazi ya kumbukumbu, kwa hivyo hakuna kilichoendeshwa. Seva yenye afya husoma karibu na sifuri kwenye full. Zaidi ya 10, mtumiaji huhisi polepole, na 40 au zaidi ni hali ambayo watu huielezea kama kuganda.

Hii ndiyo sababu kikomo pekee si ahadi. Kitengo kinachoshikiliwa chini ya MemoryHigh= hupunguzwa kasi badala ya kuuawa, kwa hivyo kinabaki hai na kinabaki polepole, na hakuna kinachokianzisha upya kwa sababu kwa mtazamo wa systemd hakijawahi kushindwa. Kitengo kilichowekewa kikomo ambacho bado kinaruhusiwa kutumia swap huzalisha usomaji na uandikaji unaotozwa kwa kitengo hicho lakini unaohudumiwa na kifaa kimoja kinachoshirikiwa, kwa hivyo kinaweza kusukuma /proc/pressure/io juu kwa kila huduma nyingine kwenye seva. Vikomo huamua nani anayelipia uhaba, na haviwezi kuunda uwezo mpya.

Thibitisha kuwa VPS yako inaendesha cgroup v2

stat -fc %T /sys/fs/cgroup

cgroup2fs ni mfumo wa uongozi uliounganishwa (unified hierarchy), ambao ndio unaohitajika kwa kila mpangilio ulio hapa chini. tmpfs inamaanisha kuwa seva imewaka kwa kutumia mpangilio wa zamani wa v1, ambapo MemoryHigh= na MemorySwapMax= havipo na tabia ya OOM kwa kila unit ni tofauti. Ubuntu 22.04 na matoleo mapya zaidi, pamoja na Debian 11 na matoleo mapya zaidi, hutumia v2 kwa chaguo-msingi. Image ya zamani, au kernel iliyowashwa kwa kutumia systemd.unified_cgroup_hierarchy=0, haitumii v2.

Kwenye cgroup v2, systemd huwasha ufuatiliaji wa kumbukumbu (memory accounting) kwa kila unit kwa chaguo-msingi, kwa hivyo namba hizo tayari zipo:

systemd-cgtop -m

Hiyo huorodhesha cgroups zilizopangwa kulingana na matumizi ya kumbukumbu, ambayo ndiyo njia ya haraka zaidi ya kujibu "nini kinachotumia rasilimali za seva hii" wakati bado inajibu. Ikiwa seva ni mpya, kazi ya akaunti na firewall iliyo kwenye dakika kumi za kwanza kwenye VPS mpya inapaswa kufanyika kabla ya hatua hii.

MemoryHigh hupunguza kasi. MemoryMax huua mchakato.

Tofauti kati ya mipangilio hii miwili ya kumbukumbu huamua jinsi hitilafu inavyoonekana.

• MemoryHigh= ni kikomo laini (soft cap). Inapovukwa, kernel hurejesha kumbukumbu kwa nguvu kutoka kwa cgroup hiyo na kupunguza kasi ya ugawaji wa kumbukumbu kwa makusudi. Matumizi yanaweza kuzidi namba hiyo, na hakuna mchakato unaouawa.
• MemoryMax= ni kikomo kigumu (hard cap). Ugawaji wa kumbukumbu unaposhindikana chini ya kikomo hiki, OOM killer hufanya kazi ndani ya cgroup hiyo na kuua mchakato mmoja wa unit hiyo.

Nusu ya pili ndiyo sababu kuu ya kuweka MemoryMax= kwenye huduma yoyote ambayo huiamini kikamilifu. Bila kikomo, uhaba wa kumbukumbu huwa tatizo la seva nzima, na OOM killer ya mfumo mzima huchagua mwathiriwa kulingana na oom_score, ambayo mara nyingi inamaanisha mchakato mkubwa zaidi. Mchakato mkubwa zaidi kwa kawaida ni database yako, si script iliyovuja kumbukumbu. Ukiwa na kikomo, mauaji hutokea ndani ya unit iliyosababisha tatizo.

Weka zote mbili, huku MemoryHigh= ikiwa asilimia 20 hadi 30 chini ya MemoryMax=. Pengo hilo ni eneo la onyo: uvujaji wa polepole huvuka High na kuonekana kama huduma iliyopungua kasi, wakati ongezeko la ghafla hupita moja kwa moja kupitia Max na kufa.

Thamani za asilimia hulinganishwa na kumbukumbu halisi iliyopo (physical memory), kwa hivyo MemoryMax=25% kwenye mpango wa 4 GB ni 1 GB na itabaki kuwa robo ya seva hata ukibadilisha ukubwa wa mpango huo. MemorySwapMax=0 huizuia unit hiyo kutumia swap kabisa, jambo linalobadilisha mchakato wa polepole kuwa kifo cha haraka na dhahiri.

Huduma chache hukuruhusu kuamua mahitaji yake mapema badala ya kuyapima: unit ya Ollama hupanga ukubwa wa KV cache yake kulingana na context window unayoiweka, kwa hivyo soma gharama za RAM kwa kuongeza num_ctx kabla ya kuchagua kikomo cha unit hiyo.

Kikomo kinahitaji sera ya kuanzisha upya (restart policy) kando yake, vinginevyo kifo cha mchakato kitakuacha na huduma iliyosimama.

[Unit]
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Restart=on-failure
RestartSec=5s

StartLimit* inapaswa kuwekwa kwenye [Unit] na Restart= kwenye [Service]. Ukiweka mojawapo kwenye sehemu isiyo sahihi, systemd itaipuuza. Kuanzisha upya mara tano ndani ya dakika tano ni ishara ya uvujaji badala ya tatizo la muda mfupi, kwa hivyo baada ya hapo systemd huacha kujaribu na kuiacha unit ikiwa katika hali ya failed, ambayo ndiyo hali unayotaka kuikuta baadaye badala ya crash loop inayoficha tatizo.

Punguza matumizi ya CPU kwa CPUQuota, au igawane kwa kutumia CPUWeight

CPUQuota= huchukua asilimia ya muda unaopatikana kwenye CPU moja. CPUQuota=50% ni nusu ya core moja. CPUQuota=200% ni sawa na core mbili, ambazo kitengo kinaweza kuzisambaza kwenye threads nyingi kadiri kinavyotaka. Kwenye mpango wa 2 vCPU, CPUQuota=200% ni mashine nzima.

CPUWeight= ni chaguo bora zaidi kwa huduma nyingi. Hii ni sehemu ya uwiano kuanzia 1 hadi 10000, na thamani ya msingi ya kernel ni 100. Inafanya kazi tu wakati kuna ushindani: kazi ya backup iliyowekwa kwenye CPUWeight=20 itapisha web server iliyo kwenye 100 wakati wa msongamano, na bado itatumia mashine nzima wakati haina kazi. Quota ngumu hupoteza uwezo huo wa ziada.

Kuwa mkweli kuhusu faida unayopata kwa kuweka kikomo cha CPU. Mchakato unaotumia CPU nyingi mara chache husababisha Linux kuganda, kwa sababu scheduler huendelea kutoa muda kwa kila mchakato. Kumbukumbu (RAM) ndiyo inayoweza kuangusha seva. Tumia CPUQuota= unapotaka kikomo kinachotabirika, kwa mfano kwenye kazi ya build au agent ambayo ingeweza kufanya kazi kwa kasi ya juu kwa saa nzima. Kupima ukubwa wa kazi ya aina hiyo ni swali tofauti, linalojadiliwa katika kiasi gani cha RAM na CPU ambacho VPS ya coding agent inahitaji.

Ikiwa CPU inaonekana kuwa na shughuli nyingi wakati hakuna mchakato wako unaofanya kazi kubwa, sababu inaweza kuwa upande mwingine wa hypervisor. Hiyo ni CPU steal time kutoka kwa jirani mwenye kelele, na hakuna quota utakayoweka itakayobadilisha hali hiyo.

TasksMax inazuia fork loop

TasksMax= ni idadi ya processes na threads ambazo unit inaweza kuwa nazo. Threads huhesabiwa, kwa hivyo huduma ya Java au Go inahitaji nafasi kubwa zaidi kuliko inavyoonekana kwenye orodha ya processes. Hii ndiyo njia rahisi zaidi ya kujilinda dhidi ya script inayofanya fork kwenye loop, kwa sababu fork inafeli ndani ya unit badala ya seva kuishiwa na process IDs.

TasksMax=128

Wakati unit inapofikia kikomo hiki, kernel huandika mstari kwenye logi unaotaja cgroup husika:

cgroup: fork rejected by pids controller in /system.slice/myapp.service

Programu yenyewe kwa kawaida huripoti fork: retry: Resource temporarily unavailable. Angalia kile ambacho meneja hutumia kwa chaguo-msingi kwa kutumia systemctl show -p DefaultTasksMax.

Kuwekea kikomo kazi ya mara moja kwa kutumia systemd-run

Hauhitaji faili ya unit ili kutumia haya yote. systemd-run hutengeneza unit ya muda mfupi kuzunguka amri moja.

sudo systemd-run --scope -p MemoryMax=1G -p MemorySwapMax=0 -p CPUQuota=50% -p TasksMax=64 ./import-data.sh

--scope huendesha amri hiyo kwenye terminal yako, baada ya kuchapisha Running scope as unit: run-r7c1a....scope. Matokeo hubaki kwenye skrini yako na vikomo hivyo hupotea wakati amri inapomaliza kufanya kazi. Sifa yoyote kutoka systemd.resource-control hufanya kazi baada ya -p.

Kwa kazi ndefu, ondoa --scope na uipe jina. Kisha huendesha kwa nyuma kama huduma ya muda mfupi na kuandika kumbukumbu kwenye journal:

sudo systemd-run --unit=nightly-import -p MemoryMax=1G -p CPUWeight=20 ./import-data.sh
journalctl -u nightly-import -f

Chaguzi zilezile hufanya kazi na --user wakati wewe si root, ingawa meneja wa mtumiaji wako anayo tu vidhibiti vilivyokabidhiwa kwake, kwa hivyo sifa inaweza kukataliwa hapo. Iendeshe na sudo ikiwa hilo litatokea. Wakati kazi inapopata makazi ya kudumu, mipangilio huhamia bila kubadilika kwenda kwenye unit halisi: angalia kuendesha script kama systemd service na timer.

Swali la swap, limejibiwa kwa uaminifu

Swap hubadili namna ya kutokea kwa hitilafu badala ya kuizuia.

Bila swap, leak ikifika ukomo, kitu fulani hufa ndani ya sekunde chache. Outage hiyo huwa ya ghafla, fupi na rahisi kusomeka kwenye journal baadaye. Ukiwa na swap, kernel huandika anonymous pages zisizotumika kwenye disk na kununua muda. Ikiwa mchakato ulikuwa unakaribia kutulia, swap itakuokoa. Ikiwa ni runaway, swap hubadili outage ya sekunde tano kuwa mkwamo wa dakika ishirini, na mkwamo huo ni mbaya zaidi, kwa sababu mchakato uliokufa bado hukuacha na shell inayofanya kazi, wakati mashine inayopata thrashing haifanyi kazi.

swapon --show
free -h

Njia ya kati inayofaa kwenye VPS ndogo: weka swap file ya wastani kwa ajili ya pages zilizotengwa mara moja na zisizoguswa tena, na uweke MemorySwapMax=0 kwenye units ambazo uko tayari kuzipoteza. Huduma muhimu hubaki na swap yao. Zile zisizotabirika hugonga ukuta haraka na kuanza upya.

Kupunguza vm.swappiness ni njia dhaifu, na ni muhimu kujua kwa nini. Inabadili tu uwiano kati ya kuondoa page cache na kufanya swapping ya anonymous pages, na zote mbili hugharimu disk read baadaye. Inabadili ni pages zipi zinazopata thrashing, si kama mashine itapata thrashing au la.

Daemon ya mapema ya OOM huua kabla ya kukwama

Kernel husubiri hadi mchakato wa reclaim ushindwe kabisa, na kwenye VPS ndogo, kusubiri huko ndiko kunakofanya upoteze seva. Daemons mbili za userspace hufunga pengo hili kwa kufuatilia kumbukumbu zenyewe na kuua mapema zaidi.

earlyoom hufuatilia kumbukumbu inayopatikana na swap iliyo wazi, na huua mchakato wenye alama ya juu zaidi wakati wowote mojawapo inaposhuka chini ya kizingiti.

sudo apt install earlyoom
systemctl status earlyoom

Kifurushi cha Debian na Ubuntu huanzisha huduma hii wakati wa usakinishaji. Chaguzi zake zipo kwenye /etc/default/earlyoom:

EARLYOOM_ARGS="-m 5,2 -s 5,2 --avoid '^(sshd|systemd)$' --prefer '^(node|python3)$'"

-m PERCENT huweka kiwango cha chini cha kumbukumbu inayopatikana na -s PERCENT huweka kiwango cha chini cha swap, zote zikiwa asilimia 10 kwa chaguomsingi. Namba ya pili katika kila jozi ni hatua ya SIGKILL: earlyoom hutuma SIGTERM pindi unaposhuka chini ya thamani ya kwanza, kisha SIGKILL chini ya ya pili, ambayo kwa chaguomsingi ni nusu ya ya kwanza. Tekeleza mabadiliko kwa sudo systemctl restart earlyoom, na usome journalctl -u earlyoom ili kuona ni mchakato gani uliouawa na kiasi gani cha kumbukumbu mchakato huo ulikuwa unatumia.

systemd-oomd ni chaguo jingine. Ukurasa wake wa mwongozo unaielezea kama "huduma ya mfumo inayotumia cgroups-v2 na pressure stall information (PSI) kufuatilia na kuchukua hatua za kurekebisha kabla ya OOM kutokea katika kernel space". Inafanya kazi kwenye cgroups nzima badala ya michakato binafsi, kwa hivyo huua unit, si mtoto mmoja aliyepotea. Units hujiunga na huduma hii kwa ManagedOOMMemoryPressure=kill au ManagedOOMSwap=kill, na vizingiti vipo kwenye /etc/systemd/oomd.conf.

systemctl status systemd-oomd
oomctl

oomctl huchapisha kile inachofuatilia kwa sasa, ambacho mara nyingi huwa hakuna kitu kwenye image ya seva, kwa sababu mpangilio huu unahitaji kujiunga kwa kila unit. Chagua daemon moja na uishie hapo. Kuendesha zote mbili kunamaanisha vitu viwili vinashindana kuchagua mhasiriwa, na sababu ya mauaji yoyote inakuwa ngumu zaidi kufuatilia.

Ni kitengo kipi kilichohusika?

Anza na kernel, kwa sababu inarekodi kila mchakato inaouua.

journalctl -k --grep "Killed process" --since "2 hours ago"

Uuaji kutoka kwa OOM killer wa mfumo mzima huonekana hivi:

Out of memory: Killed process 4127 (node) total-vm:2731084kB, anon-rss:1874232kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:4212kB oom_score_adj:0

anon-rss ni kumbukumbu ambayo mchakato huo ulikuwa umeishikilia kwenye RAM wakati unafariki, takriban 1.8 GB hapa. Soma jina lililo kwenye mabano kwa tahadhari. Huyo ndiye mwathiriwa aliyechaguliwa na kernel, na kernel huchagua mchakato mkubwa zaidi, ambao si lazima uwe ndio uliosababisha uhaba wa kumbukumbu.

Uuaji unaotokana na kikomo cha cgroup huwa na kiambishi tofauti, na ripoti iliyochapishwa juu yake hutaja cgroup iliyogonga kikomo chake yenyewe:

Memory cgroup out of memory: Killed process 8811 (python3) total-vm:1044320kB, anon-rss:769112kB, file-rss:0kB, shmem-rss:0kB, UID:998 pgtables:1720kB oom_score_adj:0

Kiambishi hicho ndicho kiini cha utambuzi. Memory cgroup out of memory inamaanisha kitengo kimoja kiligonga MemoryMax= uliyokipa na sehemu nyingine ya seva ilikuwa salama. Out of memory tupu inamaanisha mashine nzima iliishiwa na kumbukumbu, kwa hivyo vikomo vyako vilikuwa havipo au vilikuwa vikubwa mno kiasi cha kuzidi uwezo.

Kisha iulize systemd kile ilichokiona:

systemctl status myapp.service
journalctl -u myapp.service -n 50

myapp.service: A process of this unit has been killed by the OOM killer.
myapp.service: Main process exited, code=killed, status=9/KILL
myapp.service: Failed with result 'oom-kill'.

systemctl status inasema kitu kilekile kwa mstari mmoja, kama Active: failed (Result: oom-kill).

Kaunta za cgroup ndizo chanzo cha tatu, na ndizo pekee zinazorekodi throttling, ambayo haitoi mstari wowote wa logi:

cat /sys/fs/cgroup/system.slice/myapp.service/memory.events
cat /sys/fs/cgroup/system.slice/myapp.service/memory.peak

low 0
high 4213
max 118
oom 12
oom_kill 12

high huhesabu mara ngapi kitengo kilisukumwa zaidi ya MemoryHigh= na kupunguzwa kasi (throttled). max huhesabu mara ngapi kilifikia kikomo kikuu (hard cap), na oom_kill huhesabu michakato iliyouawa kweli. high kubwa ikiwa na oom_kill 0 ni kisa cha kimya kilichotajwa awali: huduma inaendelea kufanya kazi, imepunguzwa kasi hadi kutambaa, na haijaripoti kosa lolote kwa yeyote. memory.peak (Linux 5.19 na matoleo mapya zaidi) huhifadhi matumizi ya juu zaidi ambayo cgroup ilifikia, ambayo ndiyo namba ya kutumia kupima MemoryMax=. Faili zote mbili hujirekebisha (reset) wakati kitengo kinapoanzishwa upya, kwa sababu systemd hutengeneza cgroup hiyo upya.

Sharti moja lipo chini ya haya yote. Ikiwa /var/log/journal haipo, journal huishi kwenye RAM, na kila mstari hupotea baada ya reboot uliyohitaji ili kuirejesha seva.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --list-boots

journalctl --list-boots inayoonyesha zaidi ya boot ya sasa inamaanisha historia sasa inahifadhiwa, kwa hivyo journalctl -k -b -1 inaweza kukuonyesha ujumbe wa kernel kutoka kwenye boot iliyokufa.

Sehemu ya kuanzia kwa VPS ndogo

Kwenye mpango wa 2 GB, acha 300 hadi 400 MB kwa ajili ya kernel na page cache, na usiruhusu jumla ya mipaka (caps) ifikie 2 GB kamili, kwa sababu kila kitengo kinaweza kufikia kilele cha matumizi kwa wakati mmoja. Ipe huduma muhimu sehemu kubwa zaidi, kisha wekea mipaka huduma zote zisizo za lazima zinazoizunguka.

[Service]
MemoryHigh=256M
MemoryMax=384M
MemorySwapMax=0
CPUWeight=20
TasksMax=64
Restart=on-failure
RestartSec=5s

Kuweka njia ya kuingia ni muhimu kwa mpangilio mmoja zaidi. OOMScoreAdjust=-500 katika faili ya drop-in ya ssh.service hufanya OOM killer wa mfumo mzima kuwa na uwezekano mdogo sana wa kuchagua SSH daemon yako kama mwathiriwa, jambo ambalo ni tofauti kati ya kurekebisha seva na kuianzisha upya kutoka kwenye control panel. Hii inabadilisha tu chaguo la kernel la nani wa kumuua. Haifupishi muda wa kukwama kwa mfumo.

Containers huendeshwa katika cgroups zao wenyewe, zilizoundwa na container runtime badala ya unit files zako, kwa hivyo kikomo kwenye docker.service hakigeuki kuwa kikomo cha container moja. Mambo yanayolingana na MemoryMax= na CPUQuota= kwa kila container yamefafanuliwa katika kuweka mipaka ya kumbukumbu na CPU katika Docker Compose.

FAQ

Kwa nini VPS yangu iliganda badala ya kuua mchakato uliopoteza udhibiti?

Kwa sababu kernel hupima maendeleo kwa kuangalia kama reclaim inarejesha kurasa za kumbukumbu, si kwa muda unaotumika. Wakati kumbukumbu ni haba, kernel huondoa page cache, ikiwemo kurasa za programu zinazoendelea, kisha huzisoma tena wakati wa maelekezo yanayofuata. Kila kitu husubiri hifadhi (storage) na hakuna allocation iliyoshindwa kitaalamu, kwa hivyo OOM killer haiamshwi. Chunguza /proc/pressure/memory wakati tatizo likiendelea: full avg10 inayozidi 40 inamaanisha karibu hakuna kazi iliyoweza kutekelezwa katika sekunde kumi zilizopita. Daemon ya userspace kama earlyoom huua mchakato kabla ya seva kufikia hali hiyo.

Kuna tofauti gani kati ya MemoryHigh na MemoryMax?

MemoryHigh= ni kikomo laini (soft cap) kinachopunguza kasi ya matumizi. Kernel hufanya reclaim kwa bidii kutoka kwa unit hiyo na kupunguza kasi ya allocation zake, lakini matumizi yanaweza kuzidi namba hiyo na hakuna kinachouawa. MemoryMax= ni kikomo kigumu (hard cap): allocation inayoshindwa kukidhi kikomo hiki huamsha OOM killer ndani ya cgroup ya unit hiyo, hivyo mchakato uliosababisha tatizo ndio unaokufa badala ya mchakato mkubwa zaidi kwenye seva. Weka MemoryHigh= chini ya MemoryMax= na chukulia nafasi iliyo katikati yao kama eneo la onyo.

Ninawezaje kujua ni huduma gani iliyopigwa na OOM killer?

Tekeleza journalctl -k --grep "Killed process" --since "2 hours ago". Mstari unaoanza na Memory cgroup out of memory unamaanisha unit moja imegonga MemoryMax= yake yenyewe, wakati Out of memory ya kawaida inamaanisha mashine nzima imekosa kumbukumbu. Kisha tekeleza journalctl -u <unit> -n 50 na utafute Failed with result 'oom-kill'. Ikiwa /var/log/journal haipo kwenye seva yako, journal ilikuwa imehifadhiwa kwenye RAM na ushahidi ulipotea wakati wa reboot, kwa hivyo tengeneza saraka hiyo kabla ya tukio lijalo.

Je, niongeze swap kwenye VPS ndogo?

Faili ndogo ya swap husaidia na kurasa za "cold" ambazo hutengwa mara moja na haziguswi tena. Haikusaidia na mchakato uliopoteza udhibiti: inachelewesha kifo cha mchakato na kubadilisha kukatika kwa muda mfupi na kuganda kwa muda mrefu ambako huwezi kuingia ili kurekebisha. Weka swap kwa kiasi kidogo, na uweke MemorySwapMax=0 kwenye unit ambazo uko tayari kuzipoteza, ili zifikie kikomo chake na kuanza upya haraka wakati huduma muhimu zikibaki na swap yao.

Je, ninaweza kuwekea amri kikomo bila kuandika unit file?

Ndiyo. sudo systemd-run --scope -p MemoryMax=1G -p CPUQuota=50% ./script.sh huendesha amri kwenye terminal yako ndani ya transient scope yenye vikomo hivyo, na vikomo hivyo hupotea inapomaliza. Kila sifa kutoka systemd.resource-control inapatikana baada ya -p, kwa hivyo MemorySwapMax=, TasksMax= na CPUWeight= hufanya kazi hapo pia. Ondoa --scope na uongeze --unit=name ili kuendesha kazi hiyo kwa nyuma (background) huku matokeo yake yakiwa kwenye journal.