@harrasteblogi JUURI NYT
--:--

Tilaa uutiskirje

Saat tuoreimmat 10 uusinta artikkelia kerran viikossa sähköpostiisi.

Tilaa uutiskirje

WordPress PHP-FPM worker saturation – syyt ja korjauksetPHP-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.

Tiivistelmä
Mitä PHP-FPM worker saturation tarkoittaa

Worker on PHP-prosessi, joka käsittelee yksittäisiä pyyntöjä....

Yleisimmät syyt

Yksi hidas SQL-kysely voi pitää workerin varattuna useita sekunteja....

Välimuistin puuttuminen:

Jos käytössä ei ole:...

Huonosti optimoidut lisäosat:

Yleisiä ongelmalähteitä:...

Liian pieni pm.max_children:

Yksi yleisimmistä virheistä....

PHP-FPM-konfiguraation optimointi

Määrittää workerien maksimimäärän....

Miten tunnistaa worker saturation

Mahdollistaa seurannan:...

htop ja top:

Tarkkaile:...

Korjauskeinot

Esimerkiksi:...

Yleisimmät virheet

Jos SQL-kyselyt ovat hitaita:...

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....

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.

🍪