Tuning Kernel AlmaLinux untuk Production: Panduan Lengkap Parameter sysctl, Boot Options, dan Best Practice

Jadi gini, kemarin sore aku lagi santai di meja kerja, kopi masih anget di samping keyboard, niatnya cuma mau rapihin inbox biar nggak makin numpuk. Eh, masuklah satu ticket yang bikin aku angkat alis. Client bilang server mereka yang baru dimigrasi ke AlmaLinux itu berasa lemot. Padahal spek-nya nggak murahan — 16 core, 32GB RAM, NVMe. Aplikasi-nya juga nggak berat-berat amat, traffic-nya baru mulai jalan.

Aku cek pelan-pelan, secangkir kopi dulu baru ke terminal. CPU 15%, RAM 60% kosong, disk I/O bersih. Ini kenapa? Kok bisa lemot padahal resource lega semua? Terus aku buka dmesg, cek beberapa parameter kernel, dan ketahuan deh. Semuanya masih nilai default. Kernel-nya baru keluar dari pabrik, belum di-setting buat kerja di production. Wajar sih, tapi ya itu tadi, hasilnya berasa.

Kenapa Kernel Default Kurang Optimal untuk Production?

Nah, ini pertanyaan yang sering muncul. Kernel Linux itu dibuat buat nyamain semua kasus: desktop, laptop, server kecil, sampai mainframe. Makanya konfigurasi default-nya itu kompromi. Nilai default-nya aman, stabil, dan berlaku umum. Tapi pas beban mulai naik — ribuan koneksi TCP, query database yang beneran, file operation yang banyak — batas-batas default itu mulai kerasa. Nggak tiba-tiba crash, nggak langsung error gede. Justru yang bahaya itu yang halus-halus: response mulai nggak konsisten, koneksi sesekali reset, latency naik turun, kadang muncul backlog overflow di log.

Gejalanya juga suka bikin bingung karena resource keliatan aman. CPU normal, RAM lega, tapi aplikasi ngerasa lemot. Itu biasanya karena bukan CPU atau RAM yang jadi bottleneck, tapi parameter kernel yang nggak cocok sama pola trafik server kita. Contoh paling umum: net.core.somaxconn masih 4096 buat webserver yang kebanjiran koneksi, tcp_fin_timeout 60 detik bikin TIME_WAIT numpuk, swappiness 30 bikin swap kepake padahal RAM masih ada, dan Transparent Huge Pages yang on bikin latency spike di database.

Kalau ini dibiarkan, dampaknya bukan cuma lemot. Koneksi yang di-drop di level kernel itu bisa bikin client retry, request gagal di tengah jalan, checkout error, atau sync data putus. Buat bisnis yang bergantung sama uptime, ini serius. Dan yang paling nyebelin, masalah kayak gini sering nggak kelihatan di monitoring standar karena bukan error yang teriak-teriak. Makanya kita perlu tune kernel-nya biar dia nggak cuma “aman”, tapi juga cocok sama beban production kita. Ibaratnya kayak motong rumput di halaman rumah — kelihatan sepele, tapi kalau dibiarin panjang, tetangga mulai nengok.

Langkah 0: Backup dan Kenali Kondisi Awal

Sebelum ngutak-atik apa-apa, aturan pertama di dunia NOC: backup dulu, baru utak-atik. Config sysctl itu cuma satu file, tapi kalau salah set bisa bikin server nggak bisa akses jaringan. Jadi kita simpan dulu config aslinya, dan catat kondisi awal biar kalau nanti ada masalah, kita bisa compare. Ini kayak foto sebelum renovasi rumah — biar ada bukti bentuk aslinya.

Pertama, backup file sysctl. Kemudian cek beberapa parameter yang bakal kita ubah, biar tahu nilai default di versi AlmaLinux kalian. Output-nya bakal beda-beda tiap versi kernel, jadi jangan kaget kalau angkanya nggak sama persis kayak di artikel lain.

