Linux szerveren a processzor- és memóriahasználatot túlzó szkriptek gyors megtalálása htop parancs segítségével

A Linux szervereken a htop parancs az egyik legpraktikusabb valós idejű folyamatfigyelő eszköz, amellyel gyorsan kiszűrhetjük azokat a szkripteket, amelyek túlzottan terhelik a processzort (CPU) és a memóriát (RAM). Az htop felületén a CPU%, MEM%, PID, USER, TIME+ és COMMAND oszlopok elemzésével könnyedén megállapíthatjuk, hogy mely PHP, Python, Node.js, cron, adatbázis vagy rendszerfolyamatok okozzák a szerver lassulását. Ezt követően a folyamat tulajdonosának, fájlútvonalának és működési céljának ellenőrzésével biztonságosan beavatkozhatunk.

Akár megosztott tárhelyről, VPS-ről, VDS-ről vagy dedikált szerverről van szó, a váratlan lassulások jelentős részét az ellenőrizetlenül futó szkriptek okozzák. Egy hibás WordPress bővítmény, végtelen ciklusba kerülő PHP fájl, túlzottan aktív cron feladat, optimalizálatlan adatbázis-lekérdezés vagy egy feltört webfájl percek alatt 100%-ra tornázhatja a CPU terheltségét. Ha a RAM fogyasztás is megugrik, akkor a szolgáltatások akadozhatnak, az MySQL kapcsolatok megszakadhatnak, a weboldalak 503-as hibát dobhatnak, vagy a Linux kernel az OOM Killer segítségével leállíthat bizonyos folyamatokat.

Ebben az útmutatóban lépésről lépésre bemutatjuk, hogyan telepítheted az htop-ot, hogyan értelmezheted az adatokat, miként különböztetheted meg a processzort és memóriát túlterhelő szkripteket, illetve hogyan találhatod meg a folyamat fájlútvonalát PID alapján, és hogyan avatkozhatsz be biztonságosan. Emellett kitérünk a biztonsági gyanúra, cron feladatok ellenőrzésére, log elemzésre és hatékony optimalizációs tippekre, hogy a problémák ne ismétlődjenek meg. Ha szervereden gyakoriak a forráskorlát miatti problémák, érdemes lehet megvizsgálni infrastruktúrádat a VPS szerver csomagok és a Magas teljesítményű webtárhely oldalakon található ajánlatok alapján.

Mi az a htop, és miért praktikusabb, mint a top parancs?

Az htop egy interaktív terminálos folyamatfigyelő eszköz Linux rendszereken, amely hasonló funkciókat kínál, mint a klasszikus top, de sokkal áttekinthetőbb, színes forráskijelzéssel, egyszerűbb rendezéssel, kereséssel, szűréssel és folyamatkezelési lehetőségekkel rendelkezik. Emiatt élő szervereken a gyors hibakereséshez az htop az egyik leggyakrabban használt eszköz a rendszergazdák körében.

Az htop segítségével az alábbi adatokat láthatod pillanatnyi állapotban:

• Minden folyamat által használt CPU százalék
• Minden folyamat által használt RAM százalék és mennyiség
• A folyamat PID azonosítója
• A folyamatot futtató felhasználó
• A parancssor vagy szkript neve
• A futási idő és prioritás
• A load average érték, összes RAM, swap és CPU magok kihasználtsága

Különösen webtárhely környezetben, ahol egy szerveren több weboldal, felhasználó vagy szolgáltatás fut egyszerre, nem elég csak az összesített erőforrás-felhasználást látni. Fontos tudni, hogy pontosan melyik felhasználóhoz, weboldalhoz, cron feladathoz vagy szkriptfájlhoz tartozik a túlzott terhelés. Ebben az esetben az htop gyors és hatékony elsődleges diagnosztikai eszköz.

htop telepítése: elosztástól függő parancsok

Számos modern Linux disztribúció alapból nem tartalmazza az htop-ot, de root vagy sudo jogosultsággal pillanatok alatt telepíthető. A telepítés előtt érdemes frissíteni a csomaglistát, különösen új szervereken, hogy elkerüljük a hibákat.

htop telepítése Ubuntu és Debian szervereken

Ubuntu vagy Debian alapú rendszeren az alábbi parancsokkal telepíthető:

sudo apt update

sudo apt install htop -y

Telepítés után az htop parancs beírásával indítható az eszköz. Ha nincs sudo jogosultságod, kérd a tárhelyszolgáltatód segítségét. Kezelhető VPS esetén általában van root hozzáférésed.

htop telepítése AlmaLinux, Rocky Linux, CentOS és RHEL rendszereken

RHEL-alapú disztribúciókon a csomagkezelő verziójától függően a dnf vagy yum használatos:

sudo dnf install htop -y

Régebbi CentOS verziókon előfordulhat, hogy az EPEL tárolót kell engedélyezni:

sudo yum install epel-release -y

sudo yum install htop -y

Ha a telepítés sikeres, az htop begépelésére színes monitorozó képernyő jelenik meg. Ha még új vagy a szerverkezelésben, akkor a Linux parancsok útmutató remek alapot adhat a továbbiakhoz.

Az htop képernyő értelmezése: mit jelentenek az oszlopok?

Az htop megnyitásakor a képernyő tetején a CPU magok, RAM, swap, folyamatok száma, szálak száma, load average és uptime adatok jelennek meg. Alul pedig a futó folyamatok listája látható. A hibakeresés során leggyakrabban az alábbi oszlopokat használjuk:

Fontos szem előtt tartani, hogy egy rövid ideig tartó CPU-terhelés nem feltétlenül probléma. Például biztonsági mentés, képtömörítés, cache tisztítás vagy forgalmi csúcs idején a processzor terheltsége átmenetileg megemelkedhet. A tényleges gondot az jelenti, ha ugyanaz a folyamat perceken át folyamatosan magas CPU vagy RAM használatot produkál, a load average pedig jóval meghaladja a CPU magok számát, és emiatt a webszolgáltatások válaszideje jelentősen romlik.

CPU-t túlterhelő szkriptek felderítése htop segítségével

A processzor túlzott használóinak megtalálásához az htop képernyőn nyomd meg az F6 gombot a rendezési oszlop kiválasztásához, vagy egyszerűen kattints a CPU% oszlop fejlécére, ha az egér támogatott. Így a legmagasabb CPU használatú folyamatok kerülnek a lista élére.

1. lépés: CPU% szerinti rendezés

Az htop futtatása közben rendezd a folyamatokat CPU használat szerint. Ha olyan folyamatot találsz, mint például php-fpm, php, python3, node, java, mysqld vagy bash, amely tartósan a lista tetején szerepel, jegyezd fel. Egyszálas processzornál a 100% a maximum, míg többmagos rendszeren a százalékérték akár 200% vagy 400% is lehet, ha több magot használ egyetlen folyamat.

2. lépés: PID és USER adatainak rögzítése

Jegyezd fel a gyanús folyamat PID számát és a USER mezőt. Például ha a PID 24819, USER siteuser, és a COMMAND oszlopban php /home/siteuser/public_html/wp-cron.php szerepel, akkor valószínűleg a szóban forgó weboldal cron vagy WordPress mechanizmusa okozza a problémát. Ha a COMMAND rövid, az htop beállításaiban engedélyezheted a teljes parancssor megjelenítését, vagy a ps paranccsal kérhetsz részletesebb információt.

3. lépés: A folyamat pontos parancssorának megtekintése

A PID alapján a részletes parancssor lekérdezéséhez használd a következő parancsot:

ps -fp PID

Példa:

ps -fp 24819

Ez kilistázza, hogy melyik fájlból indult a szkript. Ha a parancs például php /home/felhasznalo/public_html/index.php, akkor egy webes kérés indította. Ha viszont php /home/felhasznalo/public_html/wp-content/plugins/ismeretlen-bovitmeny/task.php, akkor egy bővítmény okozhatja a gondot.

4. lépés: Fájlútvonal és nyitott fájlok ellenőrzése

A folyamat által megnyitott fájlok és hálózati kapcsolatok megtekintéséhez használd az lsof eszközt:

lsof -p PID

