Mitos Server Tanpa Swap: Ketika Apa yang Disebut “Best Practice” Justru Membunuh Sistem

Ada satu kalimat yang beredar di komunitas DevOps seperti dogma yang tidak perlu dipertanyakan lagi: “best practice server itu tidak boleh ada swap.” Kalimat ini diucapkan dengan keyakinan penuh, disetujui dengan anggukan, dan kemudian diimplementasikan di server production tanpa banyak pertanyaan. Masalahnya: dalam banyak kasus, pemahaman ini tidak hanya keliru — ia aktif berbahaya. Server yang dikonfigurasi tanpa swap berdasarkan dogma ini menjadi server yang lebih mudah mati, lebih brutal cara kematiannya, dan lebih sulit di-debug setelah kematian itu terjadi. Artikel ini membedah dari mana mitos ini berasal, mengapa ia salah untuk sebagian besar kasus, bagaimana OOM Killer bekerja, dan apa yang sebenarnya harus dilakukan.

Dari Mana Mitos Ini Berasal

Memahami asal-usul sebuah miskonsepsi adalah langkah pertama untuk membongkarnya dengan benar. Mitos “server tanpa swap” tidak lahir dari kekosongan — ia lahir dari konteks yang valid, lalu digeneralisasi ke situasi yang tidak relevan.

Konteks yang Melahirkan Klaim Ini

Ada tiga sumber utama dari mana narasi ini menyebar.

Pertama: sistem yang butuh latensi sangat rendah. Swap memang berbahaya untuk sistem trading frekuensi tinggi, real-time audio processing, atau aplikasi lain yang intoleran terhadap jitter latensi. Ketika proses diswap out ke disk lalu dipanggil kembali, ada delay yang bisa mencapai ratusan milidetik hingga beberapa detik — tidak dapat diterima untuk use case seperti ini. Di konteks ini, menghindari swap adalah keputusan yang tepat dan beralasan.

Kedua: pengalaman buruk dengan konfigurasi swap default Linux. vm.swappiness default Linux adalah 60, yang berarti kernel cukup agresif memindahkan halaman memori ke swap bahkan ketika RAM masih tersedia cukup. Ini menciptakan pengalaman server yang terasa “hang” — responsif tapi terasa berat — karena konteks switching antara RAM dan disk yang terlalu sering. Engineer yang mengalami ini cenderung menyimpulkan bahwa swaplah masalahnya, padahal masalahnya ada di konfigurasi swappiness yang tidak disesuaikan.

Ketiga: generalisasi narasi dari ekosistem container dan cloud. Kubernetes memang secara resmi tidak merekomendasikan swap karena mengganggu kalkulasi resource allocation-nya. Beberapa cloud provider juga tidak menyediakan swap secara default. Dari dua fakta ini, banyak engineer menyimpulkan bahwa “tidak ada swap” adalah standar industri — padahal konteksnya sangat spesifik.

flowchart TD
    A[Pengalaman dengan swap\nyang dikonfigurasi buruk] --> D[Generalisasi:\n'Swap itu buruk']
    B[Narasi dari ekosistem\nKubernetes dan container] --> D
    C[Sistem latency-sensitive\nyang memang tidak butuh swap] --> D
    D --> E[Dogma:\n'Server tidak boleh ada swap']
    E --> F[Server production\ntanpa swap sama sekali]
    F --> G{Memory habis?}
    G -- Ya --> H[OOM Killer aktif\nProses di-SIGKILL]
    G -- Tidak --> I[Aman]
    H --> J[Downtime tanpa\nkesempatan mitigasi]

    style H fill:#ffebee,stroke:#e53935
    style J fill:#ffebee,stroke:#e53935
    style E fill:#fff3e0,stroke:#fb8c00

Yang hilang dari generalisasi ini adalah pemahaman tentang apa yang sebenarnya dilakukan swap — dan apa yang terjadi ketika swap tidak ada di situasi yang tepat.

Cara Kernel Linux Mengelola Memori

Sebelum membahas swap lebih jauh, perlu ada model mental yang tepat tentang cara Linux mengelola memori. Ini bukan sekadar teori — pemahaman ini langsung menentukan mengapa swap bisa menyelamatkan sistem atau menghancurkannya.

Hirarki Memori di Linux

Linux mengelola memori dalam beberapa lapisan. Ketika sebuah proses membutuhkan halaman memori, kernel mencari dari lapisan yang paling cepat ke yang paling lambat.