cp /etc/sysctl.conf /etc/sysctl.conf.bak-$(date +%F)

sysctl -a | grep -E 'net.core.somaxconn|net.ipv4.tcp_tw_reuse|vm.swappiness|fs.file-max'

cat /sys/kernel/mm/transparent_hugepage/enabled

lsblk -d -o NAME,ROTA,SCHED

Di AlmaLinux 8, nilai default net.core.somaxconn itu 4096. Di AlmaLinux 9 juga masih 4096. fs.file-max di AlmaLinux 9 biasanya udah lebih gede karena nilai defaultnya ngikutin ukuran RAM. Jadi catat dulu ya, biar kita tahu perubahan apa yang terjadi setelah tuning.

Oh ya, satu hal penting: semua perintah di artikel ini dijalankan sebagai root, atau via sudo kalau kamu punya user terbatas. Pastikan juga kamu punya akses ke konsol out-of-band (VNC, KVM, panel provider) sebagai fallback. Soalnya kalau salah set parameter jaringan, SSH bisa putus. Paham-paham aja, monggo catat dulu.

Langkah 1: Tuning Parameter Jaringan (Network Stack)

Ini bagian yang paling sering kerasa bedanya, apalagi buat server yang pegang webserver atau API. Masalah umumnya di backlog queue, TIME_WAIT, dan port range. Ketiganya kalau kekecilan, hasilnya koneksi ditolak atau lambat pas traffic naik. Kalau kamu pernah nemu server yang “kok kayaknya lambat” padahal resource oke, mulai curiga ke bagian ini.

Berikut parameter yang biasanya aku ubah buat production server. Perhatiin baik-baik, ini bukan nilai mati — sesuaikan sama kebutuhan, tapi nilai di bawah ini aman buat mayoritas kasus. Aku simpen di file terpisah biar gampang dicek dan dicabut kalau perlu.

cat > /etc/sysctl.d/60-tuning.conf <<'EOF'
# --- Network Stack ---
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65536
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
EOF

Penjelasan singkatnya gini:

• net.core.somaxconn: panjang antrian koneksi yang bisa diterima aplikasi lewat listen(). Nginx, Apache, dan aplikasi Node.js bakal kepake ini. Default 4096, buat production aku naikin ke 65535.
• net.core.netdev_max_backlog: antrian paket di network device sebelum diproses CPU. Kalau kekecilan, paket dibuang diam-diam pas traffic tinggi — ini bikin latency naik tapi nggak keliatan error.
• net.ipv4.tcp_max_syn_backlog: antrian koneksi SYN yang belum di-handshake. Pas SYN flood atau pas server kewalahan, ini yang nampung. Naikin biar nggak gampang nolak koneksi baru.
• net.ipv4.tcp_fin_timeout: berapa lama socket dalam status FIN_WAIT_2 sebelum ditutup. Default 60 detik, aku turunin ke 30 biar socket yang udah selesai nggak nggantung lama.
• net.ipv4.tcp_tw_reuse: ini yang sering salah paham. Dia ngizinin koneksi TIME_WAIT dipakai ulang buat koneksi baru ke alamat yang sama. Penting banget buat server yang banyak koneksi keluar (misal backend yang nyambung ke API).
• net.ipv4.ip_local_port_range: range port ephemeral buat koneksi keluar. Default cuma mulai 32768, aku buka dari 1024 biar server nggak kehabisan port pas banyak koneksi keluar.
• net.ipv4.tcp_slow_start_after_idle: kalau 0, congestion window nggak di-reset setiap idle. Buat koneksi yang frequent tapi pendek, ini ngebantu biar nggak mulai pelan-pelan terus.
• tcp_rmem/tcp_wmem dan rmem_max/wmem_max: buffer TCP. Naikin biar koneksi jarak jauh (misal antar datacenter) nggak jadi bottleneck karena buffer kekecilan.

