Rögzítse a csúcsidőszakot, és hasonlítsa össze a CPU-t, a memóriát, a PHP workereket, az adatbázist és az access logot. Csoportosítsa a kéréseket URL, státusz, IP vagy user agent szerint, és profilozza a legdrágább forgatókönyvet. Korlátozza a káros forrást, javítsa a lekérdezést vagy a feladatot, állítson be cache-t, és csak ezután döntsön a kapacitásról.
A WordPress magas CPU- vagy memóriahasználata nem diagnózis, hanem annak jele, hogy a szerver több munkát végez, mint amennyit elbír, vagy amennyit kellene. Az ok lehet legitim látogatottság, bot, sikertelen cron, lassú lekérdezés, külső időtúllépés, képgenerálás vagy végtelen ciklus. Az azonnali szerverbővítés időt nyerhet, de mérés nélkül ugyanaz a probléma nagyobb léptékben tér vissza.
A vizsgálat összekapcsolja az infrastruktúra időbeli lefolyását az access loggal, a PHP-folyamatokkal, az adatbázissal és az alkalmazáseseményekkel. Tudnia kell, hogy a forrás sok olcsó kérés vagy néhány rendkívül költséges. A stabilizálás után elkészül a reprodukció és a javítás, majd egy megfelelő kapacitástartalék. Az alábbi eljárás ott read-only, ahol először bizonyítékokat gyűjtünk.
Határozza meg a kimerülés idejét, forrását és típusát
Nézze meg a CPU, a memória, a load average, a lemez I/O, a swap, az adatbázis-kapcsolatok és a PHP workerek grafikonjait ugyanabban az időzónában. Egy telepítés utáni rövid csúcs különbözik a fokozatos memóriaszivárgástól vagy egy napi cron feladattól. Jegyezze fel a kezdetet, az időtartamot és a normál állapotba való visszatérést. Ellenőrizze a tárhely esetleges korlátait és a throttlingot is.
Különböztesse meg a PHP kimerülését az adatbázis, a webszerver vagy egy külső kapcsolat kimerülésétől. A workerek megtelt sora annak is következménye lehet, hogy mindegyik egy API-ra vár, nem pedig a folyamatok hiányának. Egy OOM-esemény olvasható WordPress-hiba nélkül is leállíthatja a folyamatot. Ezért a szerver- és rendszernaplók is az alkalmazásadatokhoz tartoznak.
Csoportosítsa a kéréseket az access logból
A vizsgált időablakra határozza meg a leggyakoribb URL-eket, metódusokat, állapotkódokat, forráscímeket, user agenteket és válaszidőket. A bejelentkezésre, XML-RPC-re, keresésre, REST endpointra irányuló nagy forgalom vagy a véletlenszerű 404-es hibák automatizációra utalhatnak. Ne blokkoljon egy legitim keresőmotort csupán a user agent neve alapján; lehetőség szerint ellenőrizze a viselkedést és az eredetet.
Egy kevés kérést kapó lassú URL ugyanannyi erőforrást fogyaszthat, mint sok gyors. Kövesse nyomon a válaszidő percentiliseit és a válasz méretét, ne csak a kérések számát. A cache esetében különböztesse meg a hitet és a misst. Adjon hozzá korrelációs azonosítót, ha a request egy sorban vagy külső API-ban folytatódik. A logokat redigálja és arányos ideig őrizze meg, mert az URL érzékeny paramétert is tartalmazhat.
- URL és metódus
- Darabszám, időpont és válaszállapot
- Cache hit vagy miss
- Bot, felhasználó vagy ütemezett feladat
Profilozza a PHP-t, az adatbázist és a külső hívásokat
Stagingen vagy biztonságos éles profilerrel derítse ki, mely függvények, hookok és pluginok fogyasztják az időt és a memóriát. Figyelje az ismétlődő lekérdezéseket, a lapozás nélküli nagy gyűjteményeket és a metaadatok feletti ciklusokat. Az adatbázis slow logja a lekérdezést és a végrehajtási tervet is megmutatja. Ne csak a stack tetején szereplő fájlt optimalizálja, ha az csupán egy mélyebben fekvő függőségre vár.
A külső HTTP-hívásoknak legyen időkorlátjuk, és nem blokkolhatnak minden oldalmegjelenítést. Gyorsítótárazza az eredményt, vagy helyezze át a szinkronizálást egy várólistába. Importáláskor kötegekben, checkpointtal dolgozzon, ne a teljes katalógust egyetlen kérésben. Ne a memóriakorlát emelése legyen az egyetlen javítás, amíg nem tudja, hogy az objektum jogosan növekszik-e, vagy egy végtelen ciklusban szivárog.
Stabilizálja az üzemet a bizonyítékok elvesztése nélkül
Aktív incidens során be lehet vezetni rate limitet egy konkrét, visszaélésre használt endpointra, be lehet kapcsolni az előkészített cache-t, fel lehet függeszteni a hibás feladatot, vagy átmenetileg korlátozni lehet egy költséges funkciót. Minden intézkedésnek legyen gazdája és visszaállítási feltétele. Az összes forgalom teljes blokkolása vagy a ciklikus újraindítás elfedheti a mintázatot, és károsíthatja a rendeléseket.
A folyamat leállítása előtt őrizze meg a naplókat, a metrikákat és a várólista állapotát. Cron vagy Action Scheduler hiba esetén ne indítson további kézi próbálkozásokat idempotencia nélkül. Ha növeli a workerek számát, figyelje az adatbázis-kapcsolatokat és a memóriát; a nagyobb párhuzamosság felgyorsíthatja az összeomlást. Tájékoztassa az üzemeltetést arról, hogy melyik funkció ideiglenesen korlátozott.
- Célzott rate limit
- A hibás hook ideiglenes felfüggesztése
- Megőrzött metrikák és naplók
- Időben korlátozott vészhelyzeti intézkedés
Javítsa ki a kiváltó okot, és állítson be kapacitástartalékot
A javítás lehet index, lapozás, a duplikált hook eltávolítása, objektum-gyorsítótár, rövidebb timeout vagy a munka áthelyezése egy sorba. Hasonlítsa össze ugyanazt a forgatókönyvet a beavatkozás előtt és után, és végezzen funkcionális tesztet. A terheléses tesztet megfelelő környezetben, a kérések valósághű keverékével és a szolgáltatóval egyeztetve végezze, ne ellenőrizetlenül éles környezetben.
Csak az optimalizálás után határozza meg a workerek számát, a memóriát és a skálázást a szokásos üzem és a várható csúcs alapján. A monitoring még a kemény korlát elérése előtt figyelmeztet a trendre, a runbook pedig összekapcsolja a metrikát az első ellenőrzésekkel. Incidens után rögzítse a kiváltó okot, a hatást, az észlelés idejét és a megelőző intézkedést. A kapacitás és a hatékony kód kiegészítik, nem pedig helyettesítik egymást.
Gyakori kérdések
Segít a PHP memory_limit növelése?
Átmenetileg segíthet egy legitim, erőforrásigényes feladat befejezésében, de nem oldja meg a végtelen ciklust, a nagy, korlátlan lekérdezést vagy a memóriaszivárgást. Először mérje meg, mi tartja a memóriát, és a növelést az összes worker kapacitásával együtt ellenőrizze.
Hogyan állapíthatom meg, hogy bot terheli-e a CPU-t?
Csúcsidőben csoportosítsa az access logot URL, IP-cím, user agent, darabszám és válaszidő szerint. Ellenőrizze, hogy a kérések megkerülik-e a gyorsítótárat, és automatizált mintázatot mutatnak-e. A user agent hamisítható, ezért több jelzést használjon.
Egy erősebb tárhely a megoldás?
Ha a szokásos, legitim terhelés meghaladja a kapacitást, igen. Kódhiba vagy támadás esetén csak késlelteti a korlát elérését, és növeli a költségeket. Először stabilizáljon és profilozzon, majd kombinálja az optimalizálást megfelelő tartalékkal.
Források és további olvasnivaló
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.
