OPcache és PHP memórialimit beállítása WordPresshez

Scheo · 2026-10-26 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha egy WordPress-oldal néha gyors, máskor pedig indokolatlanul lomha, a háttérben gyakran a PHP futtatási környezete áll, és nem a sablon vagy a bővítmények. Ebben a cikkben három beállítást nézünk meg közelebbről. Az OPcache a lefordított PHP-kódot tartja memóriában, a memóriakorlát azt szabja meg, mennyi RAM-ot használhat egy kérés, a futásidő-korlát pedig azt, meddig dolgozhat. Mindhármat érdemes ismerned, mielőtt újabb gyorsító bővítményt telepítesz.

A szövegben jelöljük, mi számít hivatalosan igazolt információnak (PHP- és WordPress-dokumentáció), mi a saját tapasztalatunk és mi szakmai feltételezés.

Mit csinál az OPcache egy WordPress-oldalon?

Az OPcache a PHP-fájlokból fordított bájtkódot osztott memóriában tárolja, így a szervernek nem kell minden kérésnél újra beolvasnia és lefordítania ugyanazt a kódot.

Egy WordPress-oldal betöltésekor a PHP több száz fájlt húz be, a magot, a sablont és minden aktív bővítményt. OPcache nélkül minden egyes látogatásnál beolvassa, elemzi és bájtkóddá alakítja ezeket. Bekapcsolt OPcache mellett ez egyszer történik meg, utána a kész bájtkód a memóriából fut.

Hivatalosan igazolt: a PHP kézikönyve szerint az OPcache a PHP 5.5 óta a PHP része, és a lefordított szkriptek osztott memóriában tárolásával javítja a teljesítményt. Fontos különbség, hogy az OPcache a PHP-kódot gyorsítja. A kész HTML-oldalt nem tárolja, ez az oldal-gyorsítótár (page cache) dolga, az adatbázis-lekérdezések eredményét pedig az objektum-gyorsítótár kezeli. A három réteg kiegészíti egymást.

Hogyan ellenőrizheted, hogy be van-e kapcsolva az OPcache?

A legmegbízhatóbb a phpinfo() kimenetében a Zend OPcache szakasz, ahol az „Opcode Caching” sornak „Up and Running” értéket kell mutatnia.

Lépésről lépésre így néz ki.

1. Hozz létre a webgyökérben egy véletlenszerű nevű fájlt, például info-x7k2.php néven.
2. A tartalma egyetlen sor legyen: <?php phpinfo();
3. Nyisd meg böngészőben, és keress rá a „Zend OPcache” részre.
4. Nézd meg az opcache.enable, az opcache.memory_consumption és az opcache.max_accelerated_files értékét.
5. Utána azonnal töröld a fájlt. A phpinfo sok belső adatot mutat a szerverről, ezt nem jó nyilvánosan hagyni.

Ha a Zend OPcache szakasz hiányzik, a bővítmény nincs betöltve. Ha ott van, de az opcache.enable értéke Off, be van töltve, csak ki van kapcsolva. Mindkét esetben a szolgáltatóhoz kell fordulnod, ennek okát lejjebb leírjuk.

Saját tapasztalat: sok tárhelyszolgáltató panelén (cPanel, DirectAdmin, ISPmanager) a PHP-verzió kiválasztó felületén bővítményként is látszik az OPcache, de a pipa megléte önmagában nem bizonyítja, hogy a te oldaladon működik is. A phpinfo kimenete a döntő.

Honnan tudod, hogy elég-e az OPcache memóriája?

Az opcache_get_status() függvény megmutatja a szabad és a pazarolt memóriát, a gyorsítótárazott fájlok számát és az újraindítások számát. Ha a szabad memória a nullához közelít, vagy az oom_restarts értéke nő, kevés a memória.

Egy rövid, ideiglenes ellenőrző szkript (ezt is töröld használat után):

<?php $s = opcache_get_status(false); print_r($s['memory_usage']); print_r($s['opcache_statistics']);

