Paano Limitahan ang Memory at CPU sa systemd

Limitahan ang memory at CPU ng process gamit ang systemd drop-in

Nililimitahan mo ang memory at CPU ng process sa Linux VPS sa pamamagitan ng pagdaragdag ng ilang linya sa unit na nagpapatakbo sa process. Ang MemoryMax= ang hard ceiling ng memory. Ang CPUQuota= ang ceiling ng processor time. Pareho itong ipinapatupad ng cgroup v2 (control groups, version 2), ang kernel feature na ginagamit na ng systemd para subaybayan ang paggamit ng bawat service sa server.

sudo systemctl edit myapp.service

Binubuksan nito ang drop-in file na may mga instruction sa comments. Idagdag ito sa itaas ng mga iyon:

[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

Dapat ulitin ng systemctl show ang iyong mga numero gamit ang sariling units ng kernel: MemoryMax=805306368 at CPUQuotaPerSecUSec=800ms. Kung MemoryMax=infinity ang i-print nito, hindi na-load ang drop-in. Suriing nasa /etc/systemd/system/myapp.service.d/override.conf ang file at nagsisimula ito sa [Service] header, dahil kapag walang section sa itaas ng isang settings line, ila-log ng systemd ang Assignment outside of section. Ignoring. at sisimulan nito ang service nang walang anumang limitasyon.

Ipinapaliwanag ng natitirang bahagi ng guide na ito kung paano piliin ang mga numerong iyon at kung ano pa rin ang maaaring magkamali kapag naitakda na ang mga ito.

Bakit nagpi-freeze ang isang runaway process sa VPS kahit hindi nito nauubos ang memory

Ang process na umaabot sa hard memory cap ay namamatay pagkalipas ng humigit-kumulang isang segundo, at nagre-restart ang service. Ito ang magandang sitwasyon. Ang masamang sitwasyon ay kapag walang namamatay: sumasagot ang box sa ping, tinatanggap ng SSH ang connection, pero hindi lumalabas ang shell prompt. Buhay at abala ang machine, pero walang kapaki-pakinabang sa ginagawa nito.

Narito ang mekanismo, dahil hindi ito agad halata. Kapag kumokonti ang free memory, nire-reclaim ng kernel ang mga page sa halip na maglaan ng mga bago. Ang pinakamadaling i-reclaim ay ang file-backed pages, at nasa page cache ang executable code ng lahat ng tumatakbong process. Kaya inii-evict ng kernel ang text pages ng sshd, at ang susunod na instruction na tatakbuhin ng sshd ay isang page fault na kailangang basahin muli ang mga byte na iyon mula sa storage. Nauuwi ang bawat process sa paghihintay sa disk sa halip na pagtakbo. Paulit-ulit na umaalis at bumabalik ang parehong mga page. Tinatawag itong thrashing.

Dalawang bagay ang nagpapalala nito sa VPS kumpara sa laptop. Madalas na network-attached o shared ang storage, kaya mas maraming millisecond ang halaga ng bawat fault kaysa sa local NVMe device. Hindi rin oras ang sinusukat ng kernel. Failure ang sinusukat nito: habang nakakapagbalik ang reclaim ng isang page, gaano man ito kabagal, naniniwala ang kernel na may progress at hindi nito tinatawag ang out of memory (OOM) killer. Maaaring manatili ang box sa ganitong estado nang maraming minuto bago may mapatay na process.

Makikita mong nangyayari ito. Nag-e-export ang kernel ng pressure stall information (PSI) sa Linux 4.20 at mas bago:

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

Ang full line ang mahalaga. Ibig sabihin ng full avg10=48.15, sa nakalipas na sampung segundo, 48% ng oras ay stalled ang lahat ng runnable task sa box habang naghihintay ng memory work, kaya walang tumatakbo. Sa healthy server, malapit sa zero ang value ng full. Kapag lampas 10, mabagal na itong maramdaman ng user, at ang 40 o higit pa ay ang estadong inilalarawan ng mga tao bilang frozen.

Ito rin ang dahilan kung bakit hindi sapat ang limit lang bilang garantiya. Ang unit na nasa ilalim ng MemoryHigh= ay tina-throttle sa halip na patayin, kaya nananatili itong buhay at mabagal. Walang nagre-restart dito dahil, mula sa pananaw ng systemd, hindi naman ito nag-fail. Ang capped unit na pinapayagang gumamit pa rin ng swap ay bumubuo ng reads at writes na sinisingil sa unit na iyon pero pinoproseso ng iisang shared device. Dahil dito, maaari nitong pataasin ang /proc/pressure/io para sa lahat ng iba pang service sa box. Tinutukoy ng limits kung sino ang sasagot sa gastos ng kakulangan, pero hindi nito nalilikha ang capacity.

Tiyaking gumagamit ang iyong VPS ng cgroup v2

stat -fc %T /sys/fs/cgroup

cgroup2fs ang unified hierarchy na kailangan ng lahat ng setting sa ibaba. Ibig sabihin ng tmpfs ay nag-boot ang server gamit ang mas lumang v1 layout. Sa layout na iyon, wala ang MemoryHigh= at MemorySwapMax=, at iba ang OOM behavior sa bawat unit. Ubuntu 22.04 at mga mas bagong bersyon, pati Debian 11 at mga mas bagong bersyon, ay gumagamit ng v2 bilang default. Hindi ito ginagamit ng lumang image o ng kernel na nag-boot gamit ang systemd.unified_cgroup_hierarchy=0.

Sa cgroup v2, awtomatikong ino-on ng systemd ang memory accounting para sa bawat unit. Kaya available na agad ang mga value:

systemd-cgtop -m

Inililista nito ang mga cgroup ayon sa memory use, mula sa pinakamalaki. Ito ang pinakamabilis na paraan para malaman kung ano ang kumokonsumo ng resources sa server habang nakakasagot pa ito. Kung bago ang server, unahin ang account at firewall work sa unang sampung minuto sa bagong VPS bago ito.

Nagti-throttle ng MemoryHigh. Nagki-kill ang MemoryMax.

Ang pagkakaiba ng dalawang memory setting ang nagtatakda kung ano ang hitsura ng failure.

• MemoryHigh= ay soft cap. Kapag lumampas dito, agresibong nagre-reclaim ang kernel mula sa cgroup na iyon at sadyang pinapabagal ang mga allocation nito. Maaari pa ring lumampas ang usage sa value, at walang pinapatay.
• MemoryMax= ay hard cap. Kapag hindi na kayang matugunan ang allocation sa loob ng limitasyong ito, tumatakbo ang OOM killer sa loob ng cgroup na iyon at pinapatay ang isa sa mga sariling process ng unit.

Iyan ang tunay na dahilan kung bakit dapat itakda ang MemoryMax= sa anumang hindi mo lubos na pinagkakatiwalaan. Kapag walang cap, nagiging problema ng buong machine ang kakulangan sa memory, at pinipili ng global OOM killer ang biktima batay sa oom_score, na karaniwang nangangahulugang pinakamalaking process. Karaniwang database mo ang pinakamalaking process, hindi ang script na nag-leak. Kapag may cap, sa loob ng unit na sanhi nito napupunta ang kill.

Itakda ang dalawa, at panatilihing nasa 20 hanggang 30 porsiyentong mas mababa ang MemoryHigh= kaysa sa MemoryMax=. Warning zone ang pagitan: ang mabagal na leak ay lalampas sa High at lalabas bilang serbisyong bumagal, samantalang ang biglaang spike ay direktang lalampas sa Max at mamamatay.

Binabasa ang mga percentage value batay sa naka-install na physical memory, kaya ang MemoryMax=25% sa isang 4 GB plan ay 1 GB at mananatiling isang-kapat ng machine kahit i-resize mo ang plan. Ganap na inaalis ng MemorySwapMax=0 ang unit na iyon sa swap, kaya nagiging mabilis at malinaw na kill ang matagal na pagbagal.

May ilang serbisyo na hinahayaan kang itakda nang maaga ang memory na gagamitin ng mga ito sa halip na sukatin ito: sine-size ng isang Ollama unit ang KV cache nito batay sa context window na ibinibigay mo rito, kaya basahin ang gastos sa RAM ng pagtataas ng num_ctx bago pumili ng ceiling para rito.

Dapat may restart policy kasabay ng cap. Kung wala, titigil lang ang serbisyo matapos ang kill.

[Unit]
StartLimitIntervalSec=300
StartLimitBurst=5

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

Nasa [Unit] dapat ang StartLimit*, at nasa [Service] ang Restart=. Kapag inilagay ang alinman sa maling section, hindi ito pinapansin ng systemd. Ang limang restart sa loob ng limang minuto ay leak, hindi panandaliang aberya. Pagkatapos nito, susuko ang systemd at iiwan ang unit bilang failed. Iyan ang state na gusto mong makita sa susunod, sa halip na crash loop na nagtatago sa problema.

Limitahan ang CPU gamit ang CPUQuota, o hatiin ito gamit ang CPUWeight

CPUQuota= ang gumagamit ng porsiyento ng oras na available sa isang CPU. CPUQuota=50% ang katumbas ng kalahati ng isang core. CPUQuota=200% ang katumbas ng dalawang core, na maaaring ipamahagi ng unit sa kahit ilang thread na kailangan nito. Sa isang 2 vCPU plan, CPUQuota=200% ang buong machine.

CPUWeight= ang mas magandang default para sa karamihan ng mga serbisyo. Isa itong relative share mula 1 hanggang 10000, at 100 ang default ng kernel. May epekto lamang ito kapag may nagkukumpitensiya sa CPU: ang backup job na may CPUWeight=20 ay magbibigay-daan sa web server na may 100 kapag mataas ang load, at magagamit pa rin nito ang buong machine kapag idle ang machine. Sinasayang ng hard quota ang idle capacity na iyon.

Maging tumpak sa pakinabang ng CPU limit. Bihirang mapahinto ng CPU-bound process ang Linux, dahil patuloy na nagbibigay ang scheduler ng oras sa lahat ng proseso. Ang memory ang karaniwang nagpapabagsak sa machine. Gamitin ang CPUQuota= kapag kailangan mo ng predictable ceiling, halimbawa sa build o agent na kung hindi lilimitahan ay tatakbo nang todo sa loob ng isang oras. Ang pag-size ng ganitong workload ay hiwalay na usapin at tinatalakay sa kung gaano karaming RAM at CPU ang kailangan ng coding agent VPS.

Kung mukhang busy ang CPU kahit kaunti lamang ang ginagawa ng mga proseso mo, maaaring nasa kabilang panig ng hypervisor ang sanhi. Ito ang CPU steal time mula sa maingay na katabing tenant, at walang quota na itatakda mo ang makapagbabago rito.

TasksMax pinipigil ang fork loop

Ang TasksMax= ay ang bilang ng mga process at thread na maaaring hawakan ng isang unit. Kasama sa bilang ang mga thread, kaya mas maraming headroom ang kailangan ng Java o Go service kaysa sa ipinapakita ng process list. Ito ang pinakamurang proteksyon laban sa script na patuloy na nagfo-fork sa loop, dahil mabibigo ang fork sa loob ng unit sa halip na maubusan ng process ID ang buong server.

TasksMax=128

Kapag naabot ng isang unit ang limit, nagla-log ang kernel ng linya na naglalaman ng pangalan ng cgroup:

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

Karaniwang nag-uulat ang mismong program ng fork: retry: Resource temporarily unavailable. Suriin kung ano ang default na ipinapatupad ng manager gamit ang systemctl show -p DefaultTasksMax.

Limitahan ang isang one-off job gamit ang systemd-run

Hindi mo kailangan ng unit file para magamit ang mga ito. Gumagawa ang systemd-run ng transient unit para sa isang command.

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

Pinapatakbo ng --scope ang command sa terminal mo matapos ipakita ang Running scope as unit: run-r7c1a....scope. Nanatili sa screen mo ang output, at nawawala ang mga limit kapag natapos ang command. Gumagana ang anumang property mula sa systemd.resource-control pagkatapos ng -p.

Para sa matagal na job, alisin ang --scope at bigyan ito ng pangalan. Tatakbo ito sa background bilang transient service at magla-log sa journal:

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

Gumagana ang parehong option sa --user kapag hindi ka root, pero ang user manager mo ay may mga controller lamang na na-delegate rito, kaya maaaring tanggihan nito ang isang property. Patakbuhin ito gamit ang sudo kapag nangyari iyon. Kapag kailangan na ng permanenteng lugar ang isang job, ilipat nang walang pagbabago ang mga setting sa isang aktuwal na unit: tingnan ang pagpapatakbo ng script bilang systemd service at timer.

Ang swap, sinagot nang tapat

Binabago ng swap ang anyo ng failure sa halip na pigilan ito.

Kapag walang swap, umaabot sa limit ang memory leak at may namamatay sa loob ng ilang segundo. Maingay at maikli ang outage, at madaling basahin ang nangyari sa journal pagkatapos. Kapag may swap, isinusulat ng kernel sa disk ang mga cold anonymous page at nagbibigay ito ng dagdag na oras. Kung titigil sana sa pagtaas ang paggamit ng memory ng process, makakatulong ang swap. Kung runaway ito, ginagawang dalawampung minutong stall ng swap ang limang segundong outage. Mas masama ang stall dahil kapag namatay ang process, gumagana pa rin ang shell. Kapag nagta-thrash ang system, hindi.

swapon --show
free -h

Isang praktikal na setup sa maliit na VPS: panatilihin ang katamtamang laki ng swap file para sa mga page na isang beses lang ina-allocate at hindi na ginagamit muli, at itakda ang MemorySwapMax=0 sa mga unit na maaari mong mawala. Panatilihin ang swap para sa mahahalagang serbisyo. Ang mga hindi predictable na serbisyo ay mabilis na aabot sa limit at magre-restart.

Mahina lang na control ang pagpapababa ng vm.swappiness, at mahalagang malaman kung bakit. Binabago lang nito ang balanse sa pagitan ng pag-evict ng page cache at pag-swap ng anonymous page, at parehong mangangailangan ng disk read sa susunod. Binabago nito kung aling mga page ang nagta-thrash, hindi kung magta-thrash ang system.

Isang maagang OOM daemon ang pumapatay bago ang pagbagal

Hinihintay ng kernel na tuluyang mabigo ang reclaim. Sa maliit na VPS, ang paghihintay na iyon ang eksaktong pagitan kung kailan mawawala sa iyo ang machine. Isinasara ito ng dalawang userspace daemon sa pamamagitan ng sarili nilang pagmamanman sa memory at mas maagang pagpatay sa proseso.

earlyoom ang sumusubaybay sa available memory at free swap. Pinapatay nito ang prosesong may pinakamataas na score kapag bumaba sa threshold ang alinman sa mga ito.

sudo apt install earlyoom
systemctl status earlyoom

Awtomatikong sinisimulan ng Debian at Ubuntu package ang service kapag na-install ito. Nasa /etc/default/earlyoom ang mga option nito:

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

Itinatakda ng -m PERCENT ang minimum na available memory, at ng -s PERCENT ang minimum na free swap. Parehong 10 percent ang default. Ang ikalawang numero sa bawat pares ang SIGKILL point. Nagpapadala ang earlyoom ng SIGTERM kapag bumaba ka sa unang value, at SIGKILL kapag mas mababa na sa ikalawa. Bilang default, kalahati ito ng unang value. Ilapat ang pagbabago gamit ang sudo systemctl restart earlyoom. Basahin ang journalctl -u earlyoom upang makita kung aling proseso ang pinatay nito at kung gaano karaming memory ang hawak ng prosesong iyon.

systemd-oomd ang isa pang option. Inilalarawan ito ng manual page nito bilang “isang system service na gumagamit ng cgroups-v2 at pressure stall information (PSI) upang mag-monitor at magsagawa ng corrective action bago magkaroon ng OOM sa kernel space.” Kumakilos ito sa buong cgroup, hindi sa mga indibidwal na proseso. Dahil dito, unit ang pinapatay nito, hindi isang hiwalay na child process. Kailangang mag-opt in ang mga unit gamit ang ManagedOOMMemoryPressure=kill o ManagedOOMSwap=kill. Nasa /etc/systemd/oomd.conf ang mga threshold.

systemctl status systemd-oomd
oomctl

Ipinapakita ng oomctl kung ano ang kasalukuyang mino-monitor nito. Madalas ay wala itong mino-monitor sa server image dahil opt-in ang setting para sa bawat unit. Pumili ng isang daemon at doon na tumigil. Kapag pareho mong pinatakbo, magkakaroon ng dalawang proseso na nag-uunahang pumili ng biktima. Mas magiging mahirap tukuyin ang dahilan ng bawat pagpatay.

Aling unit ang may pananagutan?

Magsimula sa kernel, dahil itinatala nito ang bawat kill na ginagawa nito.

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

Ganito ang itsura ng kill mula sa global OOM killer:

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

Ang anon-rss ang memory na hawak ng process sa RAM nang mamatay ito, na humigit-kumulang 1.8 GB dito. Basahin nang may pag-iingat ang pangalan sa loob ng bracket. Iyon ang victim na pinili ng kernel. Pinipili ng kernel ang pinakamalaking process, ngunit hindi ito palaging process na naging sanhi ng kakulangan.

Iba ang prefix ng kill mula sa cgroup limit. Ang report na naka-print sa itaas nito ang nagpapakita kung aling cgroup ang umabot sa sarili nitong ceiling:

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

Karamihan ng diagnosis ay nasa prefix na iyon. Ang Memory cgroup out of memory ay nangangahulugang may isang unit na umabot sa MemoryMax= na itinakda mo, habang maayos ang natitirang bahagi ng box. Ang karaniwang Out of memory ay nangangahulugang naubusan ng memory ang buong machine. Ibig sabihin, maaaring walang caps o masyadong maluwag ang mga ito para sa pinagsamang paggamit.

Pagkatapos, itanong sa systemd kung ano ang nakita nito:

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'.

Sinasabi ng systemctl status ang parehong bagay sa isang linya, bilang Active: failed (Result: oom-kill).

Ang cgroup counters ang ikatlong source. Ito lamang ang nagtatala ng throttling, na hindi kailanman gumagawa ng log line:

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

Binibilang ng high kung ilang beses lumampas ang unit sa MemoryHigh= at na-throttle. Binibilang ng max kung gaano kadalas nitong naabot ang hard cap, at binibilang ng oom_kill ang mga process na aktuwal na pinatay. Ang malaking high na may oom_kill 0 ay ang tahimik na sitwasyong nabanggit kanina: tumatakbo ang service, sobrang bagal nito, at wala itong nai-report na failure sa sinuman. Nagtatala ang memory.peak (Linux 5.19 at mas bago) ng pinakamataas na usage na naabot ng cgroup. Ito ang numerong dapat pagbatayan sa pag-size ng MemoryMax=. Parehong nagre-reset ang dalawang file kapag nag-restart ang unit, dahil ginagawa muli ng systemd ang cgroup.

May isang prerequisite na pinagbabatayan ng lahat ng ito. Kung hindi umiiral ang /var/log/journal, nasa RAM ang journal. Mawawala ang bawat linya pagkatapos ng reboot na kinailangan mo para ma-recover ang box.

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

Ang journalctl --list-boots na nagpapakitang higit ito sa kasalukuyang boot ay nangangahulugang nananatili na ang history. Dahil dito, maipapakita sa iyo ng journalctl -k -b -1 ang mga kernel message mula sa boot na nag-crash.

Panimulang punto para sa maliit na VPS

Sa isang 2 GB plan, maglaan ng 300 hanggang 400 MB para sa kernel at page cache. Huwag hayaang umabot sa buong 2 GB ang kabuuan ng mga cap, dahil maaaring mag-peak nang sabay-sabay ang bawat unit. Ilaan ang pinakamalaking bahagi sa pinakamahalagang service, at limitahan ang lahat ng speculative service sa paligid nito.

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

Mahalagang may natitira kang paraan para makapasok sa server. OOMScoreAdjust=-500 sa isang drop-in para sa ssh.service ay lubos na nagpapaliit sa posibilidad na piliin ng global OOM killer ang SSH daemon bilang victim nito. Ito ang maaaring magtakda kung maaayos mo ang server o kailangan mo itong i-reboot mula sa control panel. Binabago lamang nito ang pinipiling victim ng kernel. Hindi nito pinaiikli ang stall.

Tumatakbo ang mga container sa sarili nilang cgroup. Ginagawa ang mga ito ng container runtime, hindi ng iyong unit files. Kaya ang limitasyon sa docker.service ay hindi nagiging limitasyon para sa isang container. Ang katumbas na per-container ng MemoryMax= at CPUQuota= ay ipinaliliwanag sa pagtatakda ng memory at CPU limits sa Docker Compose.

FAQ

Bakit nag-freeze ang aking VPS sa halip na patayin ang runaway process?

Dahil sinusukat ng kernel ang pag-usad batay sa kung nakakapag-reclaim ito ng pages, hindi sa tagal ng prosesong iyon. Kapag kapos ang memory, ine-evict nito ang page cache, kasama ang executable pages ng mga tumatakbong program, at binabasa muli ang mga ito sa susunod na instruction. Naghihintay ang lahat sa storage at wala pang allocation na teknikal na nag-fail, kaya hindi kailanman tinatawag ang OOM killer. Suriin ang /proc/pressure/memory habang nangyayari ito: ang full avg10 na lampas 40 ay nangangahulugang halos walang task ang nakatakbo sa nakalipas na sampung segundo. Ang userspace daemon gaya ng earlyoom ay pumapatay ng process bago umabot ang server sa ganitong kalagayan.

Ano ang pagkakaiba ng MemoryHigh at MemoryMax?

Ang MemoryHigh= ay soft cap na nagti-throttle. Mariing nagre-reclaim ang kernel mula sa unit at pinapabagal ang mga allocation nito, ngunit maaaring lumampas ang usage sa itinakdang numero at walang napapatay. Ang MemoryMax= ay hard cap: kapag hindi matugunan ang isang allocation habang nasa ilalim ng limitasyong ito, tinatawag ang OOM killer sa loob ng sariling cgroup ng unit. Dahil dito, ang process na nagdulot ng problema ang namamatay sa halip na ang pinakamalaking process sa server. Itakda ang MemoryHigh= na mas mababa sa MemoryMax= at ituring na warning zone ang pagitan ng dalawang ito.

Paano ko malalaman kung aling service ang tinamaan ng OOM killer?

Patakbuhin ang journalctl -k --grep "Killed process" --since "2 hours ago". Ang linyang nagsisimula sa Memory cgroup out of memory ay nangangahulugang may unit na lumampas sa sarili nitong MemoryMax=, samantalang ang karaniwang Out of memory ay nangangahulugang naubusan ng memory ang buong machine. Pagkatapos, patakbuhin ang journalctl -u <unit> -n 50 at hanapin ang Failed with result 'oom-kill'. Kung wala ang /var/log/journal sa iyong server, nasa RAM ang journal at nawala ang ebidensiya kasabay ng reboot. Gawin ang directory na iyon bago ang susunod na insidente.

Dapat ba akong magdagdag ng swap sa maliit na VPS?

Nakakatulong ang maliit na swap file sa cold pages na isang beses lang inilalaan at hindi na muling ginagamit. Hindi ito nakakatulong sa runaway process: ipinagpapaliban nito ang pagpatay sa process at pinapalitan ang maikling outage ng matagal na stall na hindi mo maa-access para ayusin. Panatilihing katamtaman ang swap, at itakda ang MemorySwapMax=0 sa mga unit na handa mong mawala. Sa gayon, maaabot ng mga ito ang ceiling at mabilis na magre-restart habang nananatiling may swap ang mahahalagang service.

Maaari ko bang limitahan ang isang command nang hindi gumagawa ng unit file?

Oo. Pinapatakbo ng sudo systemd-run --scope -p MemoryMax=1G -p CPUQuota=50% ./script.sh ang command sa iyong terminal sa loob ng transient scope na may mga limitasyong iyon, at nawawala ang mga limitasyon kapag nag-exit ito. Available ang bawat property mula sa systemd.resource-control pagkatapos ng -p, kaya gumagana rin doon ang MemorySwapMax=, TasksMax=, at CPUWeight=. Alisin ang --scope at idagdag ang --unit=name upang patakbuhin ang job sa background at ilagay ang output nito sa journal.