Direktori Artikel
Jumlah pengguna bersamaan yang dapat ditangani oleh sebuah server tidak bergantung pada berapa banyak inti prosesor yang dimilikinya, tetapi pada berapa banyak memori yang dikonsumsi oleh setiap proses.
Pernyataan ini mungkin terdengar seperti provokasi, tetapi ini adalah pengalaman paling nyata dan menyakitkan dalam industri operasi dan pemeliharaan.
Mengapa memori menjadi hambatan utama?
Banyak orang melihat VPS dengan CPU 8-core dan memori 24GB dan secara tidak sadar berpikir bahwa mereka dapat dengan mudah menjalankan ratusan proses PHP-FPM.
Namun, pada kenyataannya, penggunaan memori RSS oleh satu proses PHP seringkali mencapai 200MB.
Berikut adalah hasil yang diperoleh melalui pengujian aktual melalui baris perintah:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
Dalam kerangka kerja HestiaCP yang kompleks dan lingkungan multi-plugin, terutama tanpa optimasi OPcache, 200MB adalah hal yang wajar.
Ini berarti bahwa memori, bukan CPU, adalah batasan utama yang menentukan konkurensi maksimum.
File konfigurasi yang direkomendasikan (php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
Logika perhitungan parameter dan dasar pengaturannya
| Parameter konfigurasi | Nilai pengaturan | Dasar perhitungan dan pengaturan inti |
|---|---|---|
| pm | dynamic | Mode dinamis memungkinkan penambahan atau penghapusan proses secara elastis berdasarkan kebutuhan konkurensi, menyeimbangkan kecepatan respons dan pemanfaatan memori. |
| pm.max_children | 80 | Total memori 24GB dikurangi kernel sistem dan MySQL/RedisSetelah Nginx, tersisa sekitar 16GB untuk PHP.16,384 MB / 200 MB ≈ 81.9Menyetelnya ke 80 dapat sepenuhnya menghilangkan OOM (Out of Memory) selama konkurensi tinggi. |
| pm.start_servers | 16 | Pemanasan awal saat startup diatur menjadi dua kali jumlah inti CPU (8 inti × 2 = 16) untuk memastikan bahwa layanan dapat langsung menangani konkurensi dasar setelah restart. |
| server cadangan minimum | 8 | Atur jumlah inti CPU menjadi 8 inti untuk memastikan bahwa permintaan baru dapat ditanggapi kapan saja selama periode lalu lintas rendah. |
| pm.maks_server_cadangan | 24 | Atur nilainya menjadi 3 kali jumlah inti CPU (8 inti × 3 = 24) untuk mempertahankan jumlah proses yang moderat setelah lalu lintas mereda, agar dapat menangani fluktuasi yang ringan. |
| pm.max_requests | 500 | Jika sebuah proses tunggal mencapai ukuran basis yang besar yaitu 200MB, mengurangi jumlah permintaan menjadi 500 akan menghancurkan dan membangun kembali proses tersebut, yang dapat membersihkan kebocoran memori implisit dengan lebih cepat. |
| pm.process_idle_timeout | 10s | Melebihi min_spare_servers Proses yang menganggur akan secara otomatis dilepaskan dan dikembalikan ke memori sistem setelah 10 detik tanpa permintaan. |
Pengaturan Pendukung Penting dan Saran Pengoptimalan
1. Mekanisme penanggulangan mabuk (timeout)
request_terminate_timeout = 60s Itulah kuncinya.
Fitur ini dapat menghentikan secara paksa proses yang macet karena kebuntuan basis data atau pemblokiran API pihak ketiga.
Sementara itu, Nginx's fastcgi_read_timeout Pesan tersebut harus disimpan setidaknya selama 60 detik, jika tidak, klien akan menerimanya sebelum waktunya. 504 Gateway Timeout.
2. Strategi untuk mengatasi hambatan memori
Jumlah maksimum 80 proses bersamaan berarti bahwa dalam kondisi konkurensi ekstrem, sistem dapat menangani maksimal 80 permintaan HTTP dinamis secara bersamaan.
Jika Anda ingin meningkatkan kapasitas lebih lanjut, fokusnya harus pada pengurangan penggunaan memori per proses.
- Aktifkan OPcache: 30 menit
php.iniKonfigurasi sedangopcache.enable=1danopcache.memory_consumption=256Caching bytecode dapat mengurangi penggunaan memori pada satu proses dari 200MB menjadi 60~100MB. - Kontrol yang wajar terhadap memory_limit:Akan
php.initengahmemory_limitTerbatas pada128M或256MUntuk mencegah skrip abnormal individualtak terbatasHal itu menghabiskan banyak memori.
Begitu penggunaan memori suatu proses tunggal turun hingga 100MB...pm.max_children Ini dapat ditingkatkan dengan aman menjadi 150 Selain itu, kemampuan konkurensi juga hampir berlipat ganda.
Pandangan-pandangan otoritatif yang dikutip
Sesuai dengan rekomendasi dalam dokumentasi resmi Nginx :
"Aplikasi FastCGI harus selalu dipantau dengan arahan batas waktu untuk mencegah kehabisan sumber daya."
(Sumber: Dokumentasi Nginx)
Manual resmi PHP dengan jelas menyatakan:
"pm.max_children menentukan jumlah maksimum proses anak yang akan dibuat. Ini adalah arahan yang paling penting."
(Sumber: Dokumentasi PHP-FPM)
Pandangan-pandangan otoritatif ini selaras sepenuhnya dengan praktik-praktik kami, membuktikan bahwa logika optimasi tidak hanya didasarkan pada pengalaman, tetapi juga pada praktik terbaik yang terstandarisasi.
Kesimpulan: Pandangan dan Kutipan Utama Saya
Dalam skenario konkurensi tinggi, CPU adalah mesinnya, memori adalah tangki bahan bakarnya, dan PHP-FPM adalah pengatur armadanya.
Sekuat apa pun mesinnya, jika tangki bahan bakarnya tidak cukup besar, konvoi tersebut tidak akan bisa melaju jauh.
Para ahli sejati tidak serta merta memaksimalkan parameter, melainkan menghitung secara tepat penggunaan memori setiap proses untuk menghindari pemborosan dan kelebihan beban.
Inti dari optimasi adalah menemukan keseimbangan optimal dengan sumber daya yang terbatas.
Ini bukan hanya teknologi, tetapi juga filosofi.
Oleh karena itu, berhentilah percaya bahwa "jumlah core menentukan segalanya." Yang benar-benar menentukan batas konkurensi adalah kendali Anda atas memori.
Ambil tindakan dan optimalkan VPS Anda hingga potensi maksimalnya, manfaatkan setiap tetes memori secara maksimal.
Semoga artikel "8-core 24G VPS kehabisan memori? Penyesuaian ekstrem pada process pool PHP-FPM di bawah HestiaCP" yang dibagikan di blog Chen Weiliang ( https://www.chenweiliang.com/ ) bermanfaat bagi Anda.
Silakan bagikan tautan artikel ini: https://www.chenweiliang.com/cwl-34509.html