A kimenetben ezekre figyelj.

• free_memory és used_memory, vagyis mennyi van még a lefoglalt területből.
• wasted_memory és current_wasted_percentage, azaz a módosított vagy elavult fájlok által foglalt, de már nem használt rész.
• num_cached_scripts és max_cached_keys. Ha az előbbi közel jár az utóbbihoz, a fájlszám-korlát telt be.
• oom_restarts és hash_restarts. Ezek a memória, illetve a kulcsok elfogyása miatti újraindításokat számolják.
• opcache_hit_rate, a találati arány. Egy jól beállított, stabil oldalon ez jellemzően nagyon magas.

Hivatalosan igazolt: a PHP kézikönyve szerint az opcache.memory_consumption alapértéke 128 MB, az opcache.max_accelerated_files alapértéke 10 000 (a PHP ezt a következő, általa használt prímszámra kerekíti fel), az opcache.interned_strings_buffer alapértéke 8 MB.

Szakmai feltételezés: egy átlagos WordPress-oldalnak a 128 MB többnyire elég, de egy sok bővítményes webshop, több oldal egy szerveren vagy egy oldalépítő bővítmény könnyen megnöveli a fájlszámot. Ilyenkor gyakran a fájlszám-korlát telik be előbb, és nem a memória.

Saját tapasztalat: osztott tárhelyen előfordul, hogy az opcache_get_status() le van tiltva (az opcache.restrict_api beállítással), vagy a kimenet több ügyfél fájljait is tartalmazza, mert az OPcache közös egy PHP-készleten belül. Ilyenkor a számokat óvatosan kell értelmezni, és a szolgáltatótól érdemes kérni a pontos adatot.

Miért lassul le az oldal, ha betelik az OPcache?

Ha a memória vagy a fájlszám-keret betelik, az OPcache nem tud új fájlt felvenni, ezért azokat minden kérésnél újra kell fordítani. Ha közben sok a pazarolt memória, a PHP a teljes gyorsítótárat üríti és újraépíti, ami átmeneti lassulást okoz.

Hivatalosan igazolt: a PHP kézikönyve szerint amikor az osztott memória elfogy, és a pazarolt rész aránya eléri az opcache.max_wasted_percentage értékét, az OPcache újraindítást ütemez. Ha a pazarolt arány ennél kisebb, a gyorsítótár egyszerűen nem fogad új szkriptet.

A gyakorlatban két tünet jelentkezhet.

• Tartós, egyenletes lassúság. A gyorsítótár tele van, az újonnan betöltött fájlok (például egy frissen aktivált bővítmény kódja) nem kerülnek be, minden kérés újrafordítja őket.
• Időszakos megugrások. A gyorsítótár rendszeresen kiürül és újratöltődik. Az ürítés utáni első kérések lassabbak, a válaszidő grafikonján fogazott mintázat látszik.

Saját tapasztalat: a pazarolt memória gyakran a sűrű frissítésekből jön. Minden bővítmény- vagy sablonfrissítés után a régi bájtkód a memóriában marad, csak már nem érvényes. Egy aktívan fejlesztett oldalon ez gyorsabban gyűlik, mint egy ritkán változón.

Mi a különbség a memory_limit és a WP_MEMORY_LIMIT között?

A memory_limit a PHP saját korlátja, amely egyetlen kérés legnagyobb memóriahasználatát szabja meg. A WP_MEMORY_LIMIT egy WordPress-állandó, amellyel a WordPress megpróbálja ezt az értéket megemelni, de csak addig, ameddig a szerver engedi.

Ez a két beállítás független az OPcache memóriájától. Az OPcache egy közös, osztott terület, a memory_limit pedig kérésenként érvényes.

Hivatalosan igazolt: a WordPress fejlesztői dokumentációja szerint a WP_MEMORY_LIMIT alapértéke egyedi oldalon 40 MB, multisite esetén 64 MB. Az adminfelületen a WP_MAX_MEMORY_LIMIT érvényes, ennek alapértéke 256 MB. A WordPress csak akkor módosít, ha az állandó értéke nagyobb a PHP aktuális korlátjánál, lejjebb nem viszi.

