„Allowed memory size exhausted” hiba WordPressben: így találd meg az okát

Az Allowed memory size of ... bytes exhausted üzenet azt jelenti, hogy egy PHP-kérés elérte a számára engedélyezett memóriahatárt. Ez nem a tárhely szabad lemezterülete, és nem feltétlenül a szerver teljes fizikai memóriája. A jó javítási sorrend: azonosítsd a hibát kiváltó műveletet, nézd meg a tényleges limitet és a naplót, különítsd el a problémás komponenst, majd csak akkor emelj korlátot, ha a művelet jogos memóriaigénye indokolja.

Mit mond el pontosan a hibaüzenet?

Egy tipikus sor így néz ki:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
  (tried to allocate 2097152 bytes) in /.../plugin.php on line 123

Az első szám a folyamat határa, a második az a további mennyiség, amelyet a PHP már nem tudott lefoglalni. A példában 134 217 728 bájt 128 MiB, a kért 2 097 152 bájt pedig 2 MiB. Gyors átváltáshoz oszd a bájtértéket kétszer 1024-gyel. A fájl és a sorszám azt mutatja, hol bukott el a foglalás, de nem bizonyítja, hogy ott kezdődött a túlzott fogyasztás. Lehet, hogy a kérés addigra már más kód miatt majdnem minden memóriát felhasznált.

1. Rögzítsd, mikor és hol jelentkezik

Próbáld pontosan leírni a kiváltó műveletet: minden oldalbetöltéskor történik, csak egy nagy kép feltöltésekor, importnál, biztonsági ellenőrzésnél, mentésnél vagy egyetlen szerkesztőoldalon? Ha kizárólag egy feladatnál jelenik meg, az sokkal hasznosabb nyom, mint maga a fájlnév.

Nézd meg az Eszközök > Webhely-egészség > Információk > Kiszolgáló alatt jelzett PHP-memóriahatárt. Ha van tárhelyi PHP-információ vagy kezelőpanel, hasonlítsd össze vele. Előfordulhat, hogy a wp-config.php nagyobb értéket kér, mint amit a tárhely PHP-beállítása ténylegesen enged; a kisebb felső korlát ilyenkor nem léphető át.

2. Készíts használható, de nem nyilvános naplót

Előbb legyen friss mentés; ehhez kövesd a WordPress biztonsági mentési útmutatót. Még a hibakeresés bekapcsolása előtt gondoskodj védett naplóhelyről. A legjobb a tárhely kezelőfelületén elérhető, eleve nem nyilvános PHP-hibanapló. Ha külön WordPress-napló kell, hozz létre a webrooton — például a public_html könyvtáron — kívül egy csak a PHP-folyamat számára írható könyvtárat, és annak teljes szerverútvonalát add meg. A következő útvonal csak minta, nem másolandó szó szerint:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/teljes/szerverut/webrooton-kivul/wordpress-debug.log' );
  define( 'WP_DEBUG_DISPLAY', false );
  @ini_set( 'display_errors', 0 );

A sorok a wp-config.php fájlban a „That’s all, stop editing” megjegyzés elé kerüljenek. Az abszolút útvonalat a tárhely dokumentációjából vagy ügyfélszolgálatától kérd el; bekapcsolás előtt ellenőrizd, hogy a könyvtár nem érhető el HTTP-n, és a PHP tud bele írni. Ha ezt nem tudod biztonsággal megoldani, ne használd a WP_DEBUG_LOG=true alapértéket az éles oldalon, mert az rendszerint a wp-content/debug.log fájlba ír; maradj a szolgáltató zárt PHP-hibanaplójánál. Ezután idézd elő egyszer a hibát, jegyezd fel az időpontot, és nézd meg a védett WordPress-napló, valamint a tárhely PHP-hibanaplójának ugyanakkori sorait. Az éles oldalon ne hagyd szükségtelenül bekapcsolva a hibakeresést, mert a napló elérési utakat és más érzékeny részleteket tartalmazhat.

