Zaznamenejte čas špičky a porovnejte CPU, paměť, PHP workers, databázi a access log. Seskupte požadavky podle URL, statusu, IP nebo user agenta a profilujte nejnáročnější scénář. Omezte škodlivý zdroj, opravte dotaz či úlohu, nastavte cache a teprve poté rozhodněte o kapacitě.
Vysoké vytížení CPU nebo paměti WordPressu není diagnóza, ale signál, že server dělá více práce, než zvládá nebo než by měl. Příčinou může být legitimní návštěvnost, bot, neúspěšný cron, pomalý dotaz, externí timeout, generování obrázků nebo nekonečná smyčka. Okamžitý upgrade serveru může získat čas, ale bez měření se stejný problém vrátí ve větším měřítku.
Vyšetřování propojuje časový průběh infrastruktury s access logem, PHP procesy, databází a aplikačními událostmi. Potřebujete vědět, zda je zdrojem mnoho levných požadavků, nebo několik extrémně náročných. Po stabilizaci se vytvoří reprodukce a oprava, poté přiměřená kapacitní rezerva. Následující postup je read-only tam, kde se nejprve sbírají důkazy.
Určete čas, zdroj a typ vyčerpání
Prohlédněte si grafy CPU, paměti, load average, diskového I/O, swapu, databázových spojení a PHP workerů ve stejném časovém pásmu. Krátká špička po nasazení se liší od postupného úniku paměti nebo denní cron úlohy. Zaznamenejte začátek, trvání a návrat do normálu. Ověřte také případné limity hostingu a throttling.
Rozlišujte vyčerpání PHP od vyčerpání databáze, webserveru nebo externího připojení. Plná fronta workerů může být důsledkem toho, že každý čeká na API, nikoli nedostatku procesů. Událost OOM může proces ukončit bez čitelné chyby WordPressu. Serverové a systémové logy proto patří k aplikačním datům.
Seskupte požadavky z access logu
Pro sledované okno zjistěte nejčastější URL, metody, stavové kódy, zdrojové adresy, user agenty a dobu odezvy. Velký objem požadavků na přihlašování, XML-RPC, vyhledávání, REST endpoint nebo náhodné chyby 404 může signalizovat automatizaci. Neblokujte legitimní vyhledávač jen podle názvu user agenta; ověřujte chování a původ, pokud je to možné.
Pomalá URL s malým počtem požadavků může spotřebovat stejné zdroje jako mnoho rychlých. Sledujte percentily času a velikost odpovědi, nejen počet. U cache rozlišujte hit a miss. Přidejte korelační ID, pokud request pokračuje do fronty nebo externího API. Logy redigujte a uchovávejte přiměřeně, protože URL může obsahovat citlivý parametr.
- URL a metoda
- Počet, čas a stav odpovědi
- Cache hit nebo miss
- Bot, uživatel, nebo naplánovaná úloha
Profilujte PHP, databázi a externí volání
Na stagingu nebo pomocí bezpečného produkčního profileru zjistěte funkce, hooky a pluginy, které spotřebovávají čas a paměť. Sledujte opakované dotazy, velké kolekce bez stránkování a smyčky nad metadaty. Databázový slow log ukáže dotaz i jeho plán. Neoptimalizujte pouze soubor uvedený na vrcholu stacku, pokud jen čeká na hlubší závislost.
Externí HTTP volání mají mít timeout a nesmí blokovat každé zobrazení. Výsledek ukládejte do cache nebo přesuňte synchronizaci do fronty. Při importu zpracovávejte dávky s checkpointem, nikoli celý katalog v jednom požadavku. Paměťový limit nezvyšujte jako jedinou opravu, dokud nevíte, zda objekt roste legitimně, nebo uniká v nekonečném cyklu.
Stabilizujte provoz bez ztráty důkazů
Při aktivním incidentu lze zavést rate limit na konkrétní zneužívaný endpoint, zapnout připravenou cache, pozastavit chybnou úlohu nebo dočasně omezit nákladnou funkci. Každé opatření musí mít vlastníka a podmínku návratu. Úplné zablokování veškeré návštěvnosti nebo restart ve smyčce může skrýt vzorec a poškodit objednávky.
Před ukončením procesu zachovejte logy, metriky a stav fronty. Při chybě cronu nebo Action Scheduleru nevytvářejte další ruční pokusy bez idempotence. Pokud zvýšíte počet workerů, sledujte databázová spojení a paměť; více souběhu může kolaps urychlit. Sdělte provozu, která funkce je dočasně omezena.
- Cílený rate limit
- Dočasné pozastavení chybného hooku
- Zachované metriky a logy
- Časově omezené nouzové opatření
Opravte příčinu a nastavte kapacitní rezervu
Opravou může být index, stránkování, odstranění duplicitního hooku, objektová cache, kratší timeout nebo přesun práce do fronty. Porovnejte stejný scénář před zásahem a po něm a proveďte funkční test. Zátěžový test provádějte ve vhodném prostředí s realistickým mixem požadavků a po dohodě s poskytovatelem, nikoli nekontrolovaně na produkci.
Teprve po optimalizaci stanovte počet workerů, paměť a škálování podle běžného provozu a očekávané špičky. Monitoring upozorní na trend dříve než na tvrdý limit a runbook propojí metriku s prvními kontrolami. Po incidentu zapište spouštěč, dopad, dobu detekce a preventivní opatření. Kapacita a efektivní kód se doplňují, nikoli nahrazují.
Časté dotazy
Pomůže zvýšení PHP memory_limit?
Může dočasně dokončit legitimně náročnou úlohu, ale nevyřeší nekonečnou smyčku, velký neomezený dotaz ani únik. Nejprve změřte, co paměť drží, a navýšení ověřte spolu s kapacitou všech workerů.
Jak zjistím, zda CPU spotřebovává bot?
V době špičky seskupte access log podle URL, IP, user agenta, počtu a doby odezvy. Ověřte, zda požadavky obcházejí cache a mají automatizovaný vzorec. User agent lze podvrhnout, proto používejte více signálů.
Je řešením výkonnější hosting?
Pokud je běžná legitimní zátěž vyšší než kapacita, ano. Při chybě kódu nebo útoku pouze oddálí limit a zvýší náklady. Nejprve stabilizujte a profilujte, potom kombinujte optimalizaci s přiměřenou rezervou.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