Ez megmutatja, mely fájlokat, könyvtárakat, logokat és hálózati kapcsolatokat tart nyitva a folyamat. Webhoszting környezetben így azonosítható, hogy melyik weboldal mappája érintett. Ha például gyanús nevű PHP fájlt találsz a /home/pelda/public_html/wp-content/uploads mappában, az már biztonsági problémára utalhat. Ilyenkor nem elég a folyamat leállítása; szükséges a fertőzött fájlok eltávolítása, jelszavak cseréje, bővítményfrissítés és átfogó biztonsági vizsgálat. SSL és biztonságos kapcsolat beállításához hasznos lehet a SSL tanúsítvány megoldások oldal is.

RAM-t túlterhelő szkriptek megtalálása htop segítségével

A memóriahasználati problémák gyakran alattomosabbak, mint a CPU terhelés. A processzor használat hirtelen észrevehető lassulást okoz, míg a RAM kimerülése miatt szolgáltatások összeomolhatnak, a swap memória túlzott használata késleltetést eredményez, és az egész szerver lassul. Az htop képernyőjén a MEM% oszlop szerint rendezve listázhatod a legnagyobb memóriát felhasználó folyamatokat.

A MEM%, RES és swap kapcsolata

Az htop alapértelmezett nézetében a MEM% mutatja a memóriahasználat arányát. Bizonyos konfigurációkban megjelenik a VIRT, RES és SHR oszlop is. Különösen a RES érték fontos, mert ez mutatja a folyamat ténylegesen a fizikai memóriából foglalt területet. A VIRT ezzel szemben a folyamat által lefoglalt virtuális memóriát jelzi, ami nem feltétlenül egyezik meg a valódi RAM használattal, így önmagában megtévesztő lehet.

Például egy 4 GB memóriás VPS-en egyetlen PHP folyamat 900 MB RES használata már gyanús. Hasonlóan, ha egy Node.js alkalmazás memóriája idővel 200 MB-ról 1,5 GB-ra nő, az memóriaszivárgásra utalhat. MySQL vagy MariaDB esetén a magas memóriahasználat néha normális cache működés eredménye, de ezt a lekérdezési teljesítménnyel és buffer beállításokkal együtt kell értékelni.

A RAM-t túlhasználó szkriptek tipikus okai

• Végtelen ciklusba kerülő PHP, Python vagy Node.js kódok
• Nagy méretű CSV, XML vagy JSON fájlok egyszerre történő betöltése memóriába
• Nem optimalizált WordPress bővítmények és sablonfunkciók
• Képfeldolgozás, PDF generálás vagy videó konvertálás
• Nem megfelelő cache használat miatt ismétlődő, erőforrásigényes lekérdezések
• Botforgalom vagy támadás miatt egy szkript túl sokszor fut egyszerre
• Memóriaszivárgással működő hosszú ideje futó háttérszolgáltatások

Az ilyen problémák átmeneti megoldása lehet, ha a folyamatot csak megöljük (kill), de a tartós megoldáshoz elemezni kell, hogy a szkript mit csinál, milyen adatokat dolgoz fel, és miért nem szabadul fel a memória.

Keresés, szűrés és fa nézet az htop-ban

Ha a szerveren több száz folyamat fut, nehéz manuálisan átnézni őket. Az htop viszont praktikus gyorsbillentyűket kínál: F3-mal kereshetsz, F4-gyel szűrhetsz, F5-tel pedig fa nézetre válthatsz. A fa nézet különösen hasznos a szülő-gyermek folyamatok megjelenítéséhez. Így például jobban átláthatók a nginx vagy Apache alatti php-fpm child folyamatok, a cron által indított szkriptek vagy a supervisor által kezelt Node.js szolgáltatások.

Hasznos szűrési példák

• php beírásával csak a PHP folyamatok jelennek meg.
• python segítségével a Python szkriptek szűrhetők.
• wp-cron beírásával ellenőrizhető a WordPress cron működése.
• node parancsszóval a Node.js alkalmazások listája jelenik meg.
• Felhasználónév beírásával egy adott hosting fiók folyamatai szűrhetők.

Ezek a szűrők nagyban megkönnyítik a munkát többfelhasználós környezetben. Ha egy szerveren például 30 különböző weboldal fut, a USER oszlop és a parancssor együtt segít gyorsan beazonosítani, hogy melyik fiók okozza a problémát. Domain-alapú projektekhez a Domain ellenőrzés és regisztráció oldal nyújthat további segítséget a kezelőfelület egyszerűsítésében.

