Dalam pengelolaan arsitektur aplikasi berbasis PHP, pemilihan metode manajemen proses pada PHP-FPM (FastCGI Process Manager) merupakan variabel krusial yang menentukan efisiensi penggunaan sumber daya server. Ketidaktepatan dalam konfigurasi sering kali berujung pada in-efisiensi memori atau penumpukan antrean (queue) yang menghambat performa aplikasi.
Memilih strategi manajemen proses yang tepat bukan cuma soal angka, tapi soal bagaimana kita “memperlakukan” RAM agar tetap efisien. Terdapat tiga model manajemen proses PHP-FPM beserta batasan global yang perlu diperhatikan oleh administrator sistem.
Mode FPM
Parameter Kunci
php-fpm.conf
process.max
berapa jumlah proses maksimal di dalam RAM yang bisa ditangani secara akumulatif dari semua pool
*.conf pool
pm.max_children [static/dynamic/on-demand]
berapa jumlah proses maksimal di dalam RAM yang diperbolehkan untuk pool tersebut
pm.max_requests [static/dynamic]
berapa jumlah layanan yang diperbolehkan untuk dilayani oleh satu proses, jika nilai ini terpenuhi, maka proses tersebut akan di-recycle
pm.process_idle_timeout [on-demand]
berapa detik waktu tunggu yang dibutuhkan oleh satu proses ‘nganggur’ (idle) di RAM menunggu tugas berikutnya, jika waktu ini terpenuhi, maka proses tersebut akan dimatikan
pm.start_servers [dynamic]
berapa jumlah proses yang dibuat di RAM untuk pool tersebut untuk pertama kalinya
pm.min_spare_servers [dynamic]
berapa jumlah proses minimal yang harus ada di RAM untuk pool tersebut
pm.max_spare_servers [dynamic]
berapa batasan jumlah proses yang disisakan di RAM untuk pool tersebut
Mode Static: Si “Siap Sedia tapi Menuh-menuhin”
Tidak ada waktu tunggu buat forking proses karena proses dibuat di awal sebanyak pm.max_children. Performa sangat stabil.
Minus: begitu dibuat, sisa process.max langsung berkurang sebanyak pm.max_children pool ini. Makanya menuh-menuhin RAM. Ya kalau trafiknya ramai, kalau sepi?
Untuk menghindari memory leak, maka pengaturan pm.max_requests sangat perlu diperhatikan.
Mode Dynamic: Si “Fleksibel”
Dapat dikatakan sebagai win-win-solution dari static dan on-demand. Di awal membuat beberapa forking proses sesuai dengan pm.start_servers. Jika trafik melonjak, maka akan forking proses. Jika trafiknya sepi lagi, maka akan disisakan sebanyak pm.max_servers.
Untuk menghindari memory leak, maka pengaturan pm.max_requests sangat perlu diperhatikan.
Mode On-Demand: Si “Ngirit tapi Berat”
Kebalikan dari static, di sini tidak ada proses yang dibuat di awal. Performa cukup berat, karena begitu ada permintaan dan tidak ada proses yang masih idle (kurang dari pm.process_idle_timeout), maka forking proses yang ‘cukup’ berat baru dijalankan.
Plus: jika trafiknya sepi, maka RAM-nya jadi lega.
Simulasi
Konfigurasi pm = static (pada pool.d/www.conf)
Gambar menunjukkan jumlah proses tetap (5 children).
Mode static memang mempertahankan jumlah proses yang ditentukan oleh pm.max_children sepanjang waktu, terlepas dari beban request.
Konfigurasi pm = dynamic (pada pool.d/lib.conf)
Gambar menunjukkan proses yang bertambah/berkurang berdasarkan min_spare_servers dan max_spare_servers.
Mode dynamic bertujuan untuk menyeimbangkan konsumsi RAM dengan responsivitas; jika ada idle process di luar batas spare, maka akan di-terminate untuk menghemat sumber daya.
Konfigurasi pm = ondemand (pada pool.d/mail.conf)
Gambar menunjukkan proses hanya dibuat saat ada request baru dan akan mati setelah process_idle_timeout.
Mode ondemand paling hemat memori karena tidak ada proses yang berjalan di latar belakang jika tidak ada trafik, namun ada overhead sedikit lebih tinggi saat cold start proses baru.
Limitasi process.max
Gambar menunjukkan bahwa meskipun max_children per pool belum tercapai, jika total akumulasi proses dari semua pool (www + lib + mail) telah mencapai nilai process.max (global), maka request baru harus mengantre.
Ini adalah konsep krusial dalam troubleshooting PHP-FPM. Administrator sering lupa bahwa process.max di php-fpm.conf adalah batas atas total untuk seluruh pool yang berjalan di bawah satu master process.
Leave a Reply