flowchart TD
    P[Proses membutuhkan halaman memori]
    P --> A{Ada di CPU cache?}
    A -- Ya --> Z1[Akses langsung\nnanoseconds]
    A -- Tidak --> B{Ada di RAM?}
    B -- Ya --> Z2[Ambil dari RAM\nmikrodetik]
    B -- Tidak --> C{Ada di page cache\nfile yang baru dibaca?}
    C -- Ya --> Z3[Ambil dari page cache\nmikrodetik]
    C -- Tidak --> D{Ada swap?}
    D -- Ya --> Z4[Swap in dari disk\nmilidetik - detik]
    D -- Tidak --> E[Tidak ada opsi]
    E --> F[OOM Killer aktif\nProses di-SIGKILL]

    style F fill:#ffebee,stroke:#e53935
    style Z4 fill:#fff3e0,stroke:#fb8c00
    style Z1 fill:#e8f5e9,stroke:#43a047
    style Z2 fill:#e8f5e9,stroke:#43a047

Swap ada di lapisan terakhir sebelum kegagalan total. Ia lambat — tidak ada yang memperdebatkan itu. Tapi “lambat tapi hidup” hampir selalu lebih baik dari “cepat tapi mati” di konteks server production.

Apa yang Diputuskan Kernel Ketika RAM Penuh

Ketika RAM mendekati batas, kernel punya beberapa strategi yang ia coba secara berurutan:

1. Reclaim page cache — memori yang digunakan untuk menyimpan file yang baru dibaca bisa dibebaskan karena bisa dibaca ulang dari disk
2. Reclaim anonymous pages ke swap — halaman yang tidak punya backing file (heap aplikasi, stack) dipindahkan ke swap
3. OOM Killer — jika tidak ada swap dan page cache sudah habis, kernel tidak punya pilihan lain

Swap adalah satu-satunya opsi yang memungkinkan kernel menyelamatkan anonymous pages (yang isinya tidak bisa dibuang begitu saja karena tidak ada file di disk yang menyimpannya) tanpa harus membunuh prosesnya.

“Anonymous pages” adalah halaman memori yang dialokasikan oleh aplikasi untuk data runtime — variabel, heap, stack. Berbeda dengan “file-backed pages” yang isinya bisa dikembalikan dengan membaca file dari disk. Anonymous pages hanya bisa diselamatkan lewat swap — tidak ada cara lain.

OOM Killer: Memahami Mekanisme yang Sering Disalahpahami

OOM Killer (Out-of-Memory Killer) adalah mekanisme kernel Linux yang diaktifkan ketika sistem kehabisan memori dan tidak ada cara lain untuk membebaskannya. Ia memilih satu atau lebih proses untuk dibunuh menggunakan SIGKILL — sinyal yang tidak bisa ditangkap atau diabaikan oleh aplikasi.

Cara OOM Killer Memilih Korban

Kernel memberikan skor “badness” kepada setiap proses berdasarkan beberapa faktor:

flowchart TD
    OOM["OOM Killer aktif"] --> SCAN["Scan semua proses"]
    SCAN --> SCORE["Hitung oom_score tiap proses"]

    SCORE --> F1["+ Penggunaan memori<br/>lebih banyak pakai = skor lebih tinggi"]
    SCORE --> F2["+ Memori child processes"]
    SCORE --> F3["- Proses dengan runtime panjang<br/>lebih lama = skor lebih rendah"]
    SCORE --> F4["- Proses kernel dan daemon penting"]
    SCORE --> ADJ["oom_score_adj<br/>bisa diset manual oleh aplikasi"]

    F1 --> SELECT["Pilih proses dengan<br/>skor tertinggi"]
    F2 --> SELECT
    F3 --> SELECT
    F4 --> SELECT
    ADJ --> SELECT

    SELECT --> KILL["SIGKILL - tidak bisa ditangkap"]
    KILL --> LOG["Tulis ke kernel log<br/>Out of memory: Kill process X"]

    style KILL fill:#ffebee,stroke:#e53935
    style OOM fill:#ffebee,stroke:#e53935

Proses yang paling banyak memakan memori mendapat skor tertinggi dan paling mungkin dibunuh. Tapi ini bukan jaminan — kernel punya heuristic yang kompleks, dan hasilnya bisa mengejutkan. Ada kasus di mana OOM Killer membunuh proses yang “salah” dari perspektif operator: bukan aplikasi yang bocor memori, tapi database atau web server yang kebetulan punya memory footprint besar.

