Temu Duga Linux: Bagaimanakah Anda Mendiagnosis OOM Kill?

Prompt dan Bila Ia Terpakai

Satu nod Linux 64 GiB masih mempunyai 18 GiB MemAvailable, tetapi satu bekas berulang kali keluar selama tempoh enam jam. Masa jalanan (runtime) merekodkan OOMKilled dan kod keluar 137. memory.max cgroup v2 beban kerja tersebut ialah 4 GiB; sebelum kegagalan berlaku, memory.current menghampiri had tersebut dan oom_kill meningkat dalam memory.events. Dalam tempoh yang sama, anon dalam memory.stat meningkat daripada 1.2 GiB kepada 3.5 GiB manakala file adalah sekitar 280 MiB. Terangkan bagaimana anda akan membuktikan pencetusnya, membezakan cgroup OOM daripada OOM global, mengesan punca pertumbuhan, membendung insiden dengan selamat, dan menghalang ia berulang.

Angka 64 GiB, 18 GiB, 4 GiB, tempoh masa enam jam, dan statistik penggunaan adalah andaian temu duga, bukan penanda aras kapasiti sebenar. Andaikan Linux menggunakan cgroup v2 dan status runtime serta fail cgroup merujuk kepada tempoh kegagalan yang sama. Soalan ini tergolong dalam general kerana ia menguji penebusan (reclaim) sistem pengendalian, perakaunan cgroup, bukti OOM, dan pengendalian proses; platform bekas hanya menyediakan tetapannya.

Bahan temu duga awam Linux dan sistem pengendalian yang diterbitkan pada tahun 2026 secara langsung merangkumi senario OOM dan meminta calon membuat penaakulan berdasarkan log kernel, had sumber, dan tingkah laku proses. Jawapan yang lengkap perlu melangkaui "tambah memori" atau "saya nampak 137": ia memerlukan rantaian bukti, pembendungan yang selamat, atribusi punca, dan ujian yang boleh diulang bagi membuktikan bahawa pembaikan tersebut berkesan.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon mentafsir bukti dengan betul. Di bawah konvensyen status keluar Bash, 137 boleh menjadi 128 ditambah isyarat 9, jadi ia menyatakan bahawa proses tersebut ditamatkan disebabkan oleh SIGKILL. Pentadbir, pengawal masa tamat (timeout controller), atau pembunuh OOM (OOM killer) semuanya boleh menghantar isyarat tersebut. Sebab OOMKilled daripada runtime, peningkatan dalam memory.events:oom_kill dalam tempoh masa yang sama, dan log kernel adalah perkara yang memperincikan puncanya kepada OOM.

Isyarat kedua ialah sama ada calon mengenal pasti domain sumber. memory.max ialah had ketat (hard limit) cgroup. Jika penggunaan mencapainya dan proses reclaim tidak dapat mengurangkan caj tersebut, kernel boleh mencetuskan OOM di dalam cgroup itu. Nod tersebut masih boleh mempunyai 18 GiB yang tersedia. Sebaliknya, OOM global berpunca daripada tekanan peruntukan di seluruh nod, dengan kelompok mangsa yang berbeza dan tindakan pemulihan yang berbeza.

Isyarat ketiga ialah disiplin perakaunan memori. Hanya melihat pada RSS satu proses akan terlepas proses keturunan (descendants), cache halaman (page cache), tmpfs, memori kongsi (shared memory), penimbal soket (socket buffers), dan data kernel yang dicajkan kepada cgroup yang sama. Jawapan yang kukuh memadankan memory.current, memory.peak, memory.stat, ukuran per-proses, dan profil aplikasi dan bukannya menganggap VSZ, RSS, dan caj cgroup sebagai perkara yang setara.

Akhir sekali, penemu duga menilai pertimbangan insiden. Menaikkan had buat sementara waktu mungkin dapat memulihkan perkhidmatan, atau ia mungkin mengubah kebocoran yang berterusan menjadi kegagalan di seluruh nod. Jawapan tersebut harus menerangkan bila masa yang sesuai untuk mengurangkan beban (shed load), memulakan semula (restart), menskalakan, atau menaikkan had; cara membezakan lonjakan normal daripada kebocoran; dan bagaimana ujian beban (load test), ujian rendaman (soak test), dan ujian kegagalan mengesahkan dasar tersebut.

