Monitoring memberi tahu kita ada yang melahap sumber daya — resource limits memastikan pelahap itu tidak bisa memakan semuanya. Bayangkan skrip kecil dengan kebocoran memori yang dibiarkan semalaman, atau fork bomb yang menduplikasi dirinya tanpa henti: tanpa batas, satu proses rusak sanggup menjatuhkan seluruh server. Linux menjawab dengan mekanisme batas per proses yang dibaca lewat ulimit, ditetapkan permanen lewat limits.conf, dan dikelola sistemik lewat cgroups. Chapter ini membedah ketiganya dari sisi praktik: membaca batas yang sedang berlaku, menurunkannya untuk melindungi sistem, dan memilih antara ulimit serta cgroups.

Mengapa Membatasi Proses #

Batas bukan hukuman untuk proses — batas adalah pagar pengaman agar kegagalan tetap lokal. Skrip backup yang bocor memori cukup dibatasi 2 GB: proses itu sendiri mati, server tetap hidup melayani yang lain. Analisis log yang membuka ratusan ribu file sekaligus cukup dibatasi jumlah file descriptor-nya. Fork bomb dihentikan oleh batas jumlah proses per user sebelum sempat memenuhi tabel proses kernel. Di semua kasus itu, biaya kegagalan mengecil dari “seluruh server tumbang” menjadi “satu proses mati dan meninggalkan jejak di log” — jejak yang cara membacanya sudah kita kuasai di Monitoring Logs .

Membaca Batas Aktif dengan ulimit #

ulimit bukan program di PATH — which ulimit tidak menemukan apa pun karena ulimit adalah builtin bash yang membaca dan menulis batas milik shell itu sendiri. Tanpa argumen, ulimit -a mencetak seluruh batas yang sedang berlaku. Berikut contoh tampilannya — potongan yang memuat batas paling sering dipakai:

text
core file size              (blocks, -c) 0
file size                   (blocks, -f) unlimited
open files                          (-n) 1024
stack size                  (kbytes, -s) 8192
max user processes                  (-u) 100000
virtual memory              (kbytes, -v) unlimited

Empat flag di antaranya paling sering dipakai untuk diagnosis:

FlagBatas apaKena kalau dilewati
-njumlah file descriptor (file terbuka)Too many open files
-ujumlah proses per userfork: retry: Resource temporarily unavailable
-vmemori virtualCannot allocate memory
-fukuran file tertulis maksimumproses dibunuh sinyal SIGXFSZ

Nilai batas aktif untuk satu angka bisa dibaca langsung tanpa ulimit -a:

bash
ulimit -n

Output yang Dihasilkan:

text
1024

Angka 1024 adalah nilai bawaan di sistem latihan ini; di server lain angkanya bisa berbeda. Versi file dari informasi yang sama adalah /proc/self/limits — kata self berarti “proses yang membaca file ini”, dan kolomnya mencantumkan soft limit serta hard limit berdampingan.

Soft Limit vs Hard Limit #

Setiap batas punya dua nilai: soft limit yang benar-benar diberlakukan sekarang, dan hard limit yang menjadi langit-langitnya. Proses biasa boleh menaikkan soft limit sendiri sampai ke hard limit, menurunkan soft limit kapan pun — tetapi menaikkan hard limit membutuhkan hak root. Flag -S dan -H memilih nilai mana yang ditetapkan; tanpa keduanya, bash menetapkan dua-duanya sekaligus.

Karena batas hanya berlaku untuk shell itu dan seluruh anak cucunya, pola penerapannya adalah meluncurkan proses lewat shell baru yang sudah disetel:

bash
bash -c 'ulimit -Hn 2048; ulimit -Sn 512; ulimit -Sn; ulimit -Hn; grep "open files" /proc/self/limits'

Output yang Dihasilkan:

text
512
2048
Max open files            512                  2048                 files     

