Ha a weboldalad minden nap nagyjából ugyanakkor lassú, ritkán a kód a hibás. Sokkal gyakoribb, hogy a szerveren egyszerre indul el a mentés, a vírusellenőrzés, a termékimport és a hírlevélküldés, és ezek egymás elől veszik el a processzort, a lemezt és az adatbázist. Ebben a cikkben végigmegyünk azon, hogyan térképezed fel, mi fut a gépen, hogyan teszed egymás mellé az időpontokat, és hogyan osztod szét őket úgy, hogy a látogató ne vegyen észre semmit.
A cikkben háromféle állítást különítünk el. Hivatalosan igazolt az, ami egy gyártói vagy szabványdokumentációban szerepel. Saját tapasztalat az, amit weboldalak üzemeltetése közben rendszeresen látunk. Szakmai feltételezés az, ami logikusan következik, de nem mértük minden esetben.
Miért lassul be a weboldal minden nap ugyanabban az órában?
A napi, órára pontosan ismétlődő lassulás mögött legtöbbször egy ütemezett háttérfolyamat áll, ami ugyanazokat az erőforrásokat használja, mint a látogatók kiszolgálása. Egy megosztott tárhelyen vagy kisebb virtuális szerveren a lemez és az adatbázis szűk keresztmetszet, és egy teljes mentés ezt akár órákra lefoglalhatja.
A tipikus szereplők ezek:
- Mentés. Fájlok tömörítése és adatbázis-kiírás, erős lemez- és processzorterheléssel.
- Vírus- és kártevőellenőrzés. Minden fájlt végigolvas, rengeteg apró lemezművelettel.
- Termékimport vagy készletszinkron. Sok adatbázis-írás, gyorsítótár-ürítés, néha képfeldolgozás is.
- Hírlevélküldés. Ha a saját szerveredről megy ki, sok PHP-folyamatot és adatbázis-lekérdezést indít.
- Keresőindex-frissítés. A belső kereső (például a webshop termékkeresője) újraépítése, ami a teljes terméktáblát átolvassa.
Szakmai feltételezés: egy-egy feladat külön ritkán okoz érezhető gondot. A baj akkor jön, amikor kettő vagy három átfed, mert ilyenkor a várakozási sorok összeadódnak, és a látogatók kérései a sor végére kerülnek.
Hogyan derítsd ki, mi fut a szerveren éjjel és nappal?
Három helyen nézel körül, a rendszer ütemezőiben, az alkalmazás saját ütemezőjében és a külső szolgáltatások beállításaiban. Egyik sem elég magában, mert a feladatok egy része nem is a szerveren van beállítva, csak onnan fut.
1. Rendszerszintű ütemezők
Linux szerveren a cron és a systemd időzítők a leggyakoribbak. Ezekkel a parancsokkal listázhatod őket:
crontab -laz aktuális felhasználó feladatait mutatja, asudo crontab -l -u www-dataa webszerver felhasználójáét.ls /etc/cron.d /etc/cron.daily /etc/cron.hourlya rendszerszintű cron-fájlokat listázza.systemctl list-timers --alla systemd időzítőket mutatja, az utolsó és a következő futás idejével együtt.
Ha tárhelykezelő panelt használsz (cPanel, Plesk, ispmanager vagy hasonló), ott is van egy „Ütemezett feladatok” vagy „Cron” menü, és külön a mentés beállítása. A panelből indított mentés sokszor nem látszik a felhasználói crontabban, ezért könnyű kifelejteni.
2. Alkalmazásszintű ütemezők
WordPressnél a WP-Cron saját listát vezet, amit WP-CLI-vel így nézhetsz meg.
wp cron event list --fields=hook,next_run_gmt,recurrence
Hivatalosan igazolt: a WordPress fejlesztői dokumentációja szerint a WP-Cron nem valódi ütemező, hanem oldalbetöltéskor ellenőrzi, van-e esedékes feladat. Emiatt egy látogató kérése is elindíthat egy nehéz feladatot, és pont az ő oldalbetöltése lassul. A dokumentáció leírja, hogyan kapcsolod ki a DISABLE_WP_CRON konstanssal, és hogyan hívod meg helyette rendszer-cronból.
Nézd át a bővítmények beállításait is. A biztonsági bővítménynek lehet ütemezett vizsgálata, a mentőbővítménynek saját időzítése, az importálónak (XML vagy CSV feed) óránkénti futása, a hírlevélmodulnak küldési sora, a keresőbővítménynek pedig indexelése.
3. Naplók és külső szolgáltatások
Ami beállításként nem látszik, az a naplóban igen. A grep CRON /var/log/syslog (Debian, Ubuntu) vagy a journalctl -u cron --since yesterday megmutatja, mi indult el ténylegesen. A webszerver hozzáférési naplójában keresd az ismétlődő, időzített hívásokat is, például egy külső készletrendszer óránkénti lekérését vagy egy felhőmentő szolgáltatás bejelentkezését.
Hogyan tedd egymás mellé az időpontokat egy táblázatban?
Készíts egy egyszerű táblázatot (akár táblázatkezelőben), amelyben minden sor egy feladat, és minden időpont ugyanabban az időzónában szerepel. Ez az egy lépés gyakran már magában megmutatja az ütközést.
Javasolt oszlopok:
- a feladat neve, és hol van beállítva (cron, panel, bővítmény, külső szolgáltatás)
- az indulás időpontja, helyi időre átszámolva
- a gyakoriság (óránként, naponta, hetente)
- a mért futásidő (legrövidebb, jellemző, leghosszabb)
- mit terhel főleg (processzor, lemez, adatbázis, hálózat)
- ki a felelőse, és mi történik, ha egy futás kimarad
Egy elképzelt, de jellemző kiindulási állapot így néz ki:
- 02:00 teljes mentés, naponta, 40-70 perc, lemez és processzor
- 02:30 kártevővizsgálat, naponta, 20-30 perc, lemez
- 02:45 termékimport a beszállítói feedből, óránként, 5-25 perc, adatbázis
- 03:00 keresőindex újraépítése, naponta, 15 perc, adatbázis és processzor
Ebben a példában 02:30 és 03:15 között négy nehéz feladat fut egyszerre. Aki ilyenkor vásárol, lassú oldalt lát.
Saját tapasztalat: az időzónák a leggyakoribb csapda. Sok szerver UTC szerint fut, a panel viszont helyi időt mutathat, a bővítmény pedig a WordPressben beállított időzónát használja. Nyári időszámítás alatt a UTC szerinti 02:00 Magyarországon hajnali 4 óra, télen 3 óra, így a „csendes éjszakai” mentés óraátállításkor egy órával közelebb kerülhet a reggeli forgalomhoz. Ezért a táblázatban mindig egy időzónát használj, és írd is oda, melyiket.
Hogyan oldd fel az ütközéseket lépésről lépésre?
Először mérj, és csak utána tologasd az időpontokat. Futásidő nélkül a szétosztás csak tippelés, és a következő héten ugyanott leszel.
- Mérd a futásidőt. Tegyél minden feladat elé és mögé egy naplósort, hogy lásd a tényleges kezdést és a végét, például így:
echo "$(date '+%F %T') import START" >> /var/log/utemezes.log. Egy hét adat már elég a jellemző és a leghosszabb futásidőhöz. - Nézd meg óránként a forgalmat. Az analitikában vagy a szervernaplóban keresd meg a leggyengébb két-három órát. Ez lesz a nehéz feladatok ablaka, és nem biztos, hogy hajnali 2 óra.
- Oszd szét az időablakokat. A legnehezebb feladat (általában a teljes mentés) kapja a legcsendesebb ablakot, a többi utána jöjjön, a mért leghosszabb futásidőnél kicsit nagyobb távolsággal.
- Csökkentsd a gyakoriságot, ahol lehet. Kell-e óránként teljes import, vagy elég óránként a készletet és az árat frissíteni, a teljes termékadatot pedig naponta egyszer? Kell-e minden éjjel teljes kártevővizsgálat, vagy elég a megváltozott fájlokat nézni?
- Ne engedd, hogy egy feladat önmagára fusson. Ha egy óránkénti import egyszer 70 percig tart, a következő elindul mellette. A
flockezt megakadályozza:0 * * * * flock -n /tmp/import.lock /usr/local/bin/import.sh. Ha az előző még fut, az új egyszerűen kimarad. - Adj alacsonyabb prioritást. A
nice -n 19 ionice -c3előtaggal azt kéred az operációs rendszertől, hogy a mentés csak akkor kapjon processzort és lemezt, amikor más nem kér. A mentés ettől tovább tarthat, a weboldal viszont kevésbé szenved. - Tedd át a WP-Cront valódi cronra. A
DISABLE_WP_CRONbekapcsolása után egy rendszer-cron hívja meg, például 5 percenként:*/5 * * * * cd /var/www/oldal && wp cron event run --due-now --quiet. - Egy hét múlva nézd vissza. Hasonlítsd össze a naplót a lassulási görbével. Ha maradt csúcs, ott még van egy feladat, ami kimaradt a táblázatból.
Hivatalosan igazolt: a MySQL dokumentációja szerint a mysqldump --single-transaction InnoDB tábláknál a táblák zárolása nélkül készít konzisztens mentést. Régebbi, MyISAM táblákat használó oldalaknál a mentés idejére zárolás történhet, ami az írási műveleteknél (kosár, rendelés) közvetlen várakozást okoz.
Hogyan állíts be riasztást, ha egy feladat túl sokáig fut?
Adj minden feladatnak egy felső időkorlátot a mért leghosszabb futásidő alapján, és kérj értesítést, ha átlépi, vagy ha hibával áll le. A hosszú futás általában korai jel. Nő az adatmennyiség, lassul a beszállítói feed, vagy fogy a hely a lemezen.
Egyszerű megoldás a timeout parancs egy levélküldéssel kombinálva.
timeout 45m /usr/local/bin/import.sh || echo 'Az import hibával állt le, vagy 45 perc után sem ért véget' | mail -s 'Import riasztás' uzemeltetes@pelda.hu
A timeout 124-es kilépési kóddal jelzi, ha le kellett állítania a feladatot, így a riasztásban ez külön is kezelhető. Ha már van monitorozó rendszered, az ütemezett feladatok figyelésére jellemzően „heartbeat” vagy „cron monitor” funkciót kínál. A feladat a végén jelez, és ha a jelzés nem érkezik meg időben, riasztást kapsz. Ez a kimaradt futást is elkapja, nem csak a túl hosszút.
Szakmai feltételezés: a küszöböt érdemes a jellemző futásidő másfél-kétszeresére tenni. Túl szoros küszöbnél annyi riasztás jön, hogy senki nem figyel rájuk, túl lazánál pedig mire szól, a látogató már érzi a bajt.
Mit nézz meg, ha a forgalmi adatokban rendszeres napi lassulás látszik?
Ha a lassulás minden nap nagyjából ugyanakkor jelentkezik, szinte biztosan időzített okot keresel. Ezen a listán érdemes végigmenni:
- Percre pontosan egyezik a lassulás kezdete valamelyik feladat indulásával a táblázatodban?
- Ugyanabban az időzónában nézed az analitikát, a szervernaplót és a cront?
- Hétvégén is jelentkezik, vagy csak munkanapokon? A heti mentés vagy a heti riport más napon fut.
- Az óraátállítás után egy órával elcsúszott a jelenség?
- Mit mutat ilyenkor a szerver terhelése az
uptime, atopvagy aziostat -x 5szerint? Magas az I/O-várakozás (wa)? - Van ebben az időablakban lassú lekérdezés a MySQL lassúnaplójában (
slow_query_log)? - Eléri a PHP-folyamatok száma a korlátot? Keresd a PHP-FPM naplóban a
max_childrenfigyelmeztetést. - Megnő ilyenkor az 5xx hibák vagy az időtúllépések száma a hozzáférési naplóban?
- Az import üríti a gyorsítótárat, és utána a látogatók üres gyorsítótárra érkeznek?
- Jön ilyenkor feltűnően sok botkérés (keresőrobot, AI-crawler, árfigyelő)?
- Mikor futtatja a tárhelyszolgáltató a saját, szerveroldali mentését? Ezt sokszor csak tőlük tudhatod meg.
Miért esik egybe olyan gyakran a látogatói panasz és a mentés időpontja?
Saját tapasztalat: amikor egy „reggel mindig akadozik a webshop” típusú panaszt visszakövetünk, meglepően gyakran a mentésnél kötünk ki. Ennek néhány visszatérő oka van.
- A mentést valaki „éjszakára” állította, de UTC szerint, vagy egy másik időzónában működő tárhelynél, így valójában kora reggel fut.
- Az oldal nőtt, vele együtt a mentés hossza is, és a régen félórás futás mára belelóg a reggeli forgalomba. Ezt senki nem veszi észre, mert a futásidőt senki nem méri.
- Két mentés fut egyszerre, egy a tárhelypanelből és egy a mentőbővítményből, és a két beállítás gazdája nem tud egymásról.
- A mentés után közvetlenül indul az import vagy az indexfrissítés, mert valaki „majd a mentés után” logikával időzítette, a mentés viszont azóta hosszabb lett.
Ezért a panasz időpontját mindig érdemes percre pontosan rögzíteni, és először a táblázatod mellé tenni. Sokszor ennyiből kiderül az ok, mielőtt bárki a kódhoz nyúlna.
Számít ez a keresőknek és az AI-válaszmotoroknak?
Közvetve igen, de óvatosan kell fogalmazni. Hivatalosan igazolt: a Google Search Central dokumentációja szerint a Googlebot a szerver válaszaihoz igazítja a feltérképezés ütemét, és ha az oldal lassan válaszol vagy szerverhibákat ad, csökkentheti a feltérképezést. A Core Web Vitals terepadatai (Chrome UX Report) valós látogatók méréseiből származnak, 28 napos időszakra összesítve, így ha a látogatók egy része rendszeresen lassú oldalt kap, az bekerülhet ezekbe az adatokba.
Szakmai feltételezés: az AI-crawlerek is kaphatnak időtúllépést vagy hibát, ha éppen egy nehéz háttérfolyamat közben kérnek le egy oldalt. Arról, hogy ez mennyire befolyásolja az AI-válaszokban való idézést, nincs nyilvános, igazolt adat, a stabil válaszidő viszont jó eséllyel nem árt. Helyezést vagy AI-említést a rendezett ütemezés nem garantál, a technikai kockázatot viszont csökkenti.
Források és további olvasnivalók
- Google Search Central, a feltérképezési keretről és a Googlebot feltérképezési üteméről szóló dokumentáció
- web.dev, Core Web Vitals és Chrome UX Report dokumentáció
- WordPress Developer Resources, Plugin Handbook, Cron fejezet (WP-Cron és DISABLE_WP_CRON)
- WP-CLI Commands dokumentáció, wp cron
- MySQL Reference Manual, mysqldump
- systemd.timer és crontab(5) kézikönyvoldalak
- GNU Coreutils (timeout) és util-linux (flock, ionice) dokumentáció
- Az ismétlődő napi lassulás oka legtöbbször egy ütemezett feladat, ami ugyanazt a lemezt, processzort és adatbázist használja, mint a látogatók kiszolgálása.
- A feladatok három helyen lehetnek beállítva: a rendszer ütemezőjében, az alkalmazásban (például WP-Cron) és a tárhelypanelen vagy egy külső szolgáltatásban.
- Minden időpontot egy időzónában vezess, mert a UTC és a helyi idő keverése, valamint az óraátállítás a leggyakoribb csapda.
- Előbb mérd a futásidőt, és csak utána told el az időpontokat. A flock, a nice/ionice és a timeout egyszerű, de hatékony eszközök erre.
- Saját tapasztalatunk szerint a látogatói panasz időpontja meglepően gyakran egybeesik a mentésével, ezért először mindig ezt érdemes megnézni.
Gyakori kérdések
Hogyan tudom meg, milyen ütemezett feladatok futnak a szerveremen?
Linuxon a crontab -l, az /etc/cron.d könyvtár és a systemctl list-timers --all parancs mutatja a rendszerszintű feladatokat. Ezen felül nézd át a tárhelypanel mentési és cron-beállításait, WordPressnél a wp cron event list kimenetét, és a naplóban azt, mi indult el ténylegesen.
Miért lassú a weboldalam minden reggel ugyanakkor?
Legtöbbször egy ütemezett háttérfolyamat, jellemzően a mentés, az import vagy a vírusellenőrzés, fut ilyenkor, és elveszi az erőforrást a látogatók elől. Gyakori ok az is, hogy a feladat UTC szerint van időzítve, így helyi időben később fut, mint gondolnád.
Ki kell kapcsolni a WP-Cront?
A WordPress dokumentációja leírja, hogyan kapcsolod ki a DISABLE_WP_CRON konstanssal, és hogyan hívod meg helyette rendszer-cronból. Forgalmasabb oldalaknál ez jó eséllyel kiszámíthatóbbá teszi a futást, mert nem egy látogató oldalbetöltése indítja el a nehéz feladatot.
Hogyan akadályozom meg, hogy egy feladat kétszer fusson egyszerre?
A flock paranccsal egy zárolófájlhoz kötheted a futást. A flock -n kapcsolóval, ha az előző futás még tart, az új egyszerűen kimarad, és nem indul el mellette.
Mekkora legyen a riasztási küszöb egy hosszú futású feladatnál?
Szakmai tapasztalat alapján a jellemző futásidő másfél-kétszerese jó kiindulás. Ehhez előbb legalább egy hétig mérni kell a tényleges futásidőt, különben a küszöb csak tipp.
Befolyásolja a lassú háttérfolyamat a Google-helyezést?
Közvetve befolyásolhatja. A Google dokumentációja szerint lassú válasz vagy szerverhiba esetén a Googlebot csökkentheti a feltérképezést, a valós látogatói sebességadatok pedig a Core Web Vitals mérésekbe is bekerülhetnek. Helyezést a rendezett ütemezés nem garantál.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.