Soalan untuk Dijelaskan Sebelum Menjawab

• Adakah rekod-rekod tersebut merujuk kepada tika (instance) bekas dan tempoh kegagalan yang sama? Status OOMKilled yang lama, pembilang

cgroup semasa, dan penamatan keluar yang berbeza tidak boleh membentuk rantaian sebab-akibat. Selaraskan ID bekas, masa mula dan masa keluar, serta laluan.

• Adakah hos benar-benar menggunakan cgroup v2? v1 dan v2 mendedahkan fail dan semantik yang berbeza. Sahkan sama ada laluan tersebut

merupakan cgroup bekas atau cgroup induk yang mengandungi beberapa beban kerja keturunan.

• Adakah oom_kill atau hanya oom yang berubah? oom menyatakan had telah dicapai dan peruntukan hampir gagal;

oom_kill merekodkan proses yang sebenarnya telah dimatikan oleh pembunuh OOM. Buat semakan silang kiraan hierarki dengan memory.events.local.

• Adakah nod tersebut juga mengalami tekanan memori global? Periksa log kernel, MemAvailable, swap, PSI, peristiwa pengusiran (eviction events),

dan beban kerja jiran. cgroup OOM dan tekanan nod boleh berlaku dalam masa yang berdekatan.

• Adakah had 4 GiB tersebut milik bekas, Pod, atau cgroup induk? Had induk boleh mengekang anak

sebelum had anak itu sendiri dicapai. Telusuri hierarki dan periksa setiap sempadan yang berkuat kuasa.

• Apakah beban kerja yang berkorelasi dengan pertumbuhan? Konkurensi permintaan, kedalaman giliran (queue depth), saiz kelompok (batch size), kunci cache, sambungan,

saiz input, dan versi penggunaan (deployment) membantu memisahkan set kerja yang surut daripada memori tertahan yang membesar mengikut masa.

• Berapa banyak proses yang berkongsi cgroup tersebut? Sidecar, worker, dan proses anak yang dijana semuanya menyumbang kepada caj memori.

Membuat pemprofilan pada proses utama sahaja boleh terlepas pemilik sebenar pertumbuhan tersebut.

• Apakah keperluan pemulihan dan integriti data? Mematikan satu ahli daripada beban kerja berbilang proses boleh meninggalkan

keadaan yang tidak konsisten. Mulakan semula, pelupusan beban (load shedding), pengalihan trafik, dan penamatan kumpulan bergantung pada keidempotenan (idempotency) dan RTO.

Rangka Kerja Jawapan 30 Saat

"Saya akan menganggap 137 sebagai petunjuk SIGKILL, bukannya kesimpulan OOM yang muktamad. Saya akan menyelaraskan ID bekas dan masa kegagalan, kemudian menyemak sebab OOMKilled daripada runtime, memory.events.local bagi cgroup sasaran, memory.current, memory.max, dan log kernel. Nod mempunyai memori bebas, tetapi cgroup telah mencapai hadnya dan oom_kill meningkat, jadi bukti menjurus kepada cgroup OOM. Saya akan melupuskan atau mengalihkan beban dan memelihara bukti, hanya menaikkan had buat sementara waktu selepas memeriksa ruang lega (headroom) nod. Kemudian saya akan memecahkan memori tanpa nama (anonymous), fail, memori kongsi, dan kernel dengan memory.stat, serta mengkorelasikan profil per-proses dengan metrik beban kerja untuk membezakan sama ada ia kebocoran, cache tanpa batas, lonjakan konkurensi, atau had yang terlalu kecil. Selepas pembaikan, saya akan menjalankan ujian lonjakan representatif, ujian rendaman yang panjang, dan ujian had terkawal serta menyediakan amaran bagi memory.high, tekanan, lonjakan, dan peristiwa OOM."

Huraian Mendalam Langkah demi Langkah

Langkah pertama: tukarkan penamatan kepada satu garis masa tunggal.

Rekodkan ID bekas, PID, masa mula dan masa keluar, versi yang digunakan, kiraan mula semula, dan laluan cgroup. Kod keluar 137 biasanya sepadan dengan SIGKILL dalam shell dan status bekas, tetapi ia tidak membuktikan OOM: kill -9, masa tamat platform, atau ejen nod boleh menghasilkan keputusan yang sama. Korelasikan reason: OOMKilled, perbezaan (delta) dalam peristiwa cgroup, dan mesej kernel sekitar saat yang sama.

