Menghadapi skala trafik nasional memerlukan ketenangan dalam pengambilan keputusan teknis. Seringkali, solusi instan yang muncul saat performa menurun adalah melakukan upgrade hardware. Namun, dalam praktik yang saya jalani, optimasi konfigurasi dan audit mendalam terhadap sistem yang ada merupakan langkah pertama yang jauh lebih efisien sebelum memutuskan untuk menambah biaya langganan server.
Baru-baru ini, saya melakukan audit dan pemeliharaan pada sebuah infrastruktur platform Edu-Tech. Trafik yang tinggi, penggunaan memori yang mulai kritis, dan laporan kegagalan pada fungsi-fungsi penting di sisi pengguna menjadi fokus utama.
Context & Problem: Tekanan Trafik dan Risiko Downtime
Setelah melakukan inspeksi pada terminal Server-Prod-Main di IP 203.0.113.x, saya menemukan statistik penggunaan yang cukup intensif. Dalam kurun waktu 30 hari, satu node server ini harus melayani beban kerja yang signifikan:
- Aplikasi Pembelajaran Inti: 6.3 Juta Request
- Sistem Ujian Penempatan: 4.45 Juta Request
- Web Utama: 3.33 Juta Request
Secara akumulatif, server menangani lebih dari 15 juta hits per bulan. Dengan spesifikasi 32 GB RAM, penggunaan memori sudah menyentuh angka 22.6 GB (70%). Secara teknis, ini adalah zona kuning. Jika terjadi lonjakan trafik sebesar 50% saja—misalnya saat musim pendaftaran siswa baru—proyeksi penggunaan memori akan melampaui kapasitas fisik (105%) yang berujung pada kondisi Out of Memory (OOM) dan crash sistem.
Gejala awal sudah mulai terlihat dengan munculnya ribuan log Error 5xx pada aplikasi pendaftaran, yang secara langsung mengganggu alur konversi pengguna.
Deep Analysis: Akar Masalah di Balik Resource yang Menipis
Melalui pemantauan internal, saya mengidentifikasi beberapa faktor yang menyebabkan degradasi performa ini bukan semata-mata karena kurangnya spesifikasi, melainkan masalah manajemen resource:
1. Akumulasi Log dan Cache
Server ini memiliki waktu aktif (uptime) selama 77 hari tanpa pembersihan rutin. Log sistem keamanan seperti CrowdSec membengkak hingga ratusan MB, ditambah dengan file log lama yang tidak terkompresi, menghabiskan ruang disk dan membebani proses I/O.
2. Keberadaan "Zombie Service"
Saya menemukan beberapa layanan internal seperti db-admin dan docker-manager yang mengalami miskonfigurasi. Meskipun tidak aktif digunakan, layanan ini terus mencoba menjalankan proses yang gagal, mengonsumsi siklus CPU dan RAM hanya untuk menghasilkan log error.
3. Konsumsi Memori Database
Layanan database mengonsumsi sekitar 14 GB RAM. Meski wajar untuk trafik tinggi, terdapat indikasi memori yang "tersangkut" pada proses PHP-FPM yang tidak menutup dengan sempurna (memory leak), sehingga ruang kosong tidak segera kembali ke sistem.
The Solution: Langkah Optimasi Bertahap
Alih-alih menyarankan penambahan RAM, saya memilih pendekatan "Deep Clean" dan tuning performa. Berikut adalah langkah-langkah teknis yang saya implementasikan:
1. Pembersihan Log dan Journal
Langkah pertama adalah membebaskan ruang dan mengurangi beban kerja sistem manajemen log dengan melakukan rotasi dan pembersihan manual pada systemd journal:
# Membersihkan journal log yang lebih lama dari 2 hari
journalctl --vacuum-time=2d
# Menjalankan logrotate secara paksa untuk mengompresi log lama
logrotate -f /etc/logrotate.conf2. Eliminasi Layanan Tidak Efisien
Saya menonaktifkan layanan yang tidak memberikan kontribusi pada operasional produksi namun membebani sistem. Hal ini secara instan menghentikan banjir log Error 5xx internal.
3. Tuning PHP-FPM dan Memory Management
Untuk menangani memori yang tersangkut, saya melakukan optimasi pada konfigurasi PHP-FPM dan melakukan restart terukur pada layanan terkait. Hal ini bertujuan untuk membebaskan buffer yang tidak lagi diperlukan oleh sistem tanpa mengganggu koneksi pengguna yang sedang aktif.
Catatan Teknis: Melakukan restart service pada trafik tinggi memerlukan parameter graceful reload agar tidak memutus sesi transaksi database yang sedang berjalan.
4. Penguatan Keamanan Sistem
Optimasi tidak lengkap tanpa penguatan benteng pertahanan. Dari log audit, tercatat ada 642 serangan SSH brute force dan 3.501 serangan bot scanner pada protokol HTTP. Saya memperbarui ruleset pada firewall dan sistem keamanan untuk memastikan resource tidak habis digunakan oleh trafik ilegal.
The Result: Stabilitas Tanpa Biaya Tambahan
Proses pemeliharaan ini memakan waktu kurang lebih satu jam tanpa menyebabkan downtime pada layanan. Hasilnya cukup signifikan:
- Efisiensi Resource: Penggunaan memori turun secara stabil. Buffer/Cache berhasil dibebaskan sebesar 2.4 GB, memberikan ruang yang cukup untuk
