Anda mengelola Platform Layanan Kesehatan Digital dengan ribuan pengguna aktif. Tim marketing sedang beriklan, namun fitur penting—upload gambar/dokumen—mengalami gangguan.
Reaksi pertama banyak orang adalah panik. Reaksi kedua adalah menganggap "Servernya penuh, harus upgrade!" atau "Ganti versi PHP sekarang!"
Minggu ini, saya melakukan audit mendalam pada server produksi klien yang mengalami masalah ini. Spesifikasinya adalah 4 Core CPU, 8GB RAM, SSD NVMe. Namun, saat saya masuk ke terminal, saya menemukan bahwa masalahnya bukan karena spesifikasi server, melainkan karena "kepanikan" yang memicu reaksi berantai di level sistem operasi.
Berikut penjelasannya.
🕵️ Diagnosis: Jejak Digital Kepanikan
Selama audit logs (journalctl dan nginx error log), server menunjukkan tanda-tanda masalah. Berikut data mentah yang ditemukan:
- Swap Membengkak: Dari total 8GB RAM, Swap Used mencapai 2.8GB. Ini menunjukkan server sedang swapping parah, yang berdampak pada performa.
- Slow Queries Menumpuk: Terdapat 696.604 slow queries di database, mengindikasikan antrian yang tidak efisien.
- The Smoking Gun (Penyebab Utama): Di log PHP-FPM, terdapat pola switching versi PHP yang tidak wajar.
Tercatat pada tanggal 9 Desember, ada 69 kali percobaan start PHP 7.4 dalam waktu 2 jam.
Tim teknis internal mungkin mencoba memperbaiki masalah dengan bergonta-ganti versi PHP secara cepat (Rapid Switching). Meskipun niatnya baik, eksekusi yang terlalu agresif tanpa memberi jeda pada systemd menyebabkan masalah.
Akibatnya, terjadi Race Condition. Sistem operasi belum selesai mematikan proses lama dan membersihkan temporary directory, namun sudah dipaksa menyalakan proses baru. Hal ini mengakibatkan direktori /tmp yang digunakan oleh PHP menjadi corrupt atau "hilang" dari pandangan service PHP.
🛠️ Tindakan: Tenang, Jangan Asal Upgrade
Klien hampir memutuskan untuk upgrade server karena mengira disk space penuh. Namun, upgrade server TIDAK AKAN menyelesaikan masalah konfigurasi systemd yang rusak.
Berikut langkah-langkah yang saya lakukan:
1. Analisis PrivateTmp=yes
Service PHP-FPM di server modern menggunakan fitur keamanan PrivateTmp=yes. Artinya, PHP tidak menggunakan /tmp umum, melainkan membuat folder rahasia sendiri (isolated). Karena switching yang tidak teratur, folder rahasia ini gagal dibuat ulang dengan benar.
2. The Clean Restart (Bukan Reload)
Saya melakukan graceful restart pada service PHP 8.1, memastikan proses lama benar-benar mati, dan membiarkan systemd membuat ulang struktur direktori temporary yang bersih.
root@server:~# systemctl restart php81rc-fpm
# Command yang menyelamatkan situasi3. Audit Resource (Bonus Optimisasi)
Saya juga menemukan VSCode Server memakan 10% memori dan 3 instance layanan notifikasi WA berjalan bersamaan. Saya memberikan rekomendasi limitasi memori agar server dapat beroperasi lebih efisien.
📊 Hasil: Sebelum vs Sesudah
Hanya dalam hitungan menit setelah diagnosis yang tepat:
- ❌ Sebelum: Upload file gagal 100%, tim admin mengalami tekanan, antrian komplain user menumpuk.
- ✅ Sesudah: Fitur upload berfungsi dengan baik. Direktori temporary kembali bersih.
- 💰 Efisiensi: Klien TIDAK PERLU mengeluarkan biaya untuk upgrade server bulan ini.
Status Akhir:
✅ RESOLVED - Upload berfungsi normal.
⚠️ MONITORING - Perlu optimalisasi Query Database (690k slow queries menjadi perhatian selanjutnya).
💡 Kesimpulan: Sabar itu Bagian dari Skill Teknis
Pelajaran dari kasus ini:
- Jangan Spam Restart: Saat mengubah konfigurasi server (terutama versi PHP), beri jeda 30-60 detik. Biarkan server "tarik napas".
- Upgrade Server itu Opsi Terakhir: Masalah permission tidak akan teratasi dengan menambah RAM.
- Audit Log adalah Kunci: Jangan menebak-nebak. Data di log tidak pernah berbohong.
Jika Anda memiliki server dengan trafik tinggi namun sering mengalami gangguan tanpa alasan jelas, pertimbangkan untuk melakukan audit konfigurasi sebelum memutuskan untuk upgrade server. Untuk informasi lebih lanjut tentang audit server, Anda dapat membaca artikel ini dan artikel ini.