Kalau server kamu murni webserver publik, kamu bisa skip tcp_tw_reuse kalau memang nggak banyak koneksi keluar. Tapi buat server yang jadi backend, aplikasi, atau tempat cron yang banyak request keluar, set ini pasti kerasa. Nggak percaya? Cek aja netstat sebelum dan sesudah, lihat berapa socket TIME_WAIT yang numpuk.

Langkah 2: Tuning Filesystem

Bagian ini jarang dilirik padahal kadang jadi penyebab kenapa aplikasi yang pakai file watcher (Laravel, Node.js, container) tiba-tiba error "too many open files" atau inotify limit. Dua hal yang biasanya aku sentuh: file descriptor dan inotify. Keduanya pendek, tapi efeknya gede banget pas kena.

cat >> /etc/sysctl.d/60-tuning.conf <<'EOF'
# --- Filesystem ---
fs.file-max = 2097152
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 1024
EOF

fs.file-max itu batas global file descriptor di sistem. Default di AlmaLinux biasanya ngikutin RAM, tapi untuk production aku tetep set eksplisit biar nggak kaget pas beban naik. Kalau sampai kena batas ini, aplikasi bakal nolak buka file, dan error-nya bikin pusing karena nggak jelas asal mulanya.

fs.inotify.max_user_watches itu batas jumlah file/folder yang bisa di-watch. Laravel dengan file watcher, supervisor yang monitoring log, atau Docker yang mount banyak direktori, gampang banget kena limit ini. Error khasnya "ENOSPC: System limit for number of file watchers reached". Kalau kamu pernah nemu error itu, ini fix-nya. Cukup satu baris, masalah beres.

Langkah 3: Tuning Memory Management

Sekarang masuk ke bagian yang suka bikin debat: swappiness dan dirty pages. Tenang, aku jelasin pelan-pelan, santai. Nggak usah panik lihat angka-angka ini, semuanya punya alasan dan nggak ada yang ekstrem.

cat >> /etc/sysctl.d/60-tuning.conf <<'EOF'
# --- Memory ---
vm.swappiness = 10
vm.dirty_ratio = 20
vm.dirty_background_ratio = 10
vm.vfs_cache_pressure = 50
vm.max_map_count = 262144
EOF

vm.swappiness — ini yang paling sering dibahas. Default 30 artinya kernel cukup agresif mindahin halaman anonim ke swap. Untuk server, terutama yang pegang database atau Redis, aku turunin ke 10 biar kernel lebih milih nahan data di RAM selama masih ada ruang. Tapi jangan 0, soalnya kadang masih perlu swap buat hal-hal kecil. Ada cerita orang set 0 dan malah kena OOM yang nggak perlu, jadi 10 itu titik aman.

vm.dirty_ratio dan vm.dirty_background_ratio ini ngatur seberapa banyak dirty pages yang boleh numpuk sebelum ditulis ke disk. dirty_background_ratio 10 artinya background flusher mulai jalan setelah 10% RAM kotor, dan dirty_ratio 20 itu batas maksimal sebelum proses yang nulis di-block. Dengan nilai ini, write-heavy workloads nggak bakal bikin disk ngebut di akhir-akhir, tapi tetap lancar.

vm.vfs_cache_pressure — default 100. Ini ngaruh ke seberapa agresif kernel nge-reclaim dentry dan inode cache. Aku turunin ke 50 biar cache filesystem lebih lama dipertahankan. Kerasa banget buat server yang banyak akses file kecil-kecil, misal hosting atau cPanel.

vm.max_map_count — buat yang jalanin Elasticsearch atau aplikasi yang buka banyak memory mapping, nilai default 65530 itu cepet abis. Naikin ke 262144. Error khasnya "max virtual memory areas vm.max_map_count [65530] is too low". Kalau nemu itu, sekarang tahu biang keroknya.