Karakteristik SIGKILL yang Membuat OOM Killer Brutal

Berbeda dengan SIGTERM yang bisa ditangkap aplikasi untuk melakukan graceful shutdown, SIGKILL tidak bisa ditangkap, diblokir, atau diabaikan oleh proses. Kernel langsung menghentikan proses tanpa memberikan kesempatan untuk:

• Menutup koneksi database dengan bersih
• Menyelesaikan transaksi yang sedang berjalan
• Menulis buffer ke disk
• Mengirim sinyal error ke client yang sedang terhubung
• Membersihkan resource yang sudah dialokasikan

Hasilnya bisa lebih buruk dari sekadar proses yang mati: transaksi database yang setengah jalan bisa meninggalkan data yang inkonsisten, koneksi yang tidak ditutup dengan bersih bisa meninggalkan connection pool yang exhausted di sisi client, dan file yang sedang ditulis bisa korup.

Membaca Log OOM Killer

Mengenali log OOM Killer adalah skill penting untuk setiap engineer yang mengelola server Linux:

# Cari log OOM di sistem log
sudo dmesg | grep -i "out of memory"
sudo journalctl -k | grep -i "oom"

# Output yang akan kamu lihat:
# kernel: Out of memory: Kill process 12345 (php-fpm) score 892 or sacrifice child
# kernel: Killed process 12345 (php-fpm) total-vm:3145728kB, anon-rss:2097152kB
# kernel: oom_kill_process: OOM victim 12345 (php-fpm) is in memcg /system.slice

# Cek oom_score proses yang sedang berjalan (0-1000, semakin tinggi semakin berisiko)
cat /proc/$(pgrep php-fpm | head -1)/oom_score

# Set oom_score_adj untuk melindungi proses penting dari OOM Killer
# Nilai -1000 berarti proses tidak akan pernah dibunuh OOM Killer
echo -1000 > /proc/$(pgrep mysql | head -1)/oom_score_adj

Studi Kasus: PHP-FPM Tanpa Swap

Ini adalah skenario yang sangat umum dan sangat menggambarkan masalah yang terjadi ketika dogma “no swap” diterapkan tanpa pemahaman konteks.

Kondisi Awal

Server specs:
  RAM       : 4 GB
  Swap      : tidak ada (mengikuti "best practice")
  OS        : Ubuntu 22.04
  Workload  : PHP-FPM + Nginx + MySQL (semua di satu server)

PHP-FPM konfigurasi:
  pm                  = dynamic
  pm.max_children     = 20
  pm.memory_limit     = 256M per worker
  
Estimasi penggunaan memori maksimum:
  PHP-FPM  : 20 worker × 256MB = 5.12 GB  ← melebihi RAM!
  MySQL    : ~800 MB
  OS + lain: ~500 MB
  Total    : ~6.4 GB vs 4 GB RAM yang tersedia

Konfigurasi ini sudah bermasalah sejak awal — pm.max_children terlalu besar untuk RAM yang tersedia. Tapi ini adalah kesalahan yang sangat umum, dan swap bisa menjadi perbedaan antara “sistem melambat dan memberikan waktu untuk mitigasi” vs “sistem langsung mati”.

Kronologi Kegagalan Tanpa Swap

sequenceDiagram
    participant Traffic as Traffic Spike
    participant PHP as PHP-FPM Workers
    participant Kernel as Linux Kernel
    participant OOM as OOM Killer
    participant DB as MySQL

    Traffic->>PHP: Request meningkat 3x dari normal
    PHP->>Kernel: Spawn worker baru, minta memori
    Kernel-->>PHP: Alokasi OK (RAM masih tersedia)
    PHP->>Kernel: Spawn worker lagi, minta memori lagi
    Kernel-->>PHP: Alokasi OK (RAM mulai penuh)
    PHP->>Kernel: Request memori lagi
    Note over Kernel: RAM hampir habis\nTidak ada swap\nTidak ada page cache yang bisa direclaim
    Kernel->>OOM: Aktifkan OOM Killer
    OOM->>PHP: SIGKILL — proses PHP-FPM dengan skor tertinggi
    Note over PHP: Mati tanpa graceful shutdown\nKoneksi client terputus tiba-tiba
    OOM->>DB: SIGKILL — MySQL juga punya footprint besar
    Note over DB: Transaksi setengah jalan terhenti\nPotensi data corruption
    Note over Traffic: Semua request gagal\nDowntime total

