Zaznamenajte čas špičky a porovnajte CPU, pamäť, PHP workers, databázu a access log. Zoskupte požiadavky podľa URL, statusu, IP alebo user agenta a profilujte najdrahší scenár. Obmedzte škodlivý zdroj, opravte dotaz či úlohu, nastavte cache a až potom rozhodnite o kapacite.
Vysoké CPU alebo pamäť WordPressu nie je diagnóza, ale signál, že server robí viac práce, než zvláda alebo než by mal. Príčinou môže byť legitímna návštevnosť, bot, neúspešný cron, pomalý dotaz, externý timeout, generovanie obrázkov alebo nekonečná slučka. Okamžitý upgrade servera môže kúpiť čas, no bez merania sa rovnaký problém vráti vo väčšom meradle.
Vyšetrovanie spája časový priebeh infraštruktúry s access logom, PHP procesmi, databázou a aplikačnými udalosťami. Potrebujete vedieť, či zdrojom je veľa lacných požiadaviek alebo niekoľko extrémne drahých. Po stabilizácii sa vytvorí reprodukcia a oprava, potom primeraná kapacitná rezerva. Nasledujúci postup je read-only tam, kde sa najprv zbierajú dôkazy.
Určte čas, zdroj a typ vyčerpania
Pozrite grafy CPU, pamäte, load average, diskového I/O, swapu, databázových spojení a PHP workerov v rovnakom časovom pásme. Krátka špička po nasadení sa líši od postupného úniku pamäte alebo dennej cron úlohy. Zaznamenajte začiatok, trvanie a návrat k normálu. Overte aj prípadné limity hostingu a throttling.
Rozlíšte vyčerpanie PHP od databázy, webservera alebo externého spojenia. Plná fronta workerov môže byť následkom toho, že každý čaká na API, nie nedostatku procesov. OOM udalosť môže proces zabiť bez čitateľnej WordPress chyby. Serverové a systémové logy preto patria k aplikačným údajom.
Zoskupte požiadavky z access logu
Pre sledované okno zistite najčastejšie URL, metódy, stavové kódy, zdrojové adresy, user agentov a čas odpovede. Veľký objem na prihlasovanie, XML-RPC, vyhľadávanie, REST endpoint alebo náhodné 404 môže signalizovať automatizáciu. Nezablokujte legitímny vyhľadávač iba podľa názvu user agenta; overujte správanie a pôvod podľa možností.
Pomalá URL s malým počtom môže spotrebovať rovnaké zdroje ako veľa rýchlych. Sledujte percentily času a veľkosť odpovede, nie iba počet. Pri cache rozlišujte hit a miss. Pridajte korelačné ID, ak request pokračuje do frontu alebo externého API. Logy redigujte a uchovávajte primerane, pretože URL môže obsahovať citlivý parameter.
- URL a metóda
- Počet, čas a stav odpovede
- Cache hit alebo miss
- Bot, používateľ alebo naplánovaná úloha
Profilujte PHP, databázu a externé volania
Na stagingu alebo bezpečným produkčným profilerom zistite funkcie, hooky a pluginy spotrebúvajúce čas a pamäť. Sledujte opakované dotazy, veľké kolekcie bez stránkovania a slučky nad metadátami. Databázový slow log ukáže dotaz aj plán. Neoptimalizujte iba súbor uvedený na vrchu stacku, ak iba čaká na hlbšiu závislosť.
Externé HTTP volania majú timeout a nesmú blokovať každé zobrazenie. Cache výsledok alebo presuňte synchronizáciu do frontu. Pri importe spracúvajte dávky s checkpointom, nie celý katalóg v jednej požiadavke. Pamäťový limit nezvyšujte ako jedinú opravu, kým neviete, či objekt rastie legitímne alebo uniká v nekonečnom cykle.
Stabilizujte prevádzku bez straty dôkazov
Pri aktívnom incidente možno zaviesť rate limit na konkrétny zneužívaný endpoint, zapnúť pripravenú cache, pozastaviť chybnú úlohu alebo dočasne obmedziť drahú funkciu. Každé opatrenie musí mať vlastníka a podmienku návratu. Úplné blokovanie všetkej návštevnosti alebo reštart v slučke môže skryť vzor a poškodiť objednávky.
Pred ukončením procesu zachovajte logy, metriky a stav frontu. Pri cron alebo Action Scheduler chybe nevytvárajte ďalšie ručné pokusy bez idempotencie. Ak zvýšite počet workerov, sledujte databázové spojenia a pamäť; viac súbehu môže kolaps zrýchliť. Komunikujte prevádzke, ktorá funkcia je dočasne obmedzená.
- Cielený rate limit
- Dočasné pozastavenie chybného hooku
- Zachované metriky a logy
- Časovo obmedzené núdzové opatrenie
Opravte koreň a nastavte kapacitnú rezervu
Oprava môže byť index, stránkovanie, odstránenie duplicitného hooku, objektová cache, kratší timeout alebo presun práce do frontu. Porovnajte rovnaký scenár pred a po zásahu a vykonajte funkčný test. Záťažovú skúšku robte na vhodnom prostredí s realistickým mixom požiadaviek a po dohode s poskytovateľom, nie nekontrolovane na produkcii.
Až po optimalizácii stanovte počet workerov, pamäť a škálovanie podľa bežnej prevádzky a očakávanej špičky. Monitoring upozorní na trend skôr než tvrdý limit a runbook spojí metriku s prvými kontrolami. Po incidente zapíšte spúšťač, dopad, čas detekcie a preventívne opatrenie. Kapacita a efektívny kód sa dopĺňajú, nie nahrádzajú.
Časté otázky
Pomôže zvýšenie PHP memory_limit?
Môže dočasne dokončiť legitímne náročnú úlohu, ale nevyrieši nekonečnú slučku, veľký neobmedzený dotaz ani únik. Najprv zmerajte, čo pamäť drží, a zvýšenie overte spolu s kapacitou všetkých workerov.
Ako zistím, či CPU spotrebúva bot?
V čase špičky zoskupte access log podľa URL, IP, user agenta, počtu a času odpovede. Overte, či požiadavky obchádzajú cache a majú automatický vzor. User agent sa dá sfalšovať, preto používajte viac signálov.
Je riešením výkonnejší hosting?
Ak je bežná legitímna záťaž vyššia než kapacita, áno. Pri chybe kódu alebo útoku iba oddiali limit a zvýši náklady. Najprv stabilizujte a profilujte, potom kombinujte optimalizáciu s primeranou rezervou.
Zdroje a ďalšie čítanie
Web developer zo Spišskej Novej Vsi. Venuje sa WordPressu, WooCommerce, vlastným pluginom, API integráciám, webovým aplikáciám a praktickým AI automatizáciám.
