Tárhely-erőforráskorlátok olvasása: mit jelent a CPU-, memória- és belépési korlát

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

A tárhelycsomag adatlapján a CPU-mag, a memória és az egyidejű belépések száma három ártatlan számnak látszik. A gyakorlatban ez a három szám dönti el, hogy a hírlevél kiküldése utáni tíz percben a látogató megnyitja-e az ajánlatot, vagy fehér hibaoldalt lát. Lefordítom ezeket a korlátokat arra, ami a böngészőben és az adminban látszik, és megadom azt a lépéssort, amivel kiderítheted, mi meríti ki őket.

Mit jelent a gyakorlatban a CPU-, a memória- és a belépési korlát?

Röviden, a CPU-korlát azt szabja meg, mennyi számítási időt kaphat az oldalad, a memóriakorlát azt, mennyi futó folyamat férhet el egyszerre, a belépési korlát pedig azt, hány PHP-kérés dolgozhat párhuzamosan. A három közül a belépési korlát üt be leghamarabb, és ezt értik a legkevesebben pontosan.

Hivatalosan igazolt. A magyar osztott tárhelyek nagy része CloudLinux alapú, ahol minden felhasználó saját erőforrás-konténert (LVE) kap. A gyártói dokumentáció szerint a SPEED a CPU-időt maghányadban vagy százalékban adja meg, a PMEM a fizikai memóriát, az EP (entry processes) az egyidejűleg belépő kéréseket, az NPROC a futó folyamatok darabszámát, az IO és az IOPS pedig a lemezes írás-olvasás sávszélességét és műveletszámát. A 100 százalékos CPU itt egyetlen magot jelent teljes kihasználáson, nem a szerver egészét.

A belépési korlát félreértése a leggyakoribb hiba. Az EP a PHP-ben éppen dolgozó kéréseket számolja. Ha egy oldalletöltés 200 milliszekundum alatt lefut, egyetlen belépési hely másodpercenként öt kérést szolgál ki. Ha ugyanaz az oldal négy másodpercig dolgozik egy lassú adatbázis-lekérdezés miatt, ugyanaz az egy hely már csak negyed kérést visz el másodpercenként. Ezért fut korlátba a napi pár száz látogató is, miközben egy másik oldal ötezret elvisz ugyanazon a csomagon.

Mikor kap a látogató 508-as, és mikor 503-as hibát?

A tömör válasz az, hogy az 508-as az erőforrás-konténer korlátjából jön, az 503-as pedig a webkiszolgáló vagy a PHP-feldolgozó kapacitásából. A hibakód megmondja, melyik korlátot kell megnézned először.

• 508 Resource Limit Is Reached, a CPU-, memória-, belépési vagy folyamatszám-korlát telített. Ez a kód a CloudLinux és cPanel környezet sajátja, a HTTP-szabvány nem tartalmazza. Ha ezt látod, a panel statisztikájában ott lesz a hozzá tartozó hibaszámláló.
• 503 Service Unavailable, a PHP-FPM pool minden gyerekfolyamata foglalt, vagy a kiszolgáló várólistája megtelt. Gyakran ugyanaz az ok áll mögötte, csak más réteg fogja meg.
• 500 Internal Server Error fatális PHP-hibával, tipikusan a memory_limit kimerülésekor, importálás vagy képgenerálás közben.
• 504 Gateway Timeout, a kérés futott, de nem fejezte be a megengedett idő alatt. Ez lassú lekérdezésre vagy külső API-ra váró kódra utal.
• Válasz nélküli, megszakadó kapcsolat, az I/O-fojtás alatt a folyamatok nem halnak meg, csak megállnak. Ez a legnehezebben azonosítható eset.

Saját tapasztalat. Az 508-as hiba szinte soha nem egyenletes. Jellemzően két-három perces sávokban jön, aztán magától elmúlik, ezért az ügyfél jelzése és a te ellenőrzésed közé fél óra kerül, és addigra minden működik. Emiatt a hibát visszamenőleg érdemes keresni a naplóból, élőben ritkán kapod el.

Miért lassul be csak a WordPress admin, miközben a nyitóoldal gyors?