A wp-config.php fájlban, a „That's all, stop editing” sor fölé írva így néz ki:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Ha a szolgáltató a PHP oldalon 128 MB-ban rögzítette a korlátot, és letiltotta a módosítást, a fenti sor hatástalan marad. Ezért fordul elő, hogy valaki beírja, és a hibaüzenet változatlanul megjelenik.

Szakmai feltételezés: a memóriakorlát emelése tüneti kezelés. Ha egy oldal rendszeresen kifut a 256 MB-ból, érdemes megnézni, melyik bővítmény vagy lekérdezés eszik ennyit, mert a magasabb korlát a terhelést csak elodázza.

Mire való a max_execution_time, és mikor érdemes hozzányúlni?

A max_execution_time megszabja, hány másodpercig futhat egy PHP-szkript, mielőtt a PHP leállítja. Alapértéke 30 másodperc, parancssorból futtatva nincs korlát.

Hosszabb időre jellemzően importnál, nagy mentésnél, képátméretezésnél vagy webshop-termékek tömeges frissítésénél van szükség. Hétköznapi oldalbetöltésnél egy kérésnek messze a korláton belül kell maradnia. Ha egy normál oldal közelít a 30 másodperchez, az hibát jelez, és ezt a korlát emelése nem javítja.

Hivatalosan igazolt: a PHP kézikönyve szerint a korlát a szkript saját futási idejére vonatkozik. Linuxon a rendszerhívásokra és adatbázis-lekérdezésekre várakozás ebbe nem számít bele.

Saját tapasztalat: a PHP-korláton kívül a webszervernek és a PHP-FPM-nek is van saját időkorlátja (proxy- és FastCGI-timeout, request_terminate_timeout). Ha ezek rövidebbek, hiába emeled a max_execution_time értékét, a kérés 504-es vagy 502-es hibával megszakad. Ezeket osztott tárhelyen csak a szolgáltató látja és állítja.

Mit állíthatsz be magad osztott tárhelyen, és mit csak a szolgáltató?

A memory_limit és a max_execution_time sok osztott tárhelyen saját kézből is állítható. Az OPcache memóriáját és fájlszám-keretét viszont csak a szolgáltató tudja módosítani, mert ezek a szerver szintjén érvényesek.

Hivatalosan igazolt: a PHP kézikönyve szerint az opcache.memory_consumption, az opcache.max_accelerated_files és az opcache.interned_strings_buffer PHP_INI_SYSTEM típusú beállítás, vagyis csak a php.ini-ben vagy a szerver konfigurációjában adható meg. Az opcache.enable futás közben kikapcsolható, bekapcsolni viszont így nem lehet.

Amit általában magad is megpróbálhatsz, a tárhely típusától függően:

• Tárhelypanel PHP-beállításai (például cPanelben a MultiPHP INI Editor vagy a „Select PHP Version” felület), ez a legtisztább út.
• .user.ini fájl a webgyökérben, PHP-FPM vagy CGI futtatásnál, például memory_limit = 256M és max_execution_time = 120 sorokkal. A változás a user_ini.cache_ttl miatt akár néhány perc múlva lép életbe.
• .htaccess fájl php_value sorokkal, de csak akkor, ha a PHP Apache-modulként fut. Más futtatási módnál ez 500-as hibát okozhat, ezért mentsd el előtte az eredeti fájlt.
• wp-config.php a WP_MEMORY_LIMIT állandóval, a fent leírt korláttal.

Amit csak a szolgáltató tud: az OPcache be- és kikapcsolása szerverszinten, a memóriája, a fájlszám-kerete, a validate_timestamps és a revalidate_freq értéke, a webszerver és a PHP-FPM időkorlátjai, valamint a tárhelycsomag felső memóriaplafonja.

Milyen sorrendben érdemes diagnosztizálni?

