Direktori Artikel
Bilangan pengguna serentak yang boleh dikendalikan oleh pelayan bergantung bukan pada berapa banyak teras yang dimilikinya, tetapi pada berapa banyak memori yang digunakan oleh setiap proses.
Kenyataan ini mungkin kedengaran seperti provokasi, tetapi ia adalah pengalaman paling nyata dan menyakitkan dalam industri operasi dan penyelenggaraan.
Mengapakah ingatan menjadi penghalang utama?
Ramai orang melihat VPS dengan CPU 8-teras dan memori 24GB dan secara tidak sedar berfikir bahawa mereka boleh menjalankan beratus-ratus proses PHP-FPM dengan mudah.
Walau bagaimanapun, pada hakikatnya, penggunaan memori RSS bagi satu proses PHP selalunya setinggi 200MB.
Ini adalah hasil yang diperoleh melalui ujian sebenar melalui baris arahan:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
Dalam persekitaran rangka kerja dan berbilang pemalam HestiaCP yang kompleks, terutamanya tanpa pengoptimuman OPcache, 200MB adalah kebiasaan.
Ini bermakna memori, bukan CPU, adalah had keras yang menentukan keserentakan maksimum.
Fail konfigurasi yang disyorkan (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
Logik pengiraan parameter dan asas penetapan
| Parameter konfigurasi | Menetapkan nilai | Pengiraan teras dan asas persediaan |
|---|---|---|
| pm | dynamic | Mod dinamik membolehkan penambahan atau penghapusan proses secara elastik berdasarkan keperluan keserentakan, pengimbangan kelajuan tindak balas dan penggunaan memori. |
| pm.max_children | 80 | Jumlah memori 24GB tolak kernel sistem dan MySQL/RedisSelepas Nginx, kira-kira 16GB tinggal untuk PHP.16,384 MB / 200 MB ≈ 81.9Menetapkannya kepada 80 boleh menghapuskan sepenuhnya OOM (Kehabisan Ingatan) semasa keserentakan tinggi. |
| pm.start_servers | 16 | Pemanasan awal semasa permulaan ditetapkan kepada dua kali ganda bilangan teras CPU (8 teras × 2 = 16) untuk memastikan perkhidmatan tersebut dapat mengendalikan serentak asas serta-merta selepas dimulakan semula. |
| pm.min_spare_servers | 8 | Tetapkan kiraan teras CPU kepada 8 teras untuk memastikan permintaan baharu boleh dibalas pada bila-bila masa semasa tempoh trafik rendah. |
| pm.max_spare_servers | 24 | Tetapkannya kepada 3 kali ganda bilangan teras CPU (8 teras × 3 = 24) untuk mengekalkan bilangan proses yang sederhana selepas trafik surut, bagi mengendalikan turun naik yang perlahan. |
| pm.max_requests | 500 | Jika satu proses mencapai saiz asas yang besar iaitu 200MB, mengurangkan bilangan permintaan kepada 500 sebelum memusnahkan dan membina semula boleh membersihkan kebocoran memori tersirat dengan lebih cepat. |
| pm.process_idle_timeout | 10s | Melebihi min_spare_servers Proses terbiar dilepaskan secara automatik dan dikembalikan ke memori sistem selepas 10 saat tiada permintaan. |
Tetapan Sokongan Penting dan Cadangan Pengoptimuman
1. Mekanisme anti-mabuk tamat masa
request_terminate_timeout = 60s Itulah kuncinya.
Ia boleh menamatkan proses yang tersekat akibat kebuntuan pangkalan data atau penyekatan API pihak ketiga secara paksa.
Sementara itu, Nginx fastcgi_read_timeout Ia mesti disimpan sekurang-kurangnya 60 saat, jika tidak, pelanggan akan menerimanya lebih awal. 504 Gateway Timeout.
2. Strategi untuk mengatasi kesesakan ingatan
Maksimum 80 proses serentak bermakna di bawah keadaan serentak yang ekstrem, sistem boleh mengendalikan maksimum 80 permintaan HTTP dinamik secara serentak.
Jika anda ingin meningkatkan lagi kapasiti, tumpuan harus diberikan kepada pengurangan penggunaan memori setiap proses.
- Dayakan OPcache: Dalam
php.iniKonfigurasi sederhanaopcache.enable=1Danopcache.memory_consumption=256Caching bytecode boleh mengurangkan penggunaan memori bagi satu proses daripada 200MB kepada 60~100MB. - Kawalan had_memori yang munasabah:Will
php.initengahmemory_limitTerhad kepada128M或256MUntuk mengelakkan skrip abnormal individutidak terhadIa menggunakan banyak memori.
Sebaik sahaja penggunaan memori bagi satu proses menurun kepada 100MB...pm.max_children Ia boleh dinaik taraf dengan selamat kepada 150 Di samping itu, keupayaan serentak telah meningkat hampir dua kali ganda.
Pandangan berwibawa dipetik
Menurut cadangan dalam dokumentasi rasmi Nginx :
"Aplikasi FastCGI harus sentiasa dipantau dengan arahan tamat masa untuk mengelakkan kehabisan sumber."
(Sumber: Dokumen Nginx)
Manual PHP rasmi dengan jelas menyatakan:
"pm.max_children mentakrifkan bilangan maksimum proses anak yang akan dicipta. Ini adalah arahan yang paling penting."
(Sumber: Dokumentasi PHP-FPM)
Pandangan berwibawa ini selaras dengan amalan kami, membuktikan bahawa logik pengoptimuman bukan sahaja berdasarkan pengalaman, tetapi juga amalan terbaik yang piawai.
Kesimpulan: Pandangan dan Petikan Utama Saya
Dalam senario serentak tinggi, CPU ialah enjin, memori ialah tangki bahan api dan PHP-FPM ialah penghantar armada.
Tidak kira betapa berkuasanya enjin itu, jika tangki bahan api tidak cukup besar, konvoi itu tidak akan pergi jauh.
Pakar sejati tidak memaksimumkan parameter secara membuta tuli, tetapi sebaliknya mengira penggunaan memori setiap proses dengan tepat untuk mengelakkan pembaziran dan limpahan.
Intipati pengoptimuman adalah untuk mencari keseimbangan optimum dengan sumber yang terhad.
Ini bukan sekadar teknologi, tetapi juga falsafah.
Oleh itu, berhentilah mempercayai bahawa "bilangan teras menentukan segala-galanya." Apa yang benar-benar menentukan had serentak ialah kawalan anda ke atas memori.
Ambil tindakan dan optimumkan VPS anda sepenuhnya, manfaatkan setiap titisan memori sebaik mungkin.
Semoga artikel "VPS 8-teras 24GB kehabisan memori? Penalaan ekstrem kolam proses PHP-FPM di bawah HestiaCP" yang dikongsi di blog Chen Weiliang ( https://www.chenweiliang.com/ ) akan membantu anda.
Jangan ragu untuk berkongsi pautan artikel ini: https://www.chenweiliang.com/cwl-34509.html