Utamakan memory.events.local supaya pembilang hierarki induk tidak bercampur dengan peristiwa keturunan. Jika oom_kill berubah daripada 7 kepada 8 pada penamatan ini, memory.current menghampiri 4 GiB, dan log kernel melaporkan OOM cgroup memori, itu merupakan rantaian cgroup OOM yang koheren. Jika hanya terdapat 137, tanpa perubahan pembilang atau sebab runtime OOM, siasat isyarat manual, masa tamat semakan kesihatan, systemd-oomd, pengusiran (eviction), dan penamatan runtime sebagai gantinya.

Langkah kedua: kenal pasti domain sumber OOM.

memory.max mengekang memori yang diperakaunkan untuk cgroup dan keturunannya. Apabila ia dicapai dan proses reclaim terus tidak dapat memenuhi peruntukan, kernel boleh memilih mangsa hanya daripada cgroup tersebut. Oleh itu, 18 GiB MemAvailable hos tidak melindungi bekas tersebut. Telusuri ke atas melalui cgroup induk untuk mencari sempadan yang mana memory.max dan pembilang peristiwanya telah dicapai.

OOM global mempunyai bukti yang berbeza: memori nod dan swap menghampiri tahap kehabisan, PSI memori meningkat, log kernel merangkumi keadaan memori global dan mangsa, serta beban kerja lain turut terjejas. Di bawah tekanan nod, platform mungkin mengusir Pod terlebih dahulu. Memulihkan cgroup OOM menumpukan pada penggunaan beban kerja dan hadnya; OOM global pula memerlukan pembetulan lebihan komitmen (overcommit) nod, permintaan (requests) dan rizab (reservations), daemon sistem, serta penempatan beban kerja.

Langkah ketiga: terangkan ke mana 4 GiB itu pergi.

Mulakan dengan memory.current dan memory.peak, kemudian pecahkan caj tersebut dengan memory.stat. Di sini, anon meningkat daripada 1.2 GiB kepada 3.5 GiB dalam tempoh enam jam manakala file adalah sekitar 280 MiB. Ini memberikan keutamaan kepada heap, pemetaan tanpa nama (anonymous mappings), dan proses yang memilikinya, tetapi ia masih belum membuktikan kebocoran memori. Dokumentasi kernel menyatakan perakaunan cgroup turut merangkumi page cache, tmpfs dan memori kongsi, struktur kernel, serta penimbal soket; cgroup induk merangkumi cgroup anak.

Letakkan jumlah keseluruhan bersebelahan RSS setiap proses, PSS, pemetaan tanpa nama, kiraan proses dan bebenang (threads), metrik heap runtime, dan ukuran perniagaan pada satu garis masa. Jika objek aktif (live objects) dan heap aplikasi berkembang bersama, siasat rujukan yang tertahan atau cache tanpa batas. Jika heap stabil tetapi RSS kekal tinggi, periksa pemecahan pengagih (allocator fragmentation), pustaka natif, atau mmap. Pertumbuhan dalam file, shmem, sock, atau slab sebaliknya menjurus kepada fail tmpfs, cache, tunggakan sambungan, atau objek kernel.

VSZ ialah ruang alamat maya, bukan penempatan fizikal atau caj cgroup. Satu snapshot tunggal juga tidak mencukupi. Satu beban kerja kelompok yang sihat mungkin memuncak dan menurun selepas proses reclaim; kebocoran secara amnya meningkatkan garis dasar (baseline) merentasi kitaran berulang pada beban yang setanding. Bandingkan kecerunan dan keadaan mantap selepas pelepasan pada daya pemprosesan (throughput) yang sama.

Langkah keempat: jadikan setiap hipotesis boleh dipalsukan (falsifiable).

Kekalkan senarai calon hipotesis yang pendek dan nyatakan ramalan untuk setiap satu. Dengan lonjakan konkurensi, memori sepatutnya menjejaki permintaan yang sedang diproses (in-flight) dan surut apabila ia selesai. Dengan cache tanpa batas, bilangan entri dan anon meningkat bersama dan menjadi stabil apabila kapasiti dihadkan. Dengan tunggakan pengguna (consumer backlog), kedalaman giliran, objek kelompok, dan memori bergerak bersama. Dengan had yang terlalu kecil, set kerja representatif yang stabil berulang kali menghampiri sempadan tanpa kecerunan menaik jangka panjang.