Kezdd a WordPress Webhely állapota oldalával, folytasd a phpinfo kimenetével, és zárd a hibanapló átnézésével. Ez a sorrend a legkisebb beavatkozással adja a legtöbb információt.

1. Webhely állapota (Site Health). Az adminban az Eszközök › Webhely állapota › Információ fülön a „Szerver” szakasz mutatja a PHP memóriakorlátot és az időkorlátot, a „WordPress állandók” szakasz pedig a WP_MEMORY_LIMIT és a WP_MAX_MEMORY_LIMIT tényleges értékét. Ha a kettő eltér attól, amit beírtál, a szerver felülírja.
2. phpinfo. Itt látod az OPcache állapotát, a memory_limit helyi és fő értékét (Local Value, Master Value), valamint azt, melyik php.ini fájl töltődik be. Utána töröld a fájlt.
3. OPcache-státusz. Ha engedélyezett, az opcache_get_status() kimenetéből derül ki, betelt-e a memória vagy a fájlszám-keret.
4. Hibanapló. A tárhely PHP-hibanaplójában vagy a WordPress wp-content/debug.log fájljában keresd az „Allowed memory size of … bytes exhausted” és a „Maximum execution time of … seconds exceeded” sorokat. A WordPress-naplót a WP_DEBUG és a WP_DEBUG_LOG állandóval kapcsolhatod be, élő oldalon a WP_DEBUG_DISPLAY legyen false.
5. Időbeli összevetés. Ha a lassulás frissítések után vagy napszakhoz kötve jelentkezik, jegyezd fel, mikor. A szolgáltatónak ez sokat segít.

Saját tapasztalat: a hibanapló üzenetéből gyakran az is kiderül, melyik bővítmény fájljában fogyott el a memória. Ez nem feltétlenül a bűnös, de jó kiindulópont.

Mit kérdezz a tárhelyszolgáltatótól?

Kérdezz rá konkrétan az OPcache állapotára és keretére, a PHP-korlátok felső határára és arra, hogy ezekből mit módosíthatsz magad. Minél pontosabb a kérdés, annál valószínűbb, hogy érdemi választ kapsz, és nem általános ajánlást.

• Be van kapcsolva az OPcache a tárhelyemen, és a saját fájljaim kapnak külön gyorsítótárat, vagy közös a terület más felhasználókkal?
• Mekkora az opcache.memory_consumption és az opcache.max_accelerated_files értéke, és mennyi ebből a szabad rész?
• Látjátok a naplóban, hogy az OPcache memóriahiány miatt újraindult az utóbbi időben?
• Mi a memory_limit legnagyobb értéke, amit a csomagom enged, és melyik módon állíthatom (panel, .user.ini, .htaccess)?
• Mekkora a webszerver és a PHP-FPM időkorlátja, és ez magasabb-e, mint a max_execution_time?
• Be van kapcsolva a validate_timestamps, és milyen gyakran ellenőrzi a rendszer a fájlok változását?
• Hol érem el a PHP-hibanaplót, és engedélyezett az opcache_get_status() függvény?
• Ha a jelenlegi csomag kereteit kinövöm, milyen lehetőség van nagyobb OPcache-memóriára?

Szakmai feltételezés: a jól beállított OPcache és a megfelelő memóriakorlát jó eséllyel stabilabb válaszidőt ad, de önmagában nem garantál gyorsabb oldalt vagy jobb keresőhelyezést. Ha a lassulás oka a lassú adatbázis-lekérdezés, a túlterhelt admin-ajax vagy a robotforgalom, azt külön kell kezelni.

Források és további olvasnivalók

• PHP Manual: OPcache, Installing/Configuring és Runtime Configuration
• PHP Manual: opcache_get_status() függvény
• PHP Manual: Description of core php.ini directives (memory_limit, max_execution_time)
• PHP Manual: .user.ini files
• WordPress Developer Resources: Editing wp-config.php
• WordPress Advanced Administration Handbook: Debugging in WordPress
• WordPress.org dokumentáció: Site Health screen