Biztonságos beavatkozási terv gyanús PID esetén

Ha találsz egy erőforrásokat túlhasználó folyamatot, az első reflex gyakran az kill -9 parancs használata lehet, hogy azonnal leállítsd. Ez azonban adatvesztéshez, félbehagyott fájlműveletekhez vagy szolgáltatás instabilitáshoz vezethet. Ezért egy körültekintőbb, biztonságosabb lépéssorozatot érdemes követni.

1. lépés: Folyamat dokumentálása

Először jegyezd fel a PID, USER, COMMAND, CPU%, MEM% és a folyamat futási idejét. Célszerű képernyőmentést készíteni az htop-ról. Ezek az adatok később segítenek összehasonlítani és megérteni az ismétlődő problémákat, illetve hasznosak lehetnek ügyfelek vagy kollégák számára is.

2. lépés: Fájlútvonal ellenőrzése

Az ps -fp PID és lsof -p PID parancsokkal ellenőrizd a folyamat fájlútvonalát. Ha az a webkiszolgáló gyökérkönyvtárában található, nézd át az alkalmazás logjait: WordPress esetén wp-content/debug.log, a webszerver access és error logjai, PHP-FPM esetén a slow log jelenthetnek fontos információkat.

3. lépés: Finomabb leállítás megkísérlése

Ha a folyamat valóban problémás, először próbáld meg normál módon leállítani:

kill PID

Várj néhány másodpercet, majd ellenőrizd az htop-ban, hogy bezárult-e a folyamat. Ha nem reagál, és komoly rendszerproblémát okoz, végső megoldásként alkalmazd a:

kill -9 PID

A kill -9 jelzés azonnali leállítást jelent, nem ad lehetőséget a folyamatnak a tisztításra, ezért adatbázis-műveletek vagy fájlírás esetén csak nagyon indokolt esetben használd.

4. lépés: Újraindulás esetén kiváltó ok felderítése

Ha a folyamat leállítása után pár másodpercen belül újraindul, akkor valószínűleg cron, systemd szolgáltatás, supervisor, webes kérés vagy botforgalom indítja újra. Vizsgáld meg a cron bejegyzéseket (crontab -l), a rendszer szolgáltatásait (systemctl status szolgaltatasnev), valamint a webszerver access logjait. Ha WordPress wp-cron miatt van a gond, nézd át a cron konfigurációt és cache beállításokat.

htop eredmények összekapcsolása logokkal

Az htop megmutatja, mi fogyasztja az erőforrásokat, de a logok segítenek megérteni, hogy miért. Ha ezeket nem kombináljuk, a diagnózis hiányos marad. Például egy PHP-FPM folyamat akár 180% CPU-t is használhat, de hogy mely URL vagy bot indította, azt csak az access logból tudhatjuk meg.

Fontosabb naplófájlok:

• Webszerver access log: A legforgalmasabb URL-eket mutatja.
• Webszerver error log: PHP hibákat, jogosultsági és 500-as hibákat jelez.
• PHP-FPM slow log: Lassú PHP szkriptek és függvények listája.
• MySQL slow query log: Több erőforrást igénylő SQL lekérdezések.
• Auth vagy secure log: Gyanús bejelentkezési kísérletek.
• Cron log: Az ütemezett feladatok futási ideje.

Például, ha az htop-ban magas CPU-val rendelkező PID ugyanekkor ezerszeres kérést kap a /wp-admin/admin-ajax.php címre az access logban, az valószínűleg bővítményhiba, botforgalom vagy nem jól megírt AJAX művelet. Ilyenkor együttesen kell gondolni WAF-ra, rate limitre, cache-re és bővítmény-optimalizációra. A weboldal gyorsításáról bővebben a weboldal sebesség optimalizálás oldalon olvashatsz.

Normál és problémás terhelés megkülönböztetése

Nem minden magas erőforrás-felhasználás jelent problémát. Figyelembe kell venni a szerver hardverét, a forgalom nagyságát, az alkalmazás típusát és a karbantartási műveleteket. Egy 2 magos VPS-en a 6-8-as load average tartósan már szűk keresztmetszet, míg egy 16 magos dedikált szerveren ugyanez teljesen elfogadható. Ezért mindig tudni kell a CPU magok számát a load average helyes értelmezéséhez.