Azért, mert a nyilvános oldalt gyorsítótár szolgálja ki, az adminfelületet pedig soha. Ha a látogatók statikus HTML-t kapnak, a maradék erőforrás-korlátot teljes egészében az admin, a kosár, a bejelentkezés és a háttérfolyamatok terhelik.

Az adminban három dolgot érdemes megnézni. Az első az autoload méret, mert azt minden kérés betölti a memóriába. Adatbázisban így kérdezed le.

SELECT SUM(LENGTH(option_value)) AS autoload_byte, COUNT(*) FROM wp_options WHERE autoload = 'yes';

WP-CLI-vel a legnagyobb tételek is kilistázhatók.

wp option list --autoload=on --fields=option_name,size_bytes --orderby=size_bytes --order=desc | head -20

Egy megabájt fölötti autoload már érezhető, több megabájt fölött az admin minden kattintása lassú. Szakmai feltételezés, hogy az esetek nagy részében az autoload duzzadását régen letiltott bővítmények ottmaradt átmeneti adatai okozzák, és csak kisebb részben a tartalom mennyisége.

A második az admin-ajax.php forgalma. A WordPress heartbeat API alapértelmezésben néhány tíz másodpercenként kérdezi meg a szervert a szerkesztőben, és ritkábban a többi adminoldalon. Ha három ember dolgozik egyszerre, és mellette egy bővítmény is figyel, a belépési korlátból folyamatosan lefoglalódik néhány hely. A harmadik a gyorsítótárazatlan lekérdezés a nyitóoldalon. Egy kapcsolódó termékek vagy népszerű bejegyzések blokk véletlen sorrendű lekérdezéssel önmagában képes megenni a CPU-korlát felét.

Hogyan azonosítod a napi terhelési csúcsot a tárhelypanel statisztikáiból?

A panel erőforrás-grafikonja akkor lesz használható, ha nem a csúcs magasságát, hanem a csúcs időpontját keresed benne. Ez a lépéssor egy óra alatt elvégezhető, és nem kér semmilyen hozzáférést a tárhelyen kívül.

1. Nyisd meg a panel erőforrás-használat oldalát (cPanelben a Resource Usage, ispmanagerben a felhasználó erőforrás-statisztikája), és állítsd a nézetet 7, majd 30 napra.
2. Írd fel, melyik korlát mennyi hibát kapott. A CPU, EP, NPROC, IO és IOPS külön számlálón fut, és általában csak az egyik telik meg.
3. Nagyítsd rá a legutolsó hibás napra, és olvasd le a csúcs óráját, ha lehet, percét. Perc-bontású pillanatképet a támogatástól is kérhetsz.
4. Tedd mellé a GA4 óránkénti forgalmi grafikonját ugyanarra a napra. Ha a látogatói csúcs 19 órakor van, az erőforrás-csúcs pedig hajnali 3-kor, a látogatókat kizárhatod.
5. Nézd meg, ismétlődik-e a csúcs ugyanabban a percben naponta vagy óránként. Az ismétlődő minta gépi ütemezésre utal, az egyenetlen emberi forgalomra vagy robotra.
6. Ellenőrizd, egybeesik-e a csúcs a mentés, a terméklista-szinkron vagy a vírusellenőrzés beállított idejével. A nyomozás itt szokott véget érni.

Mit mutat meg a naplófájl, amit a grafikon nem?

A grafikon azt mondja meg, mikor volt a csúcs, a hozzáférési napló azt, mi futott benne. Ez a különbség dönti el, optimalizálni kell-e vagy erőforrást bővíteni.

SSH-val a percenkénti kérésszám egy sorból kijön.

awk '{print $4}' access.log | cut -d: -f2,3 | sort | uniq -c | sort -rn | head -20

A leggyakrabban hívott útvonalak és a robotok azonosítása két további sor.

awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20

grep -oE 'GPTBot|ClaudeBot|PerplexityBot|Googlebot|bingbot|AhrefsBot' access.log | sort | uniq -c | sort -rn