Gunakan profil heap, profil peruntukan, atau histogram objek yang sesuai untuk masa jalanan, tetapi ambil kira overhed pengumpulan. Mulakan dengan metrik pengeluaran berisiko rendah atau replika yang dialihkan trafiknya; sebelum mengambil dump, sahkan ruang cakera, privasi, dan kos jeda (pause cost). Ubah satu faktor pada satu masa dalam perbandingan versi atau memainkan semula trafik (traffic replay). Menaikkan had, menyahdayakan cache, dan menurunkan konkurensi secara serentak akan menyembunyikan punca sebenar.

Langkah kelima: asingkan pembendungan daripada pembaikan yang berkekalan.

Lindungi pengguna dan nod terlebih dahulu: hadkan konkurensi ke dalam tika, jedakan kelompok yang menggunakan memori tinggi, alihkan trafik, atau buat pengunduran (roll back) kepada versi yang diketahui selamat. Jika main semula selamat dan keadaan berbilang proses kekal konsisten, pemulaan semula dapat melepaskan memori dengan cepat. Jika mematikan satu worker merosakkan keadaan kongsi, pertimbangkan untuk menamatkan beban kerja tersebut sebagai satu unit. Dalam cgroup v2, memory.oom.group=1 meminta pembunuh OOM untuk menganggap cgroup sebagai tidak boleh dibahagikan, tetapi semantik pemulihannya mesti diuji.

Naikkan memory.max buat sementara waktu hanya selepas mengukur ruang lega nod, perlindungan untuk jiran, dan jangkaan lonjakan. Sertakan tarikh luput, pemantauan, dan ambang pengunduran. Bagi pertumbuhan yang berterusan, had yang lebih besar hanya melambatkan OOM seterusnya. Pembaikan yang berkekalan boleh mengehadkan cache, melepaskan rujukan, mengehadkan kelompok dan konkurensi, membaiki kitaran hayat proses anak, atau mengubah saiz permintaan dan had daripada set kerja yang diukur serta peruntukan lonjakan (burst allowance).

Jangan "menyelesaikan" insiden tersebut dengan menetapkan oom_score_adj=-1000 perkhidmatan biasa. Ini mengecualikannya daripada pemilihan OOM dan mungkin memaksa kernel mematikan proses yang lebih penting atau lebih banyak; simpankan ia untuk tugas sistem yang penting selepas semakan dasar kegagalan menyeluruh. Swap juga mengubah tingkah laku reclaim dan kependaman (latency). Ia mungkin menyerap lonjakan singkat tetapi tidak membaiki pertumbuhan tanpa batas.

Langkah keenam: sahkan kapasiti dan wujudkan isyarat yang lebih awal.

Mainkan semula trafik representatif di bawah perakaunan dan had cgroup yang setara dengan pengeluaran. Rangkumi beban stabil, lonjakan, input besar, pemulihan tunggakan, dan tingkah laku berbilang proses. Gunakan ujian beban pendek untuk lonjakan, ujian rendaman panjang untuk kecerunan pertumbuhan dan garis dasar selepas pelepasan, serta had bawah terkawal untuk menguji amaran, penamatan, pemulaan semula, dan integriti data. Kejayaan bermaksud terdapat ruang lega yang ditetapkan pada throughput dan kependaman sasaran, memory.current yang surut, tiada oom_kill baharu, dan tiada pemburukan tekanan nod atau jiran.

Gunakan memory.high sebagai sempadan kawalan sebelum had ketat: melebihi had ini akan mendikit (throttle) cgroup dan memacu direct reclaim tanpa mencetuskan OOM secara langsung, memberikan masa untuk memaklumkan atau mengautomasikan pembendungan. Pantau nisbah memory.current/memory.max, memory.peak, peristiwa high, max, oom, dan oom_kill, PSI memori, kadar mula semula, heap aplikasi, dan kecerunan pertumbuhan. Had sepatutnya diperoleh daripada pengukuran lonjakan dan rendaman serta disemak apabila versi, konkurensi, atau taburan input berubah.

Contoh Jawapan Berkualiti Tinggi