Kronologi yang Berbeda Dengan Swap

sequenceDiagram
    participant Traffic as Traffic Spike
    participant PHP as PHP-FPM Workers
    participant Kernel as Linux Kernel
    participant Swap as Swap (2 GB)
    participant Ops as Operator

    Traffic->>PHP: Request meningkat 3x dari normal
    PHP->>Kernel: Spawn worker baru, minta memori
    Kernel-->>PHP: Alokasi OK dari RAM
    PHP->>Kernel: Request memori lagi, RAM hampir penuh
    Kernel->>Swap: Pindahkan anonymous pages yang tidak aktif ke swap
    Swap-->>Kernel: Space tersedia
    Kernel-->>PHP: Alokasi OK (dari kombinasi RAM + swap)
    Note over PHP: Sistem melambat tapi tidak mati
    Note over Ops: Alert monitoring terpicu:\n"Swap usage 40%, server lambat"
    Ops->>PHP: Investigasi — temukan konfigurasi worker terlalu banyak
    Ops->>PHP: Kurangi pm.max_children, restart PHP-FPM
    Note over PHP,Swap: Sistem kembali normal\nUser mengalami latency tinggi\ntapi tidak downtime total

Perbedaannya tidak bisa lebih jelas: tanpa swap, insiden berakhir dengan downtime total dan potensi data corruption. Dengan swap, insiden berakhir dengan degradasi performa yang masih bisa dimitigasi.

Perbedaan Performance Tuning vs System Survivability

Ini adalah konsep yang paling sering dikacaukan dalam diskusi tentang swap, dan memahaminya dengan benar adalah kunci untuk mengambil keputusan yang tepat.

Performance tuning adalah optimasi untuk kasus normal — bagaimana sistem berperilaku ketika beban ada di dalam parameter yang sudah direncanakan. Di sini, swap memang tidak boleh digunakan secara rutin karena akan menambah latensi.

System survivability adalah kemampuan sistem untuk tetap hidup dan bisa direcovery ketika ada kondisi di luar normal — traffic spike yang tidak terduga, memory leak yang belum terdeteksi, atau job batch yang memakan lebih banyak memori dari estimasi. Di sini, swap adalah safety net yang sangat berharga.

Swap yang dikonfigurasi dengan benar tidak memengaruhi performance tuning sama sekali — karena dengan swappiness yang rendah, swap hampir tidak pernah disentuh di kondisi normal. Tapi ketika kondisi abnormal terjadi, swap adalah perbedaan antara “sistem hidup tapi lambat” dan “sistem mati sepenuhnya”.

“Swap dipakai berarti ada yang salah” adalah pernyataan yang benar tapi berbahaya jika disalahartikan. Yang benar: swap dipakai secara rutin dan terus-menerus berarti ada yang salah — memory leak, konfigurasi yang buruk, atau undersizing. Tapi swap dipakai sesekali saat spike berarti ia bekerja persis seperti yang dirancang.

Konfigurasi Swap yang Benar untuk Server Production

Ini bukan tentang “apakah pakai swap”, tapi tentang “bagaimana mengkonfigurasi swap agar bekerja seperti airbag — ada tapi tidak pernah dipakai kecuali saat sangat dibutuhkan”.

Ukuran Swap yang Tepat

Swap bukan perpanjangan RAM — ia adalah buffer darurat. Ukurannya tidak perlu besar.

# Rekomendasi ukuran swap berdasarkan RAM:
# RAM ≤ 2 GB  → swap 1-2 GB
# RAM 2-8 GB  → swap 2 GB
# RAM 8-16 GB → swap 2-4 GB
# RAM > 16 GB → swap 4 GB cukup (tujuannya survivability, bukan ekstensi RAM)

# Membuat swap file (lebih fleksibel dari swap partition)
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Verifikasi
sudo swapon --show
free -h

# Jadikan permanen dengan menambahkan ke /etc/fstab
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Mengatur vm.swappiness

Ini adalah parameter paling penting. Nilai default 60 terlalu agresif untuk server production.

# Cek nilai swappiness saat ini
cat /proc/sys/vm/swappiness

# Set swappiness rendah — swap hanya digunakan saat benar-benar kritis
# Nilai 1: swap digunakan hanya ketika tidak ada pilihan lain
# Nilai 10: swap mulai digunakan ketika RAM tersisa ~10%
sudo sysctl vm.swappiness=1