Ez a táblázat segít elkülöníteni a valódi teljesítményproblémákat a felesleges riadalomtól. Különösen webshopoknál kampányok vagy raktárfrissítések idején előfordulhat átmeneti terhelésnövekedés, amely nem feltétlenül igényel azonnali beavatkozást. Ha azonban a felhasználói élményt rontja, akkor a szoftveroptimalizálást és a szerver kapacitását egyaránt érdemes átgondolni.

Biztonsági aggályok: lehet-e a túlterhelő szkript rosszindulatú?

Nem minden magas CPU- vagy RAM-fogyasztású szkript ártatlan hiba eredménye lehet. Feltört weboldalakon a támadók spamküldést, kriptobányászatot, proxy-forgalmat, DDoS botokat vagy hátsó ajtó szkripteket is futtathatnak. Az htop képernyőjén a szokatlan felhasználó alatt futó ismeretlen parancsok, véletlenszerű nevű fájlok, a /tmp könyvtárból induló binárisok vagy a public_html/uploads mappában futó PHP fájlok mind figyelmeztető jelek lehetnek.

Gyanús jelek

• COMMAND oszlopban érthetetlen, random karaktereket tartalmazó fájlnevek
• Fájlok futtatása a /tmp, /dev/shm vagy uploads mappákból
• Általában nem jellemző perl, python vagy bash folyamatok
• Nagy külső hálózati aktivitású folyamatok
• Egy felhasználó rövid idő alatt rengeteg folyamatot indít
• Webfájlokban friss, engedély nélküli módosítások

Ilyen esetben a folyamat azonnali leállítása előtt érdemes bizonyítékokat gyűjteni: parancs kimeneteket menteni, fájlengedélyeket ellenőrizni, a fertőzött fájlokat elkülöníteni, az összes panel és CMS jelszót megváltoztatni, valamint frissíteni a bővítményeket, témákat és magot. Emellett a kétfaktoros hitelesítés bevezetése és a felesleges írási jogosultságok megszüntetése hosszú távon jelentősen csökkenti a kockázatot.

Legjobb gyakorlatok a teljesítményproblémák megelőzésére

Az htop segít megtalálni a problémát, de a legnagyobb érték a hiba ismétlődésének elkerülése. Az alábbi lépések jelentősen csökkentik a CPU- és memóriaeredetű leállásokat Linux szervereken:

• Állítsd be a PHP memory_limit, max_execution_time és pm.max_children értékeket a szerver kapacitásának megfelelően.
• Használj cache-mechanizmust WordPress, Joomla vagy egyedi fejlesztések esetén.
• Távolítsd el a felesleges bővítményeket, témákat és modulokat.
• Optimalizáld a MySQL lekérdezéseket a slow query log alapján.
• Ne időzíts túl sok cron feladatot egyszerre, inkább oszd el időben.
• Alkalmazz rate limitet, robots.txt szabályokat és tűzfalat a botforgalom ellen.
• Rendszeresen forgass és figyeld az alkalmazás logokat, hogy elkerüld a túl nagy logfájlokat.
• Kövesd nyomon a szerver metrikáit nem csak krízishelyzetben, hanem rendszeres időközönként is.

Ha a problémák ellenére az erőforrás-felhasználás továbbra is magas, akkor nem csak a szoftver lehet a hibás. Lehet, hogy megnövekedett a forgalom, bővült az alkalmazás vagy kevés az infrastruktúra kapacitása. Ilyenkor érdemes skálázható VPS megoldásokban, több RAM-ban, gyorsabb NVMe meghajtóban vagy dedikált izolált szerverben gondolkodni. A megfelelő csomagok összehasonlításához nézd meg a Hosting csomagok és a vállalati szerver megoldások oldalakat.

Gyakorlati példa: CPU-terhelés hirtelen megugrása egy WordPress oldalon

Vegyünk egy valós példát: egy 4 magos, 8 GB RAM-os VPS-en több WordPress oldal fut. A felhasználók lassulást és időszakos 502-es hibát tapasztalnak. Az htop megnyitásakor a load average 12 körül mozog, minden CPU mag teljesen le van terhelve, és a lista élén sok php-fpm folyamat látható, amelyek ugyanahhoz a felhasználóhoz tartoznak.