Négy útvonalat keress külön. A wp-cron.php sűrű hívása azt jelzi, hogy a WordPress belső ütemezője minden oldalletöltéssel elindul. Az xmlrpc.php tömeges POST-ja szinte mindig jelszótörési kísérlet. Az admin-ajax.php magas aránya rosszul megírt bővítményre utal. A /?s= mintájú keresési URL-ek pedig gyorsítótárazatlan adatbázis-lekérdezéseket jelentenek, és a robotok is szeretik őket.

Miért nem a látogatószám az igazi ok a legtöbb esetben?

Saját tapasztalat, és ez a cikk fő állítása. A korlátot a legtöbb esetben egy rosszul ütemezett háttérfolyamat meríti ki. A látogatói csúcs annyit tesz hozzá, hogy a folyamat pont akkor fut, amikor az oldal amúgy is dolgozik.

A tipikus együttállás úgy néz ki, hogy a mentőbővítmény hajnali 2-kor indul, a biztonsági vizsgálat szintén hajnali 2-kor, a terméklista-frissítés is akkor, mert mindegyik alapértelmezése ugyanaz a kerek óra. Egyenként mindhárom belefér a csomagba, együtt viszont megtelik az IO és az NPROC, és a hibaszámláló percekre elszáll.

A WordPress belső ütemezője ráadásul látogatásra kapcsolódik, tehát forgalom nélkül nem fut, forgalomban pedig sokszor. Az aktuális állapot így kérdezhető le.

wp cron event list --fields=hook,next_run_relative,recurrence

Ha a listában tíznél több ötperces vagy percenkénti esemény szerepel, megtaláltad a terhelést. A megoldás az, hogy a belső ütemezőt lekapcsolod, és a tárhely saját cronjára teszed át. A wp-config.php sorba kerül ez.

define( 'DISABLE_WP_CRON', true );

A tárhely cron-bejegyzése pedig ötperces ütemben hívja.

*/5 * * * * cd /home/felhasznalo/public_html && /usr/bin/php wp-cron.php >/dev/null 2>&1

Ez a csere önmagában nem gyorsítja az oldalt, viszont kiszámíthatóvá teszi a terhelést, és jó eséllyel megszünteti a csúcsórai hibákat.

Mikor elég az optimalizálás, és mikor kell csomagot vagy VPS-t váltani?

A döntést az szabja meg, hogy a korlátot hasznos munka meríti-e ki. Fölösleges terhelésnél optimalizálj, bevételt termelő forgalomnál vegyél nagyobb erőforrást.

• Optimalizálás elég, ha az erőforrás-csúcs éjjel van, ismétlődő percben, vagy ha a naplóban a kérések többsége robot, xmlrpc.php, keresési URL vagy admin-ajax.php. Ide tartozik a lapszintű gyorsítótár bekapcsolása, az objektum-gyorsítótár (Redis vagy Memcached) használata, a PHP frissítése a legújabb támogatott verzióra és az adatbázis-indexek rendbetétele.
• Bővítmény-ritkítás, ha egy bővítmény kikapcsolása után a CPU-görbe mérhetően lejjebb kerül. Mérj, ne tippelj. A Query Monitor és a szerveroldali lassú lekérdezés-napló megmutatja, melyik hook viszi el az időt.
• Csomagváltás, ha a forgalom valódi, a gyorsítótár már működik, és mégis az EP vagy a CPU hibaszámlálója gyűlik a napi látogatói csúcsban. Osztott tárhelyen belül a nagyobb csomag többnyire ugyanazt a technológiát adja több erőforrással, tehát a viselkedés kiszámítható marad.
• VPS vagy menedzselt WordPress-szolgáltatás, ha olyanra van szükséged, amit osztott környezetben nem kapsz meg. Ilyen a saját PHP-FPM pool méretezése, a Redis, az Elasticsearch, a hosszan futó worker, a sűrűbb cron vagy a kötegelt importálás. Szakmai feltételezés, hogy a webshopok többségét az adminban futó kötegelt műveletek viszik ki az osztott tárhelyről, és a látogatószám csak másodlagos tényező.

Mit mérj le a szolgáltatóváltás előtt?

