PHP-muistin hallinta on yksi WordPress-ympäristön vähiten ymmärretyistä mutta vaikutuksiltaan merkittävimmistä osa-alueista. Monet suorituskyky- ja vakausongelmat eivät johdu hitaasta koodista tai huonosta tietokannasta, vaan siitä, että PHP:n muistia käytetään väärin, sitä on liian vähän tai sen käyttöä ei nähdä ajoissa.
Perinteisessä PHP-FPM-mallissa jokainen HTTP-pyyntö on erillinen suoritus. PHP-prosessi käynnistyy, varaa muistia, suorittaa koodin ja vapauttaa muistin pyynnön lopuksi. Tämä tarkoittaa kahta tärkeää asiaa:...
WordPressissä on kaksi keskeistä muistivakiota:...
Suurin yksittäinen muistin kuluttaja WordPressissä ei ole core, vaan lisäosat ja teemat. Jokainen lisäosa:...
PHP-FPM käyttää prosessipoolia. Jokainen prosessi voi käyttää memory_limitin verran muistia. Kokonaismuistinkulutus on siis:...
Muistiongelmat eivät aina näy suoraan “Allowed memory size exhausted” -virheenä. Muita oireita ovat:...
Ensimmäinen reaktio on usein nostaa memory_limitiä. Tämä voi auttaa, mutta se ei ratkaise juurisyytä....
Object cache siirtää osan kuormasta PHP:stä ulkoiseen muistivarastoon, kuten Redikseen. Tämä vähentää PHP-prosessin muistikuormaa, mutta ei poista tarvetta hyvälle muistin hallinnalle....
Muistin hallinta on onnistunut, kun:...
PHP-muisti ei ole asia, jota “käytetään niin paljon kuin mahdollista”. Se on raja, jonka sisällä järjestelmän täytyy toimia luotettavasti....
WordPress ei “vuoda muistia” itsessään. Se käyttää PHP:tä, ja PHP käyttää muistia juuri niin kuin koodi käskee. Kun ymmärtää, miten PHP hallitsee muistia ja miten WordPress sitä kuluttaa, monet mystiset ongelmat muuttuvat ennustettaviksi ja hallittaviksi.
Miten PHP käyttää muistia
PHP ei ole jatkuva prosessi
Perinteisessä PHP-FPM-mallissa jokainen HTTP-pyyntö on erillinen suoritus. PHP-prosessi käynnistyy, varaa muistia, suorittaa koodin ja vapauttaa muistin pyynnön lopuksi. Tämä tarkoittaa kahta tärkeää asiaa:
Ensinnäkin muistivuodot eivät ole samanlaisia kuin pitkäkestoisissa sovelluksissa. Jos muisti vapautuu pyynnön lopussa, ongelma ei kerry loputtomasti, mutta se voi silti kaataa yksittäisen pyynnön.
Toiseksi yksittäinen pyyntö voi epäonnistua, vaikka palvelimella olisi runsaasti vapaata muistia, jos PHP:n muistiraja tulee vastaan.
memory_limit on kova raja
PHP:n memory_limit määrittää, kuinka paljon muistia yksi PHP-prosessi saa käyttää. Kun raja ylittyy, PHP tappaa suorituksen välittömästi.
Tämä on tarkoituksellista. memory_limit suojaa palvelinta tilanteelta, jossa yksi huonosti käyttäytyvä pyyntö söisi kaiken muistin.
WordPress ei voi ohittaa tätä rajaa, se voi vain pyytää suurempaa arvoa.
WordPressin omat muistiasetukset
WP_MEMORY_LIMIT ja WP_MAX_MEMORY_LIMIT
WordPressissä on kaksi keskeistä muistivakiota:
WP_MEMORY_LIMIT määrittää paljonko muistia WordPress pyytää frontend-pyynnöille.
WP_MAX_MEMORY_LIMIT koskee admin-puolta ja raskaampia operaatioita, kuten lisäosien päivityksiä.
Nämä eivät ole absoluuttisia arvoja. Ne eivät voi ylittää PHP:n memory_limit-arvoa. Jos PHP sallii vain 128 MB, WordPress ei saa käyttöönsä enempää, vaikka WP_MAX_MEMORY_LIMIT olisi suurempi.
Yleinen väärinkäsitys
Moni olettaa, että WP_MEMORY_LIMIT “asettaa” muistin määrän. Todellisuudessa se on pyyntö, ei käsky. Lopullinen päätös on aina PHP:n.
Missä WordPress käyttää muistia
Lisäosat ja teemat
Suurin yksittäinen muistin kuluttaja WordPressissä ei ole core, vaan lisäosat ja teemat. Jokainen lisäosa:
-
lataa PHP-tiedostoja
-
rekisteröi hookeja
-
varaa muistia objekteille ja taulukoille
Huonosti kirjoitettu lisäosa voi käyttää kymmeniä megatavuja muistia jo pelkästään latautuessaan.
Suuret kyselyt ja datarakenteet
WordPressin kyselyrajapinnat palauttavat usein kokonaisia PHP-objekteja. Jos kysely palauttaa tuhansia postauksia tai suuria meta-kenttiä, muistin käyttö kasvaa nopeasti.
Tämä korostuu admin-puolella ja massatoiminnoissa.
Gutenberg ja REST API
Moderni WordPress käyttää paljon JSON-dataa ja REST API -kutsuja. Suuret JSON-rakenteet syövät muistia sekä PHP:ssä että selaimessa.
Editorin hitaus on usein seurausta muistipaineesta, ei pelkästä JavaScript-ongelmasta.
PHP-FPM ja muistin kokonaiskuva
Yksi prosessi, monta prosessia
PHP-FPM käyttää prosessipoolia. Jokainen prosessi voi käyttää memory_limitin verran muistia. Kokonaismuistinkulutus on siis:
PHP-prosessien määrä × memory_limit
Tämä on kriittinen ymmärtää. 20 prosessia × 256 MB tarkoittaa teoriassa 5 GB muistia.
Oikea tasapaino
Liian suuri memory_limit yhdistettynä liian moneen PHP-prosessiin kaataa palvelimen. Liian pieni memory_limit kaataa yksittäiset pyynnöt.
WordPress-ympäristössä muistin hallinta on aina tasapainottelua rinnakkaisuuden ja yksittäisen pyynnön tarpeen välillä.
Oireet muistiongelmista
Fatal error ei ole ainoa merkki
Muistiongelmat eivät aina näy suoraan “Allowed memory size exhausted” -virheenä. Muita oireita ovat:
-
satunnaiset 500-virheet
-
admin-näkymien kaatuminen
-
hitaat tai epäonnistuvat päivitykset
-
REST API -virheet
Ilman lokitusta nämä näyttävät satunnaisilta ongelmilta.
Muisti ja suorituskyky
Muistipaine ei aina kaada sivustoa, mutta se hidastaa sitä. Kun PHP joutuu jatkuvasti lähelle memory_limitiä, se tekee enemmän työtä allokoidakseen ja vapauttaakseen muistia.
Tämä näkyy vasteajoissa.
Miten muistin käyttöä kannattaa hallita
Lisää muistia vain perustellusti
Ensimmäinen reaktio on usein nostaa memory_limitiä. Tämä voi auttaa, mutta se ei ratkaise juurisyytä.
Jos yksi lisäosa vaatii 512 MB muistia toimiakseen, ongelma ei ole muistin määrä vaan lisäosan rakenne.
Mittaa ennen kuin muutat
Muistin käyttöä voi mitata:
-
PHP:n sisäisillä funktioilla
-
debug-työkaluilla
-
palvelintason mittareilla
Ilman mittaamista muistin säätäminen on sokkona ampumista.
Karsi ja optimoi
Usein paras muistisäästö saadaan:
-
poistamalla tarpeettomat lisäosat
-
vähentämällä massiivisia kyselyitä
-
siirtämällä raskaita operaatioita taustaprosesseihin
Muisti on rajallinen resurssi. Sen säästäminen on arkkitehtuurinen päätös.
Object cache ja muisti
Object cache siirtää osan kuormasta PHP:stä ulkoiseen muistivarastoon, kuten Redikseen. Tämä vähentää PHP-prosessin muistikuormaa, mutta ei poista tarvetta hyvälle muistin hallinnalle.
Object cache voi myös lisätä kokonaismuistin tarvetta palvelimella, joten sitä ei pidä ottaa käyttöön ilman kokonaiskuvaa.
Milloin muisti on kunnossa
Muistin hallinta on onnistunut, kun:
-
yksittäiset pyynnöt eivät osu memory_limitiin
-
PHP-prosessit eivät syö koko palvelimen muistia
-
admin toimii luotettavasti
-
suorituskyky on tasainen myös kuormassa
Muisti ei saa olla näkymätön ongelma, mutta sen ei myöskään pidä olla jatkuva huolenaihe.
Lopuksi: muisti on raja, ei tavoite
PHP-muisti ei ole asia, jota “käytetään niin paljon kuin mahdollista”. Se on raja, jonka sisällä järjestelmän täytyy toimia luotettavasti.
WordPressissä hyvä muistin hallinta syntyy ymmärryksestä, ei pelkästä konfiguraatiosta. Kun muisti mitoitetaan oikein ja koodi käyttää sitä järkevästi, WordPress muuttuu vakaaksi, ennustettavaksi ja helpoksi ylläpitää.