Az F4-gyel a felhasználó neve szerinti szűrést alkalmazzuk. A legmagasabb CPU-t használó folyamat PID-jét feljegyezzük. A ps -fp PID utasítás php-fpm worker folyamatot mutat, az lsof -p PID pedig rámutat a /home/site/public_html/wp-content/plugins/example-importer/import.php fájlra. Az access logban ugyanabban az időben az importálást indító admin kérés és az ismétlődő AJAX hívások jelennek meg.

A megoldás: leállítjuk az importálást, kikapcsoljuk a bővítmény időzített feladatát, az importálást kisebb darabokra bontjuk, és a PHP max_execution_time értékét módosítjuk. Emellett a WordPress wp-cron helyett rendszer szintű cron fut. Ennek eredményeként a load average 12-ről 1,8-ra csökken, a CPU terheltség normalizálódik, és a weboldalak válaszideje jelentősen javul. Ez a példa jól mutatja, hogy az htop önmagában és más eszközökkel, mint a ps, lsof és log elemzés, együtt milyen hatékony.

Gyakori hibák az htop használata során

• Csak a legnagyobb terhelésű folyamat leállítása anélkül, hogy az okát keresnénk.
• A VIRT értékét valódi memóriahasználatként értelmezni.
• A MySQL cache célú magas RAM használatát azonnali problémának tekinteni.
• A kill -9 parancs elsőként való alkalmazása.
• Naplók vizsgálata nélkül az alkalmazás vagy felhasználó hibáztatása.
• A load average érték értelmezése CPU magok számától függetlenül.
• Biztonsági gyanú esetén a fájlok integritásának figyelmen kívül hagyása.

Ezek az alapvető hibák nemcsak növelik a leállási időt, hanem felesleges adatvesztéshez is vezethetnek. A rendszergazdai diagnózisban a helyes értelmezés és megfontolt beavatkozás többet ér, mint a gyors, de meggondolatlan lépések.

Gyakran ismételt kérdések

Mire jó a Linux szerveren az htop parancs?

Az htop valós időben mutatja a futó folyamatok CPU, RAM, felhasználó, PID és parancs adatait, így gyorsan megtalálhatók a túlzott erőforrás-fogyasztók.

Hogyan találom meg az htop segítségével a CPU-t túlterhelő szkriptet?

Rendezd a folyamatokat CPU% szerint, jegyezd fel a hosszú ideig magas értékű folyamat PID-jét és felhasználóját, majd a ps -fp PID és lsof -p PID parancsokkal ellenőrizd a szkript helyét és működését.

Memóriahasználatnál a MEM% vagy a VIRT az irányadó?

RAM elemzéskor a MEM% és különösen a RES érték a relevánsabb, mert a VIRT csak a lefoglalt virtuális memóriát jelzi, ami nem feltétlenül egyezik meg a tényleges fizikai használattal.

Jó-e azonnal kill -9-cel leállítani a túlterhelő folyamatot?

Általában nem. Előbb dokumentáld a folyamatot, ellenőrizd a fájlútvonalát, próbáld meg a normál kill parancsot, és csak ha az nem működik, és a rendszer egészsége veszélyben van, akkor használd a kill -9-et.

Magas CPU használat mindig támadás jele?

Nem. Biztonsági mentés, adatimport, cache építés vagy forgalmi csúcs is okozhatja. Azonban a szokatlan fájlnevek, a /tmp vagy uploads mappából futó szkriptek, illetve ismeretlen felhasználók alatt futó folyamatok biztonsági kockázatot jelezhetnek.

Összefoglalva, a Linux szerveren az htop parancs gyors, praktikus és hatékony eszköz a CPU- és memóriaigényes szkriptek felderítésére. A legjobb eredményhez érdemes az htop adatait PID elemzéssel, lsof kimenettel, cron ellenőrzéssel és naplófájlok alapos vizsgálatával kombinálni. Ha szervereden gyakran jelentkeznek erőforrás-problémák, gondold át mind a szoftveres optimalizációt, mind az infrastruktúra fejlesztését. Szükség esetén a Hostragons hosting, VPS és SSL megoldásait ingyenesen összehasonlíthatod, hogy megtaláld a projektedhez leginkább megfelelő megoldást.