"Mula-mula saya akan membuktikan sama ada OOM yang menyebabkan penamatan ini. Kod keluar 137 menyatakan proses menerima SIGKILL; penamatan manual dan masa tamat juga boleh berbuat demikian. Saya akan menyelaraskan ID bekas, masa keluar, dan laluan cgroup, kemudian memeriksa sebab OOMKilled runtime, perbezaan dalam memory.events.local, dan log kernel. Jika oom_kill meningkat pada penamatan ini, memory.current mencecah 4 GiB, dan log mengenal pasti cgroup memori, ini menyokong punca cgroup OOM.

Ini juga menerangkan mengapa nod boleh mempunyai 18 GiB memori tersedia. memory.max ialah sempadan ketat cgroup, dan kegagalan reclaim memaksa kernel membuat pemilihan dalam domain sumber tersebut tanpa perlu menghabiskan hos terlebih dahulu. Saya tetap akan memeriksa cgroup induk, PSI nod, swap, dan log OOM global untuk mengecualikan tekanan nod yang berlaku serentak atau pengusiran platform.

Untuk pembendungan, saya akan melupuskan atau mengalihkan trafik berat memori dan mengekalkan metrik sebelum kegagalan serta profil beroverhed rendah. Jika pemulaan semula selamat, saya akan mengembalikan versi yang diketahui stabil. Saya akan menaikkan had buat sementara waktu hanya selepas memeriksa ruang lega nod dan beban kerja jiran, dengan syarat luput dan pengunduran. Menambah memori bukanlah pembaikan yang berkekalan.

Untuk diagnosis, saya akan memadankan jumlah cgroup menggunakan memory.current, memory.peak, dan memory.stat, kemudian memeriksa RSS, PSS, pemetaan tanpa nama, dan heap runtime bagi setiap proses. Di sini anon meningkat daripada 1.2 GiB kepada 3.5 GiB manakala memori fail sekitar 280 MiB, jadi saya akan mengutamakan heap, mmap tanpa nama, proses anak, dan pengagih (allocator), tetapi membuktikan pemiliknya melalui pemprofilan. Saya akan mengkorelasikan memori dengan konkurensi, kedalaman giliran, entri cache, saiz kelompok, dan versi. Garis dasar yang meningkat pada beban yang setanding mencadangkan kebocoran; set kerja stabil yang surut mencadangkan lonjakan biasa atau had yang rendah.

Selepas pembaikan, saya akan menjalankan beban lonjakan dan ujian rendaman panjang di bawah had cgroup yang sama, mengesahkan bahawa memori surut, pembilang peristiwa berhenti meningkat, serta kependaman dan throughput menepati sasaran. Saya kemudiannya akan menetapkan memory.high dan amaran sebelum mencapai sempadan ketat, memantau lonjakan, tekanan, peristiwa OOM, dan kecerunan pertumbuhan, serta mensaizkan konkurensi, cache, dan kapasiti daripada set kerja yang diukur. Bagi perkhidmatan berbilang proses, saya juga akan menguji integriti data selepas penamatan separa sebelum memutuskan sama ada OOM perlu menamatkan keseluruhan kumpulan."

Kesilapan Biasa

• Mengisytiharkan OOM hanya daripada kod 137 → SIGKILL boleh datang daripada pengendali atau pengawal masa tamat → **Korelasikan

sebab runtime, peristiwa cgroup, dan log kernel.**

• Menolak OOM semata-mata kerana hos mempunyai memori bebas → cgroup boleh mencapai had ketatnya semasa nod masih mempunyai ruang lega →

Kenal pasti domain sumber terlebih dahulu.

• Hanya melihat pada RSS satu proses → Proses keturunan, fail, memori kongsi, dan caj kernel juga dikira → **Padankan

jumlah keseluruhan dan pecahkan memory.stat.**

• Menganggap VSZ sebagai penggunaan fizikal → Saiz ruang alamat bukan penempatan fizikal atau memori yang diperakaunkan → **Semak silang RSS/PSS,

pemetaan, dan metrik cgroup.**

• Menyatakan sebarang pertumbuhan anon sebagai kebocoran → Set kerja normal atau lonjakan kelompok juga boleh membesar → **Bandingkan kecerunan dan

garis dasar selepas pelepasan pada beban yang setara.**

• Menggandakan had serta-merta → Ini boleh melambatkan kebocoran dan memakan margin keselamatan nod → **Wajibkan bukti