# Jadikan permanen
echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# ANTI-PATTERN: menggunakan swappiness default atau nilai tinggi
# vm.swappiness=60  ← swap digunakan terlalu agresif, menyebabkan performa buruk
# vm.swappiness=100 ← swap dan RAM diperlakukan setara, sangat buruk untuk server

Mengatur vm.vfs_cache_pressure

Parameter ini mengontrol seberapa agresif kernel mereclaim memory yang digunakan untuk page cache (caching isi file dari disk). Nilai yang tepat membantu server menjaga performa I/O.

# Default adalah 100 — kernel agresif mereclaim page cache
# Nilai lebih rendah berarti kernel lebih mempertahankan page cache
# Untuk server web/PHP yang banyak membaca file: set ke 50
sudo sysctl vm.vfs_cache_pressure=50

# Jadikan permanen
echo 'vm.vfs_cache_pressure=50' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# Kombinasi yang direkomendasikan untuk server production umum:
# vm.swappiness=1
# vm.vfs_cache_pressure=50

Melindungi Proses Kritis dari OOM Killer

Ketika OOM Killer aktif, kamu perlu memastikan proses yang paling penting tidak menjadi korban pertama.

# Cek oom_score_adj proses (range: -1000 sampai 1000)
# -1000 = tidak akan pernah dibunuh OOM Killer
# 0 = default, menggunakan heuristic kernel
# 1000 = selalu menjadi kandidat pertama

# Lindungi proses database dari OOM Killer
# (jalankan saat startup, bukan saat sistem sudah kritis)
PID_MYSQL=$(pgrep -x mysqld | head -1)
echo -500 > /proc/${PID_MYSQL}/oom_score_adj

# Atau set melalui systemd service untuk proteksi permanen
# Di /etc/systemd/system/mysql.service.d/override.conf:
# [Service]
# OOMScoreAdjust=-500

# Buat proses PHP-FPM lebih mudah dibunuh daripada database
# (lebih baik PHP mati daripada data korup)
PID_PHP=$(pgrep -x php-fpm | head -1)
echo 200 > /proc/${PID_PHP}/oom_score_adj

Monitoring yang Harus Ada

Swap yang tidak dipantau tidak memberikan nilai tambah apa pun — kamu tidak akan tahu kapan sistem mendekati batas atau kapan ada yang salah.

# Script monitoring sederhana — tambahkan ke cron atau monitoring system
#!/bin/bash

# Cek penggunaan swap
SWAP_USED=$(free | awk '/^Swap:/{print $3}')
SWAP_TOTAL=$(free | awk '/^Swap:/{print $2}')

if [ "$SWAP_TOTAL" -gt 0 ]; then
    SWAP_PCT=$((SWAP_USED * 100 / SWAP_TOTAL))
    if [ "$SWAP_PCT" -gt 20 ]; then
        echo "WARNING: Swap usage ${SWAP_PCT}% — investigasi penggunaan memori"
        # Kirim alert ke Slack, PagerDuty, atau monitoring tool
    fi
fi

# Cek apakah OOM Killer aktif dalam 1 jam terakhir
OOM_COUNT=$(dmesg --since "1 hour ago" | grep -c "Out of memory" 2>/dev/null || \
            journalctl -k --since "1 hour ago" | grep -c "Out of memory" 2>/dev/null)

if [ "$OOM_COUNT" -gt 0 ]; then
    echo "CRITICAL: OOM Killer aktif ${OOM_COUNT}x dalam 1 jam terakhir"
    dmesg --since "1 hour ago" | grep "Out of memory"
fi

# Tampilkan top 5 proses berdasarkan oom_score
echo "=== Top 5 proses dengan oom_score tertinggi ==="
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
    score=$(cat /proc/$pid/oom_score 2>/dev/null || echo 0)
    comm=$(cat /proc/$pid/comm 2>/dev/null || echo "unknown")
    echo "$score $comm (PID: $pid)"
done | sort -rn | head -5

Mengapa Swap Juga Meningkatkan Efisiensi RAM

Ada satu manfaat swap yang sering diabaikan dalam diskusi ini: dengan adanya swap, kernel bisa lebih agresif dalam memindahkan halaman memori yang tidak aktif ke swap — membebaskan RAM fisik untuk digunakan sebagai page cache.

Page cache adalah salah satu optimasi performa terpenting di Linux. Ketika file yang sama dibaca berkali-kali (konfigurasi aplikasi, shared library, template), Linux menyimpannya di RAM sebagai cache. Akses berikutnya ke file tersebut menjadi sangat cepat karena tidak perlu baca disk.