Satu catatan: kalau server kamu dedicated buat database, sebagian orang suka set vm.overcommit_memory = 2. Ini bikin kernel nolak alokasi memori yang melebihi limit, dan itu berguna buat Redis. Tapi efeknya bisa bikin aplikasi yang butuh memory besar malah gagal start. Jadi aku saranin start dari nilai aman dulu, baru eksperimen kalau kamu tahu persis aplikasi kamu butuhnya apa.

Langkah 4: Boot Options via GRUB

Nah, kalau sebelumnya kita ubah sysctl (berlaku runtime), sekarang kita ubah parameter kernel yang dibaca saat boot. Ini yang bikin beberapa perilaku sistem berubah dari awal. Hati-hati, salah set di sini dampaknya lebih gede, jadi baca baik-baik. Dua yang paling sering aku sentuh: Transparent Huge Pages (THP) dan mitigasi CPU.

Transparent Huge Pages ini fitur yang nge-lumpuin halaman memory 4KB jadi 2MB (huge pages) secara otomatis. Buat workload umum, ini bagus. Tapi buat database, THP bikin latency tidak stabil karena proses "defrag" yang jalan di background. Error khasnya "khugepaged: fault" yang keliatan di log dan ngehalang query. Buat server database, best practice-nya disable THP. Buat webserver biasa, biarin aja on, nggak masalah.

Mitigasi CPU (Meltdown, Spectre, dll) itu default-nya aktif, dan itu bikin CPU kehilangan beberapa persen performa. Buat production yang butuh performa mentah, sebagian orang set mitigations=off. TAPI ini trade-off keamanan, dan aku nggak akan rekomen buat server yang pegang data sensitif. Kalau mau aman, biarin aja default. Untuk ngubah boot options, edit file GRUB:

# Untuk disable THP di database server
sudo sed -i 's/^GRUB_CMDLINE_LINUX=.*/GRUB_CMDLINE_LINUX="rhgb quiet transparent_hugepage=never"/' /etc/default/grub

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

⚠️ PERINGATAN KEAMANAN: Backup Sebelum Melanjutkan

Sebelum rebuild grub.cfg, pastikan kamu sudah: 1) Backup file /etc/default/grub, 2) Catat config asli biar bisa rollback, 3) Pastikan akses ke konsol out-of-band masih jalan. Salah set parameter boot bisa bikin server nggak boot sama sekali, dan kalau kamu cuma andelin SSH, itu masalah besar.

cp /etc/default/grub /etc/default/grub.bak-$(date +%F)

Setelah itu baru jalankan grub2-mkconfig, lalu reboot di maintenance window. Jangan reboot pas jam sibuk, niscaya client marah. Hehe. Percaya deh, aku udah lihat kejadiannya dan nggak enak buat semua pihak.

Langkah 5: Pilih IO Scheduler yang Tepat

IO scheduler ini ngatur gimana request baca/tulis ke disk diantri. Ini lebih ke penyetelan per-disk, bukan sysctl. Default di kebanyakan distro sekarang udah otomatis milih, tapi kadang masih salah buat setup tertentu. Buat disk NVMe, scheduler yang paling pas itu none (alias noop) — karena NVMe nggak butuh penjadwalan rumit, controller-nya sendiri udah pinter. Buat SSD SATA, mq-deadline biasanya oke. Buat HDD spinning, mq-deadline juga aman. Kalau kamu masih pake HDD buat production... yah, semoga kuat, tapi scheduler yang pas tetap membantu.

# Cek scheduler saat ini
cat /sys/block/nvme0n1/queue/scheduler

# Set ke none buat NVMe (langsung, tanpa reboot)
echo none > /sys/block/nvme0n1/queue/scheduler

# Biar persist setelah reboot, pake udev rule
cat > /etc/udev/rules.d/60-iosched.rules <<'EOF'
ACTION=="add|change", KERNEL=="nvme*", ATTR{queue/scheduler}="none"
EOF