kapasiti, tarikh luput, dan ambang pengunduran.**

• Menjadikan aplikasi kebal terhadap OOM → Kerosakan boleh beralih kepada tugasan lain atau nod → **Tukar oom_score_adj

hanya sebagai sebahagian daripada dasar kegagalan menyeluruh.**

• Hanya menjalankan ujian beban selama satu minit → Ujian yang singkat terlepas kebocoran perlahan dan pemecahan memori → **Jalankan kedua-dua ujian lonjakan dan

ujian rendaman yang panjang.**

• Hanya memberi amaran pada had ketat → Bertindak balas pada memory.max biasanya sudah terlambat → **Gunakan memory.high, PSI, dan

kecerunan pertumbuhan untuk tindakan yang lebih awal.**

• Menganggap pemulihan selesai selepas satu worker mati → Keadaan kongsi berbilang proses mungkin tidak konsisten → **Uji penamatan

kumpulan, pemulaan semula, dan semantik pemulihan data.**

Soalan Susulan dan Cara Menjawab

Susulan 1: Kod keluar 137 wujud, tetapi oom_kill tidak meningkat. Apakah yang anda periksa seterusnya?

Mula-mula sahkan laluan cgroup dan masa peristiwa, serta baca memory.events.local supaya anda tidak membandingkan cgroup induk atau tika baharu. Jika bukti OOM masih tiada, periksa sebab penamatan runtime, masa tamat penggunaan atau semakan kesihatan, jejak audit pengendali, systemd-oomd, pengusiran nod, dan log kernel. Kod keluar 137 memperincikan hasil kepada SIGKILL; ia tidak mengenal pasti penghantarnya.

Susulan 2: Bagaimanakah anda membezakan kebocoran memori daripada had yang terlalu kecil?

Bandingkan kitaran berulang pada throughput, input, dan konkurensi yang serupa. Kebocoran secara amnya meningkatkan garis dasar atau bilangan objek aktif dan tidak surut pada beban rendah. Had yang terlalu kecil lebih cenderung untuk gagal pada lonjakan yang boleh diulang dan kembali kepada set kerja yang stabil selepas itu. Sahkan dengan profil heap atau profil peruntukan, entri cache, proses anak, saiz kelompok, dan memory.stat; jangan bergantung pada satu graf sahaja. Kedua-dua keadaan boleh wujud serentak.

Susulan 3: Bilakah wajar untuk meningkatkan memory.max?

Tingkatkannya apabila ujian lonjakan representatif dan ujian rendaman menunjukkan tingkah laku yang sihat di mana set kerja yang diperlukan melebihi had semasa, manakala kapasiti nod, rizab, dan perlindungan jiran masih meninggalkan ruang lega. Peningkatan semasa insiden memerlukan tarikh luput, pemantauan, dan ambang pengunduran. Jika penggunaan meningkat tanpa had, had yang lebih tinggi hanyalah pembendungan sementara; anda juga perlu melupuskan beban dan membaiki punca pertumbuhan.

Susulan 4: Bagaimanakah memory.high dan memory.max patut bekerjasama?

memory.high ialah sempadan pendikit (throttling) dan direct-reclaim; melepasinya tidak mencetuskan pembunuh OOM secara langsung, jadi ia boleh menyediakan ruang masa untuk pemerhatian dan automasi. memory.max ialah sempadan pengasingan muktamad dan boleh mencetuskan cgroup OOM jika reclaim gagal. Tetapkan kedua-duanya berdasarkan set kerja yang diukur, lonjakan, toleransi kependaman, dan margin nod, serta berikan amaran secara berasingan bagi peristiwa high, max, oom, dan oom_kill.

Susulan 5: Mengapakah perkhidmatan berbilang proses mungkin menggunakan memory.oom.group?

Jika mematikan satu worker meninggalkan keadaan kongsi yang tidak konsisten, kunci terperangkap (locks), atau transaksi yang belum selesai, menganggap cgroup sebagai beban kerja yang tidak boleh dibahagikan dapat menjadikan kegagalan dan pemulihan lebih berketentuan (deterministic). Sebelum mendayakannya, uji masa pemulaan semula seluruh kumpulan, keidempotenan tugas, dan pemulihan data. Tugas dengan oom_score_adj=-1000 adalah pengecualian, jadi sahkan juga bahawa tiada baki beban kerja separa yang tertinggal.