Mari kita bedah baris-per-barisnya:

  1. Baris 1 (bash -c '...'): shell baru diluncurkan dengan satu rangkaian perintah — batas yang ditetapkan di dalamnya berlaku untuk shell itu dan semua proses yang dilahirkannya, sementara shell utama kita tidak tersentuh.
  2. Baris 1 (ulimit -Hn 2048): hard limit file descriptor diturunkan ke 2048 — menurunkan selalu boleh tanpa root.
  3. Baris 1 (ulimit -Sn 512): soft limit ditetapkan 512, masih ada ruang menaikkannya sendiri sampai 2048 bila perlu.
  4. ulimit -Sn; ulimit -Hn: kedua nilai dibaca kembali — 512 dan 2048, persis seperti yang ditetapkan.
  5. grep "open files" /proc/self/limits: baris yang sama dilihat dari sisi file — dua kolom angka itu adalah soft dan hard limit yang barusan disetel.

Batang tulang punggung ulimit sebenarnya syscall setrlimit — bedah resminya ada di bash(1) . Mencoba menaikkan hard limit sebagai user biasa berakhir dengan kegagalan yang tercatat rapi:

bash
bash -c 'ulimit -Hn 2048; ulimit -Hn 4096' 2>&1

Output yang Dihasilkan:

text
bash: ulimit: open files: cannot modify limit: Operation not permitted

Pesan Operation not permitted itulah bentuk lain dari kebutuhan akan root — persis seperti pesan Permission denied pada file. Di sistem latihan, pola yang tersedia hanyalah menurunkan; itu pun sudah cukup untuk melindungi sistem.

Batas Permanen di limits.conf #

ulimit hanya menetapkan batas untuk satu sesi peluncuran. Agar batas melekat pada user setiap kali login, tempatnya adalah /etc/security/limits.conf — file yang dibaca modul PAM pam_limits.so saat sesi login dibuka. File limits.conf di bundle materi ini berisi potongan konfigurasi yang wujud aslinya berada di /etc/security/:

bash
cat limits.conf

Output yang Dihasilkan:

text
# Potongan /etc/security/limits.conf pada server Debian.
# Format: <domain> <type> <item> <value>
# domain        type    item    value
budi            soft    nofile  2048
budi            hard    nofile  8192
@web            hard    nproc   1024
siti            hard    as      2097152
*               soft    core    0

Formatnya empat kolom yang dibaca begini:

  1. budi soft nofile 2048 dan budi hard nofile 8192: user budi mendapat soft limit 2048 file descriptor dengan langit-langit 8192 — pasangan soft/hard persis seperti demonstrasi di atas.
  2. @web hard nproc 1024: awalan @ berarti kelompok — semua anggota group web dibatasi maksimum 1024 proses.
  3. siti hard as 2097152: item as (address space) adalah versi limits.conf dari flag -v — memori virtual siti dibatasi 2.048.512 KB atau 2 GB.
  4. * soft core 0: tanda * berlaku untuk semua user; batas core nol mematikan penulisan core dump, file jejak kegagalan yang bisa berukuran raksasa.

Dokumentasi lengkap semua item dan pola domainnya ada di limits.conf(5) .

ulimit vs cgroups #

ulimit dan cgroups menyelesaikan masalah serupa dengan posisi berbeda:

Aspekulimitcgroups
Cakupansatu proses dan turunannya saat diluncurkangrup proses, bisa satu service utuh
Siapa memaksaproses menolak dirinya sendiri saat melewati bataskernel menimbang seluruh grup di scheduler
Saat berlakusejak peluncuran, tidak bisa ditarik ke proses yang sudah berjalanbisa dipasang ke proses yang sedang berjalan
Tempat aturshell (ulimit) atau limits.confhierarki /sys/fs/cgroup/, di Debian lewat systemd

Aturan praktisnya: ulimit tepat untuk meluncurkan satu batch job atau skrip yang tidak kita percaya; cgroups tepat untuk memagari service dan user karena pembatasannya sistemik dan bisa diubah sambil proses berjalan. Mekanisme cgroups modern dibedah tuntas di cgroups dan Resource Control , antarmuka resminya di dokumentasi kernel cgroup-v2 .

Dengan indikator, log, dan batas di tangan, satu hal terakhir yang membedakan administrator siap tempur dari yang panik: prosedur. Ketika keluhan “server lambat” datang, langkah apa lebih dulu, apa berikutnya — itu topik penutup section ini.