Jangan tanya kenapa banyak orang lupa bagian ini. Padahal buat disk NVMe, beda scheduler bisa keliatan di benchmark. Nggak segede beda RAM, tapi di workload I/O-heavy, perbedaannya tetep nyata.

Langkah 6: Apply dan Verifikasi

Oke, semua config udah ditulis ke /etc/sysctl.d/60-tuning.conf. Sekarang waktunya apply. Ada dua cara: sysctl -p buat baca satu file tertentu, atau sysctl --system buat baca semua file sysctl. Di AlmaLinux 8 dan 9, sysctl --system yang lebih proper karena dia baca semua file di /etc/sysctl.d/ dan /usr/lib/sysctl.d/.

# Apply semua setting
sysctl --system

# Verifikasi nilai yang udah ke-apply
sysctl net.core.somaxconn
sysctl vm.swappiness
sysctl fs.file-max

Output yang diharapkan kira-kira begini:

net.core.somaxconn = 65535
vm.swappiness = 10
fs.file-max = 2097152

Kalau nilainya nggak sesuai yang kita set, cek lagi file sysctl. Mungkin ada file lain di /etc/sysctl.d/ yang menimpa setting kita (urutan baca bisa bikin konflik). Sistem baca file secara lexicographic, jadi file dengan nama yang lebih akhir bisa nimpa nilai yang lebih awal. Makanya aku pakai awalan 60- biar file kita dibaca terakhir dan nggak ketimpa.

Nah, buat setting yang lewat GRUB (THP, mitigasi), itu baru aktif setelah reboot. Buat yang lewat udev rule (IO scheduler), itu aktif otomatis pas disk ke-add. Kalau mau cek THP tanpa reboot, kamu bisa set manual:

echo never > /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/enabled

Tapi inget, ini cuma sampai reboot. Setelah reboot dia balik ke nilai GRUB. Jadi tetep perlu edit GRUB buat permanen.

Langkah 7: Test dan Monitor Setelah Tuning

Buat apa tuning kalau nggak diuji? Ada bedanya, dan jangan cuma andalin perasaan. Aku biasanya pakai kombinasi: sysbench buat CPU/memory, iperf3 buat jaringan, dan ab (ApacheBench) atau wrk buat HTTP. Sebelum tuning, catat baseline. Sesudah tuning, jalanin lagi, bandingkan. Kalau hasilnya nggak berubah atau malah jelek, berarti ada yang nggak pas.

# CPU benchmark
sysbench cpu --threads=8 --time=30 run

# Memory benchmark
sysbench memory --threads=4 --time=30 run

# Network benchmark (dari client ke server)
iperf3 -c 203.0.113.10 -t 30

# HTTP benchmark ke webserver
ab -n 50000 -c 500 http://203.0.113.10/

Selain benchmark, yang lebih penting: pantau behavior-nya di beban nyata. Cek apakah masih ada TIME_WAIT yang numpuk, apakah backlog overflow hilang, apakah swap kepake. Kalau kamu udah pasang monitoring, ini saatnya keliatan manfaatnya. Belum punya monitoring? Cek artikel soal monitoring server Linux pakai Netdata, itu bisa langsung dipasang dan langsung keliatan grafik-grafiknya.

# Cek TIME_WAIT socket
ss -s

# Cek backlog overflow di log
dmesg | grep -i "backlog"

Common Mistakes dan Tips Tambahan

Dari pengalaman ngurusin banyak server, ada beberapa hal yang sering bikin orang tersandung pas tuning kernel. Yang pertama: nyalin parameter dari artikel lain tanpa mikir konteks. Nilai yang cocok buat server database belum tentu cocok buat webserver, dan sebaliknya. Parameter itu konteks-nya penting, jadi jangan asal comot.