Ha a hiba csak fehér oldalként látszik, a WordPress fehér képernyő útmutatója segít a hozzáférés visszaszerzésében. Ha a böngésző 500-as állapotot kap, használd a WordPress 500-as hiba elkülönítési sorrendjét is.

3. Különítsd el a memóriafogyasztó komponenst

Tesztoldalon kapcsold ki először azt a bővítményt, amelynek futásakor a hiba megjelenik. Ha nem egyértelmű, kapcsold ki az összes bővítményt, válts alapértelmezett sablonra, majd ismételd meg a hibát kiváltó műveletet. Ezután egyenként állítsd vissza a komponenseket. A részletes, biztonságos módszert a bővítmény- és sablonütközések hibakeresése mutatja be.

A következő minták különösen beszédesek:

  • ha a limit minden emelése után újra betelik, valószínű lehet végtelen ciklus, túl nagy lekérdezés vagy memória-szivárgás;
  • ha csak importnál vagy képfeldolgozásnál fogy el, a bemenet mérete és a feladat darabolhatósága fontos;
  • ha ugyanaz a bővítmény kikapcsolva megszünteti a hibát, nézd meg a frissítéseit és a gyártó ismert hibáit;
  • ha véletlenszerűen több, egymástól független feladat bukik el, a tárhely teljes erőforráskorlátját és rendszerfolyamatait is a szolgáltatónak kell vizsgálnia.

4. Mikor indokolt a memóriahatár emelése?

A PHP memory_limit direktívája egy futó PHP-kérés által lefoglalható memória felső határa. A WordPress ezen belül használja a WP_MEMORY_LIMIT, az adminisztratív feladatokhoz pedig a WP_MAX_MEMORY_LIMIT értéket. A wp-config.php fájlban például ilyen kérés adható meg:

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

Ez csak akkor hatásos, ha a tárhely PHP-konfigurációja és a szolgáltatói csomag is megengedi. Ne válassz automatikusan 512 vagy 1024 MiB-ot. Ha egy átlagos oldalbetöltés csak rendellenesen magas limittel működik, a korlát emelése elfedi az okot, több párhuzamos kérés pedig kifogyaszthatja a szervert a memóriából.

Az emelés akkor lehet indokolt, ha a jelenlegi érték feltűnően alacsony, a feladat jogosan erőforrás-igényes, a bővítmény dokumentált követelménye magasabb, és teszteléssel látszik, hogy a fogyasztás véges. Importnál jobb lehet kisebb csomagokra bontani a munkát; nagy képnél a feltöltés előtti átméretezés; biztonsági vizsgálatnál a bővítmény alacsony erőforrású módja.

Ellenőrzés a javítás után

  1. Futtasd le legalább kétszer ugyanazt a műveletet ugyanazzal a bemenettel.
  2. Nézd meg a WordPress- és szervernaplót új memóriahiba után.
  3. Ellenőrizd, nem keletkezett-e félbehagyott import, duplikált tartalom vagy sérült média.
  4. Kapcsold ki a felesleges hibakeresést, és töröld vagy védd a naplófájlt.
  5. Írd fel a végleges limitet és a valódi okot, ne csak azt, hogy „memória emelve”.

Figyeld azt is, hogy a hiba nem tolódott-e át más műveletre. Ha a korábbi kérés már lefut, de közben a szerver válaszideje jelentősen nő, háttérfeladatok maradnak el vagy a tárhely erőforráskorlátot jelez, a nagyobb PHP-limit csak átrendezte a problémát. Hasonlíts össze azonos műveletből származó naplót és erőforrás-adatot a módosítás előtt és után.

Mikor kérj segítséget?

A tárhelyszolgáltató vizsgálata kell, ha a beállított érték nem lép életbe, nincs hozzáférésed a szervernaplóhoz, a hibák véletlenszerűek, vagy a teljes fiók erőforráskorlátba ütközik. Fejlesztőre van szükség, ha egyedi kód, ismétlődő adatbázis-lekérdezés vagy minden limitemelést kitöltő folyamat látszik. Ilyenkor a további emelés helyett profilozás és kódjavítás a következő lépés.

Felhasznált források

Kapcsolódó útmutatók

Scroll to Top