A váltás előtti mérés célja az, hogy a döntésed számokon álljon, és a váltás után legyen mihez hasonlítani. A lista egy délután alatt végigvehető.

1. A jelenlegi korlátok írásban, konkrét értékkel. CPU maghányad, PMEM, EP, NPROC, IO, IOPS. Ha nincsenek a csomagleírásban, kérd el a támogatástól.
2. Az utolsó 30 nap hibastatisztikája korlát szerinti bontásban, képernyőképpel.
3. A napi terhelési profil. Melyik órában van a látogatói csúcs, és melyikben az erőforrás-csúcs.
4. Működik-e egyáltalán lapszintű gyorsítótár, és van-e adat a találati arányról.
5. PHP-verzió, adatbázis-motor és -verzió, elérhető objektum-gyorsítótár.
6. Az adatbázis mérete, a legnagyobb táblák és az autoload mérete.
7. Fájlszám és inode-korlát. Sok tárhelyen az inode telik meg hamarabb, mint a tárterület.
8. A tíz leglassabb URL szerveroldali válaszideje, gyorsítótár nélkül mérve.
9. Az aktív háttérfolyamatok listája és ütemezésük, a cron-események kimenetével együtt.
10. A levélküldés módja. SMTP-n megy vagy a tárhely saját mail() függvényén. Váltásnál ez borul el a leggyakrabban.
11. Külső integrációk, amelyek a szerver IP-címére vagy kimenő portokra épülnek. NAV-kapcsolat, fizetési szolgáltató, számlázóprogram, webshop-szinkron.
12. A leendő szolgáltató válasza három kérdésre. Mi a CPU-korlát mértékegysége, engedélyezett-e a sűrű saját cron, és van-e elérhető objektum-gyorsítótár.
13. Referenciamérés váltás előtt és után, ugyanazzal az eszközzel, ugyanazon az URL-en, ugyanabban a napszakban.

Hivatalosan igazolt. A szerveroldali válaszidő a TTFB-n keresztül hat az LCP-re, ezért a tárhely erőforrás-helyzete megjelenik a Search Console oldalélmény-jelentéseiben is. Ez nem garantál helyezésváltozást, a romlás viszont visszamenőleg kimutatható.

Hogyan érinti mindez az AI-keresőket és a válaszmotorokat?

A válaszmotorok robotjai ugyanabból az erőforrás-konténerből esznek, mint a látogatók, és a hibás választ nem próbálják újra türelmesen. Ha egy robot 508-as vagy 503-as hibát kap, az adott oldal tartalma kimarad abból, amit indexel vagy idéz.

Hivatalosan igazolt. A Google dokumentációja szerint az 5xx válaszok a feltérképezési sebesség csökkentését váltják ki, és a tartósan hibás oldalak kieshetnek az indexből. Szakmai feltételezés, hogy az AI-alapú válaszmotorok hasonlóan viselkednek, mert erről a nyilvános dokumentációjuk kevesebbet mond. A gyakorlati következtetés ugyanaz. A robotforgalmat mérni kell, és ha egy-egy robot löketei ütnek be a korlátba, először a hozzáférést érdemes szabályozni, és csak utána nyúlni az erőforrás-bővítéshez.

Források és további olvasnivalók

• Google Search Central, feltérképezési költségvetés és a HTTP-állapotkódok kezelése
• Google Search Central, Core Web Vitals és oldalélmény-dokumentáció
• CloudLinux OS dokumentáció, LVE-korlátok (SPEED, PMEM, EP, NPROC, IO, IOPS)
• cPanel and WHM dokumentáció, Resource Usage felület
• LiteSpeed Web Server dokumentáció, PHP-folyamatkezelés
• WordPress Developer Resources, WP-Cron és a DISABLE_WP_CRON beállítás
• WP-CLI parancsreferencia
• PHP kézikönyv, memory_limit és max_execution_time
• IETF RFC 9110, HTTP Semantics
• MDN Web Docs, HTTP válasz-állapotkódok
• MySQL és MariaDB dokumentáció, slow query log
• Schema.org és W3C specifikációk a szerkezetes adatokhoz és a webteljesítmény-mérésekhez