Yang kedua: nggak bikin baseline sebelum tuning. Kalau kamu nggak pernah ukur performa sebelum dan sesudah, gimana mau tahu perubahannya bermanfaat atau malah bikin jelek? Aku selalu catat hasil benchmark awal, terus bandingin lagi seminggu kemudian. Data itu yang bikin keputusan, bukan perasaan.

Yang ketiga: langsung ubah banyak parameter sekaligus di production tanpa uji. Kalau bisa, ubah satu kelompok dulu (misal cuma network), pantau beberapa hari, baru lanjut ke kelompok berikutnya. Ini bikin kamu tahu persis parameter mana yang bikin efek, dan kalau ada masalah, isolasi-nya gampang.

Yang keempat, ini yang paling sering: lupa urutan baca sysctl. File di /etc/sysctl.d/ dibaca urut abjad, jadi kalau ada dua file set nilai yang sama, file yang dibaca terakhir yang menang. Makanya file kita kasih awalan 60- biar dia dibaca belakangan. Kalau kamu taruh di file yang awalan 10-, bisa-bisa nilainya ketimpa sama file lain.

Terakhir: reboot langsung pas jam sibuk setelah edit GRUB. Serius, jangan. Maintenance window itu bukan sekadar formalitas. Kalau salah set THP atau mitigasi dan server nggak bisa boot pas jam kerja, itu ticket yang nggak enak. Pisahkan jadwal reboot, pastikan konsol out-of-band siap, dan baru jalanin.

Tabel Troubleshooting: Tuning yang Salah Bisa Bikin Apa?

Gejala	Kemungkinan Penyebab	Cek Di	Solusi
Koneksi reset / connection refused pas traffic naik	somaxconn atau tcp_max_syn_backlog kekecilan	ss -ltn dan dmesg	Naikin net.core.somaxconn, cek backlog dengan ss
Socket TIME_WAIT numpuk ribuan	Koneksi pendek banyak + fin_timeout lama	ss -s	Aktifkan tcp_tw_reuse, turunin tcp_fin_timeout
Error "too many open files"	File descriptor habis	ulimit -n dan /proc/sys/fs/file-max	Naikin fs.file-max dan ulimit proses
Error "inotify watch limit reached"	max_user_watches kepake habis	/proc/sys/fs/inotify/max_user_watches	Naikin fs.inotify.max_user_watches
Swap kepake padahal RAM lega	swappiness kekecilan atau kesalahan prioritas	free -h dan vmstat	Atur vm.swappiness sesuai workload
Latency DB nggak stabil, khugepaged error	Transparent Huge Pages aktif	dmesg dan /sys/kernel/mm/transparent_hugepage/enabled	Set transparent_hugepage=never di GRUB
Server nggak boot setelah edit GRUB	Salah set boot parameter	Konsol out-of-band	Boot ke rescue/old kernel, restore backup grub

Oh ya, satu lagi. Kalau kamu ubah sysctl dan tiba-tiba SSH putus atau jaringan aneh, jangan panik. Kemungkinan besar salah satu parameter jaringan yang salah. Boot ulang server (atau pake console) buat balikin ke default, atau hapus file sysctl.d yang kita buat. Makanya tadi aku bilang backup dulu dan catat nilai awal — biar nggak nebak-nebak.

FAQ

Yaudah, itu dia. Nggak serumit yang dibayangin kan? Intinya, kernel default itu aman tapi bukan optimal. Dengan beberapa penyesuaian kecil, server AlmaLinux kamu bisa jauh lebih responsif pas beban naik. Sip, mugi bermanfaat. Kalau kamu pengen baca topik lain, ada beberapa artikel yang relate: panduan monitoring server Linux pakai Netdata, hardening SSH buat VPS, sama troubleshoot load average tinggi. Dan kalau kamu lagi berurusan sama webserver, optimasi Nginx buat high traffic atau optimasi MySQL/MariaDB juga worth dibaca. Matur nuwun udah mampir, sampai jumpa di artikel berikutnya!