Artikkelihakemisto
Palvelimen käsittelemien samanaikaisten käyttäjien määrä ei riipu ytimien määrästä, vaan kunkin prosessin kuluttamasta muistista.
Tämä lausunto saattaa kuulostaa provokaatiolta, mutta se on todellisin ja tuskallisin kokemus käyttö- ja kunnossapitoalalla.
Miksi muisti on keskeinen pullonkaula?
Monet ihmiset näkevät virtuaalipalvelimen, jossa on 8-ytiminen suoritin ja 24 Gt muistia, ja alitajuisesti ajattelevat, että ne voivat helposti suorittaa satoja PHP-FPM-prosesseja.
Todellisuudessa yhden PHP-prosessin RSS-muistin käyttö on kuitenkin usein jopa 200 Mt.
Tämä on tulos, joka saatiin komentorivin kautta tehdyllä varsinaisella testauksella:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
HestiaCP :n monimutkaisessa kehyksessä ja usean liitännäisen ympäristössä, erityisesti ilman OPcache-optimointia, 200 Mt on normi.
Tämä tarkoittaa, että muisti, ei suoritin, on se kova raja, joka määrittää suurimman mahdollisen samanaikaisuuden.
Suositeltu asetustiedosto (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
Parametrien laskentalogiikka ja asetusperuste
| Konfigurointiparametrit | Asetusarvo | Ytimen laskenta ja asennusperuste |
|---|---|---|
| pm | dynamic | Dynaaminen tila mahdollistaa prosessien joustavan lisäämisen tai poistamisen samanaikaisuusvaatimusten perusteella, tasapainottaen vasteaikaa ja muistin käyttöä. |
| pm.max_children | 80 | 24 Gt kokonaismuistia ilman järjestelmäydintä ja MySQL/RedisNginxin jälkeen PHP:lle jää noin 16 Gt tilaa.16,384 MB / 200 MB ≈ 81.9Arvon 80 asettaminen voi poistaa kokonaan muistin loppumisen (OOM, Out of Memory) suuren samanaikaisuuden aikana. |
| pm.aloituspalvelimet | 16 | Käynnistyksen yhteydessä esilämmitys asetetaan kaksinkertaiseksi suorittimen ytimien määrään verrattuna (8 ydintä × 2 = 16), jotta palvelu pystyy käsittelemään perus-samanaikaisuuden välittömästi uudelleenkäynnistyksen jälkeen. |
| pm.min_spare_servers | 8 | Aseta suorittimen ytimien määräksi 8 ytintä varmistaaksesi, että uusiin pyyntöihin voidaan vastata milloin tahansa vähäisen liikenteen aikana. |
| pm.max_spare_servers | 24 | Aseta se kolminkertaiseksi suorittimen ytimien määrään verrattuna (8 ydintä × 3 = 24), jotta kohtuullinen määrä prosesseja säilyy liikenteen vähenemisen jälkeen ja että liikenteen vaihtelut ovat lieviä. |
| pm.max_requests | 500 | Jos yksittäinen prosessi saavuttaa 200 Mt:n suuren muistikapasiteetin, pyyntöjen määrän vähentäminen 500:aan ennen tuhoamista ja uudelleenrakentamista voi puhdistaa implisiittiset muistivuodot nopeammin. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers Käyttämättömät prosessit vapautetaan automaattisesti ja palautetaan järjestelmämuistiin 10 sekunnin kuluttua, jos pyyntöjä ei ole tehty. |
Olennaiset tukiasetukset ja optimointiehdotukset
1. Aikakatkaisu krapulanestomekanismeilla
request_terminate_timeout = 60s Se on avainasemassa.
Se voi pakottaa lopettamaan prosesseja, jotka ovat jumissa tietokannan lukkiutumisen tai kolmannen osapuolen API-estojen vuoksi.
Samaan aikaan Nginxin fastcgi_read_timeout Sitä on säilytettävä vähintään 60 sekuntia, muuten asiakas saa sen ennenaikaisesti. 504 Gateway Timeout.
2. Strategioita muistin pullonkaulojen voittamiseksi
Enintään 80 samanaikaista prosessia tarkoittaa, että äärimmäisissä samanaikaisuusolosuhteissa järjestelmä voi käsitellä enintään 80 dynaamista HTTP-pyyntöä samanaikaisesti.
Jos haluat parantaa kapasiteettia entisestään, tulisi keskittyä prosessikohtaisen muistin käytön vähentämiseen.
- Ota OPcache käyttöön: olemassa
php.iniKeskikokoinen kokoonpanoopcache.enable=1及opcache.memory_consumption=256Tavukoodivälimuisti voi vähentää yksittäisen prosessin muistin käyttöä 200 megatavusta 60–100 megatavuun. - Kohtuullinen muistirajoituksen hallinta：将
php.inikeskellämemory_limitRajoitettu128M或256MYksittäisten poikkeavien skriptien estämiseksirajoittamatonSe kuluttaa paljon muistia.
Kun yhden prosessin muistin käyttö laskee 100 megatavuun...pm.max_children Se voidaan turvallisesti päivittää 150 Lisäksi samanaikaisuusominaisuus on lähes kaksinkertaistunut.
Viitatut arvovaltaiset näkökulmat
Nginxin virallisen dokumentaation suositusten mukaan :
"FastCGI-sovelluksia tulisi aina valvoa aikakatkaisudirektiivien avulla resurssien loppumisen estämiseksi."
(Lähde: Nginx-dokumentaatio)
Virallisessa PHP-käyttöoppaassa lukee selvästi:
"pm.max_children määrittää luotavien lapsiprosessien enimmäismäärän. Tämä on tärkein direktiivi."
(Lähde: PHP-FPM-dokumentaatio)
Nämä arvovaltaiset näkemykset ovat täysin linjassa käytäntöjemme kanssa, mikä osoittaa, että optimointilogiikka ei perustu pelkästään kokemukseen, vaan myös standardoituihin parhaisiin käytäntöihin.
Yhteenveto: Näkökulmani ja keskeiset lainaukset
Korkean samanaikaisuuden skenaarioissa CPU on moottori, muisti on polttoainesäiliö ja PHP-FPM on kaluston lähetin.
Olipa moottori kuinka tehokas tahansa, saattue ei pääse kovin pitkälle, jos polttoainesäiliö ei ole tarpeeksi suuri.
Todelliset asiantuntijat eivät sokeasti maksimoi parametreja, vaan laskevat tarkasti kunkin prosessin muistin käytön välttääkseen sekä muistin hukkaa että ylivuotoa.
Optimoinnin ydin on löytää optimaalinen tasapaino rajallisilla resursseilla.
Tämä ei ole vain teknologiaa, vaan myös filosofiaa.
Lakkaa siis ajattelemasta, että "ytimien lukumäärä määrää kaiken". Rinnakkaisuusrajan todella määrää muistin hallinta.
Ryhdy toimiin ja optimoi VPS:si täysimääräisesti hyödyntäen jokaisen muistipisaran.
Toivottavasti Chen Weiliangin blogissa ( https://www.chenweiliang.com/ ) jaetusta artikkelista "8-core 24GB VPS running out of memory? Extreme tuning of PHP-FPM process pool under HestiaCP" on sinulle hyötyä.
Voit vapaasti jakaa tämän artikkelin linkin: https://www.chenweiliang.com/cwl-34509.html