flowchart LR
    subgraph TanpaSwap["Server Tanpa Swap"]
        RAM_A["RAM 4GB\n─────────────\nAplikasi aktif: 3.5GB\nPage cache: 0.5GB\n(terbatas karena takut OOM)"]
    end

    subgraph DenganSwap["Server Dengan Swap (2GB)"]
        RAM_B["RAM 4GB\n─────────────\nAplikasi aktif: 2.5GB\nPage cache: 1.5GB\n(lebih banyak karena\nhalaman pasif di-swap)"]
        SWAP_B["Swap 2GB\n─────────────\nHalaman pasif: 1GB\n(data heap yang\njarang diakses)"]
    end

    RAM_B <--> SWAP_B

    style TanpaSwap fill:#fff3e0,stroke:#fb8c00
    style DenganSwap fill:#e8f5e9,stroke:#43a047

Server dengan swap yang dikonfigurasi benar bisa memiliki page cache yang lebih besar — yang berarti I/O lebih cepat, bukan lebih lambat. Ini adalah keuntungan yang berlawanan intuisi tapi sangat nyata.

Kapan No Swap Memang Tepat

Artikel ini bukan argumen bahwa swap selalu harus ada. Ada situasi di mana tidak ada swap adalah keputusan yang benar dan beralasan.

NO SWAP TEPAT jika semua kondisi ini terpenuhi:
  ✓ Sistem latency-sensitive dengan SLA ketat (trading, real-time)
  ✓ Lebih baik proses mati daripada mengalami latensi tinggi
  ✓ Ada monitoring dan alerting yang sangat baik sebelum OOM
  ✓ Ada resource limit yang ketat di level aplikasi
  ✓ Ada strategi recovery yang sudah teruji (auto-restart, failover)
  ✓ Tim sudah paham dan siap dengan konsekuensi OOM Killer

NO SWAP ADALAH KEPUTUSAN BURUK jika:
  ✗ Alasannya hanya "itu best practice" tanpa memahami konteks
  ✗ Tidak ada monitoring memori yang memadai
  ✗ Workload berfluktuasi dan sulit diprediksi
  ✗ Tidak ada strategi recovery yang teruji
  ✗ Server menjalankan database atau sistem stateful
  ✗ Tim tidak paham cara membaca log OOM Killer

KHUSUS — Kubernetes cluster:
  ✗ Kubernetes secara resmi tidak mendukung swap di node
     karena mengganggu resource accounting dan scheduling
  ✓ Gunakan resource request/limit yang tepat per pod sebagai gantinya
  ✓ Gunakan Vertical Pod Autoscaler untuk penyesuaian otomatis

Ringkasan

• “Server tidak boleh ada swap” bukan best practice universal — ia adalah kesimpulan yang benar untuk konteks sempit (latency-sensitive systems) yang digeneralisasi secara keliru ke semua situasi.
• Swap dirancang untuk survivability, bukan performa — ia bukan cara untuk memperluas RAM, tapi airbag yang menyelamatkan sistem saat kondisi abnormal terjadi.
• OOM Killer lebih brutal dari swap — SIGKILL tidak bisa ditangkap aplikasi, bisa membunuh proses yang salah, dan bisa meninggalkan data dalam kondisi inkonsisten. Swap memberikan waktu untuk observasi dan mitigasi.
• vm.swappiness=1 membuat swap hampir tidak pernah digunakan — dengan nilai ini, swap hanya aktif saat kondisi benar-benar kritis, tidak memengaruhi performa di kondisi normal.
• Swap yang selalu aktif adalah alarm, bukan keberhasilan konfigurasi — jika swap usage terus naik, itu sinyal ada memory leak atau konfigurasi yang salah, bukan bukti bahwa swap bermanfaat.
• Swap bisa meningkatkan efisiensi page cache — dengan memindahkan halaman pasif ke swap, RAM fisik bisa digunakan lebih banyak untuk page cache yang meningkatkan performa I/O.
• Proteksi oom_score_adj untuk proses kritis — proses database harus dilindungi agar tidak menjadi korban pertama OOM Killer; proses yang lebih bisa di-restart adalah kandidat yang lebih baik.
• Kubernetes adalah pengecualian yang valid — swap memang tidak cocok untuk Kubernetes node karena mengganggu resource accounting; gunakan resource limit per pod sebagai gantinya.