PHP-FPM (FastCGI Process Manager) on useimpien modernien WordPress-palvelimien PHP-suoritin. Sen tehtävänä on käsitellä WordPressin PHP-pyynnöt tehokkaasti ja hallita palvelimen resursseja. Kun PHP-FPM workerit ylikuormittuvat eli tapahtuu worker saturation, sivusto alkaa hidastua, käyttäjät kohtaavat virheitä ja palvelin voi muuttua epävakaaksi.
Worker on PHP-prosessi, joka käsittelee yksittäisiä pyyntöjä....
Esimerkkejä:...
Yksi hidas SQL-kysely voi pitää workerin varattuna useita sekunteja....
Jos käytössä ei ole:...
Yleisiä ongelmalähteitä:...
Esimerkkejä:...
Yksi yleisimmistä virheistä....
Määrittää workerien maksimimäärän....
Mahdollistaa seurannan:...
Tarkkaile:...
Esimerkiksi:...
Jos SQL-kyselyt ovat hitaita:...
PHP-FPM worker saturation on yksi yleisimmistä WordPress-suorituskykyongelmista suurilla sivustoilla. Ongelma syntyy, kun PHP-prosessit ovat jatkuvasti varattuja eikä uusia pyyntöjä voida käsitellä ajoissa....
Monissa tapauksissa ongelma tulkitaan virheellisesti liian pieneksi palvelimeksi, vaikka todellinen syy löytyy huonosti optimoidusta WordPressistä, hitaista tietokantakyselyistä tai väärin mitoitetusta PHP-FPM-konfiguraatiosta.
Mitä PHP-FPM worker saturation tarkoittaa
PHP-FPM worker:
Worker on PHP-prosessi, joka käsittelee yksittäisiä pyyntöjä.
Kun käyttäjä avaa WordPress-sivun:
- Nginx tai Apache vastaanottaa pyynnön
- pyyntö välitetään PHP-FPM:lle
- worker suorittaa WordPressin PHP-koodin
- vastaus palautetaan käyttäjälle
Saturation:
Saturation tapahtuu, kun kaikki käytettävissä olevat workerit ovat varattuja.
Seurauksena:
- uudet pyynnöt joutuvat jonoon
- vasteajat kasvavat nopeasti
- syntyy 502- ja 504-virheitä
- sivusto tuntuu satunnaisesti hitaalta
Miten ongelma näkyy käytännössä
Tyypilliset oireet:
- korkea TTFB (Time To First Byte)
- satunnaiset 502 Bad Gateway -virheet
- satunnaiset 504 Gateway Timeout -virheet
- CPU ei välttämättä ole täynnä
- käyttäjät kokevat hitautta erityisesti ruuhka-aikoina
PHP-FPM logeissa:
Esimerkkejä:
server reached pm.max_children setting
tai
pool seems busy
Nämä ovat lähes aina merkki worker saturationista.
Yleisimmät syyt
Hitaat WP_Query-kyselyt:
Yksi hidas SQL-kysely voi pitää workerin varattuna useita sekunteja.
Tyypillisiä syyllisiä:
- raskaat meta_queryt
- WooCommerce-tuotehaut
- huonosti indeksoidut tietokannat
- isot hakutoiminnot
Kun worker odottaa tietokantaa:
→ se ei voi käsitellä uusia pyyntöjä.
Välimuistin puuttuminen:
Jos käytössä ei ole:
- page cachea
- object cachea
- Redis-cachea
WordPress rakentaa jokaisen sivun alusta asti.
Seurauksena:
- workerit kuormittuvat nopeasti
- samat kyselyt toistuvat jatkuvasti
Huonosti optimoidut lisäosat:
Yleisiä ongelmalähteitä:
- page builderit
- analytiikkalisäosat
- WooCommerce-lisäosat
- varmuuskopiointityökalut
Erityisesti lisäosat, jotka tekevät ulkoisia API-kutsuja, voivat pitää workerin varattuna pitkään.
Hitaat ulkoiset yhteydet:
Esimerkkejä:
- maksupalvelut
- CRM-integraatiot
- SMTP-palvelut
- REST API -kutsut
Jos ulkoinen palvelu vastaa hitaasti:
→ PHP-worker odottaa.
Liian pieni pm.max_children:
Yksi yleisimmistä virheistä.
Esimerkki:
pm.max_children = 5
Jos sivustolla on:
- 50 samanaikaista käyttäjää
Viisi workeria voi loppua välittömästi.
PHP-FPM-konfiguraation optimointi
pm.max_children:
Määrittää workerien maksimimäärän.
Laskenta perustuu:
Palvelimen RAM:
- PHP-workerin keskimääräinen muistinkulutus
Esimerkki:
- RAM käytettävissä PHP:lle = 4 GB
- yksi worker = 80 MB
Laskelma:
4096 / 80 ≈ 51 workeria
Turvamarginaalin jälkeen:
- noin 40–45 workeria
pm.max_requests:
Tärkeä asetuksen optimointi.
Esimerkki:
pm.max_requests = 500
Hyöty:
- worker käynnistyy uudelleen määräajoin
- ehkäisee muistivuotojen kertymistä
pm.process_idle_timeout:
Auttaa hallitsemaan käyttämättömiä workereita.
Erityisen hyödyllinen pienillä VPS-palvelimilla.
Miten tunnistaa worker saturation
PHP-FPM status-sivu:
Mahdollistaa seurannan:
- active processes
- idle processes
- max children reached
Jos:
- idle processes = 0
jatkuvasti, workerit ovat loppumassa.
htop ja top:
Tarkkaile:
- php-fpm-prosessien määrää
- muistinkäyttöä
- CPU-kuormaa
Slow log:
PHP-FPM slowlog:
request_slowlog_timeout = 5s
Paljastaa:
- hitaat funktiot
- hitaat lisäosat
- pitkät SQL-operaatiot
Korjauskeinot
Ota käyttöön page cache:
Esimerkiksi:
Tämä voi vähentää PHP-kuormaa jopa yli 90 %.
Redis Object Cache:
Redis vähentää:
- tietokantakyselyitä
- WP_Query-kuormaa
- PHP-prosessien käyttöaikaa
Optimoi tietokanta:
Tarkista:
- slow query log
- indeksit
- postmeta-taulu
Yksi hidas kysely voi kuluttaa enemmän resursseja kuin kymmenet normaalit pyynnöt.
Optimoi WooCommerce:
WooCommerce aiheuttaa usein:
- raskaita meta_queryjä
- suuria object cache -tarpeita
- pitkiä API-kutsuja
Redis ja tehokas page cache ovat lähes pakollisia suuremmissa verkkokaupoissa.
Skaalaa infrastruktuuria:
Jos optimointi on tehty:
- lisää RAM-muistia
- kasvata workerimäärää
- käytä kuormantasausta
Mutta vasta optimoinnin jälkeen.
Yleisimmät virheet
Nostetaan vain pm.max_children:
Jos SQL-kyselyt ovat hitaita:
- ongelma vain siirtyy tietokantaan
Ei seurata muistinkulutusta:
Liian suuri workerimäärä:
- voi aiheuttaa swapin käyttöä
- pahentaa suorituskykyä
Ei käytetä cachea:
Tämä on yleisin syy worker saturationiin WordPressissä.
Yhteenveto
PHP-FPM worker saturation on yksi yleisimmistä WordPress-suorituskykyongelmista suurilla sivustoilla. Ongelma syntyy, kun PHP-prosessit ovat jatkuvasti varattuja eikä uusia pyyntöjä voida käsitellä ajoissa.
Yleisimmät syyt ovat:
- hitaat WP_Query-kyselyt
- puuttuva välimuisti
- raskaat lisäosat
- ulkoiset API-kutsut
- väärin mitoitettu PHP-FPM-konfiguraatio
Paras ratkaisu on yhdistelmä:
- page cachea
- Redis object cachea
- tietokannan optimointia
- PHP-FPM:n oikeaa mitoitusta
Kun nämä osa-alueet ovat kunnossa, WordPress pystyy käsittelemään huomattavasti suurempia liikennemääriä ilman workerien ylikuormittumista.