Příkaz htop na Linux serveru patří mezi nejefektivnější nástroje pro sledování procesoru (CPU) a paměti (RAM) v reálném čase a rychlé odhalení skriptů, které tyto zdroje přetěžují. Díky přehledné obrazovce htop snadno zjistíte, které PHP, Python, Node.js, cron, databázové nebo systémové procesy server nejvíce zatěžují – a dále podle vlastníka procesu, cesty k souboru a účelu běhu můžete bezpečně zasáhnout a problém vyřešit.
Ať už provozujete sdílený hosting, VPS, VDS nebo dedikovaný server, mnohé náhlé zpomalení systému vznikají právě nekontrolovanými skripty. Typickým příkladem je chybně fungující WordPress plugin, PHP soubor uvězněný v nekonečné smyčce, náročný cron úkol, neoptimalizovaný databázový dotaz nebo nakažený webový soubor, který během několika minut vyčerpá téměř 100 % CPU. Při zvyšující se spotřebě RAM pak mohou služby zamrznout, MySQL spojení vypadnou, weby začnou vracet chybu 503 nebo Linux jádro aktivuje OOM Killer a ukončí některé procesy.
V tomto článku vás krok za krokem provedeme instalací htop, vysvětlíme, jak správně číst jeho obrazovku, jak rozpoznat zdroje přetěžující CPU a RAM, jak zjistit přesnou cestu k souborům přes PID a jak bezpečně zasáhnout do běžících procesů. Neopomeneme ani tipy na bezpečnostní kontroly, ověření cron úloh, analýzu logů a doporučené optimalizace, aby se problém neopakoval. Pokud často řešíte limity zdrojů na svém serveru, doporučujeme také prohlédnout VPS serverové balíčky a Web hosting s vysokým výkonem pro vhodnější infrastrukturu.
Co je htop a proč je lepší než příkaz top?
htop je interaktivní nástroj pro monitorování běžících procesů v Linuxu v terminálu. Na rozdíl od klasického příkazu top nabízí přehlednější a barevné rozhraní, snadnější třídění, vyhledávání, filtrování a správu procesů. Díky tomu je htop první volbou většiny správců serverů při rychlém zjišťování problémů v živém prostředí.
V htop můžete na první pohled sledovat například:
- Procentuální využití CPU každým procesem
- Procentuální a absolutní využití RAM jednotlivými procesy
- PID (identifikační číslo procesu)
- Uživatele, který proces spustil
- Název příkazu nebo skriptu
- Délku běhu a prioritu procesu
- Load average, celkovou RAM, swap a využití CPU jader
Na hostingovém serveru, kde běží více webů, uživatelů nebo služeb, není dostačující sledovat jen celkovou spotřebu zdrojů. Je klíčové rychle identifikovat, kterému uživateli, webu, cron úloze nebo skriptu problém patří. Právě v tom vám příkaz htop pomůže jako rychlá první diagnostika.
Instalace htop: příkazy podle distribuce
Na mnoha moderních Linux distribucích nemusí být htop předinstalovaný. Pokud máte root nebo sudo oprávnění, zvládnete instalaci během několika sekund. Doporučujeme před instalací aktualizovat seznam balíčků, což minimalizuje chyby, zejména na nových serverech.
Instalace na Ubuntu a Debian
Na Ubuntu nebo Debian serveru zadejte:
sudo apt update
sudo apt install htop -y
Po instalaci spustíte htophtop. Pokud nemáte oprávnění sudo, kontaktujte svého poskytovatele hostingu. U VPS s plnou správou obvykle root přístup máte.
Instalace na AlmaLinux, Rocky Linux, CentOS a RHEL
Na systémech založených na RHEL použijte balíčkovací systém podle verze, například:
sudo dnf install htop -y
U starších verzí CentOS může být potřeba nejprve povolit repozitář EPEL:
sudo yum install epel-release -y
sudo yum install htop -y
Pokud instalace proběhne úspěšně, zadáním htop se otevře barevná obrazovka se seznamem procesů. Pokud s Linuxem začínáte, doporučujeme také průvodce příkazy Linuxu pro rychlé seznámení.
Jak číst obrazovku htop: význam sloupců
Při spuštění htop vidíte v horní části indikátory CPU jader, RAM, swapu, počtu úloh, vláken, load average a uptime. Ve spodní části je seznam procesů. Pro diagnostiku problémů jsou zásadní tyto sloupce:
| Sloupec | Co znamená | Kdy být podezřívavý? |
|---|---|---|
| PID | Unikátní číslo procesu | Potřebujete pro zjištění cesty a dalších detailů |
| USER | Linux uživatel, který proces spustil | Pokud proces běží pod neočekávaným uživatelem, je třeba prověřit |
| CPU% | Aktuální procentuální využití CPU procesem | Procesy trvale využívající 80–100 % CPU jsou podezřelé |
| MEM% | Podíl RAM využitý procesem z celkové paměti | Pokud jeden skript využívá přes 20 % RAM, je to riziko |
| TIME+ | Celkový čas CPU využitý procesem | Zobrazuje dlouhodobé zatížení, ne krátkodobé špičky |
| COMMAND | Název spuštěného příkazu nebo skriptu | U php, python, node, bash, java apod. je třeba zjistit přesnou cestu |
Důležité je uvědomit si, že krátkodobé výkyvy CPU nemusí znamenat problém – například zálohy, optimalizace obrázků, vyprázdnění cache nebo špičky v provozu CPU zatíží jen přechodně. Skutečný problém nastává, pokud stejný proces dlouhodobě žere vysoké procento CPU nebo RAM, load average přesahuje počet jader a weby reagují pomalu či vůbec.
Jak najít skripty žeroucí CPU pomocí htop
Pro identifikaci procesů s vysokým využitím CPU můžete v htop stisknout klávesu F6 a zvolit řazení podle CPU %, nebo kliknout na záhlaví sloupce CPU%, pokud váš terminál podporuje myš. Procesy nahoře mají největší zátěž CPU.
Krok 1: Seřaďte procesy podle CPU%
Seřaďte procesy podle využití CPU. Pokud se mezi vrchními procesy často objevuje například php-fpm, php, python3, node, java, mysqld nebo bash, poznamenejte si jejich PID. Na jedno jádro může proces využívat až 100 %, na vícejádrovém serveru může být hodnota i 200 % či 400 %, protože proces využívá více jader.
Krok 2: Zaznamenejte PID a uživatele
Zapište si PID a uživatele procesu. Například pokud PID 24819 běží pod uživatelem siteuser a příkaz je php /home/siteuser/public_html/wp-cron.php, pravděpodobný problém je v cron úloze nebo WordPressu daného webu. Pokud je příkaz příliš krátký, v htop nastavte zobrazení kompletního příkazového řádku nebo použijte příkaz ps (viz další krok).
Krok 3: Zjistěte přesný příkaz přes PID
Pro detailní zobrazení příkazu použijte:
ps -fp PID
Příklad:
ps -fp 24819
Výstup ukáže, ze kterého souboru skript běží. Například:
php /home/uzivatel/public_html/index.php– může jít o návštěvníkův požadavekphp /home/uzivatel/public_html/wp-content/plugins/neznamy-plugin/task.php– může znamenat problém s pluginem
Krok 4: Zkontrolujte cestu k souboru a otevřené soubory
Pomocí nástroje lsof můžete zjistit, jaké soubory proces používá:
lsof -p PID
Výpis ukáže otevřené soubory, knihovny, logy a síťová spojení. Ve webhostingovém prostředí tak snadno zjistíte, která složka webu je aktivní. Pokud například objevíte v adresáři /home/example/public_html/wp-content/uploads podezřelý PHP soubor s neznámým názvem, může to být známka narušení bezpečnosti. V takovém případě nestačí proces jen ukončit – je potřeba provést očistu, změnit hesla, aktualizovat pluginy a provést bezpečnostní audit. Pro nastavení bezpečného SSL připojení doporučujeme také řešení SSL certifikátů.
Jak najít skripty žeroucí RAM pomocí htop
Problémy s RAM jsou často méně nápadné než s CPU. Vysoké využití CPU zpravidla způsobuje okamžité zpomalení, zatímco vyčerpání RAM může vést k neočekávanému padání služeb, intenzivnímu využívání swapu a celkovému zpomalení serveru. V htop řaďte procesy podle sloupce MEM % a vyhledejte ty s největší spotřebou paměti.
Porozumění MEM%, RES a Swap
Standardní zobrazení htop ukazuje MEM %, což je procento z celkové RAM. Některé konfigurace zobrazují také sloupce VIRT (virtuální paměť), RES (rezidentní – skutečně fyzicky využívaná paměť) a SHR (sdílená paměť). Pro analýzu je nejdůležitější hodnota RES, protože ukazuje skutečnou spotřebu RAM procesem. Hodnota VIRT může být zavádějící, protože zahrnuje i rezervovanou, ale nevyužitou paměť.
Například na VPS s 4 GB RAM není normální, když jeden PHP proces zabere 900 MB RES. Pokud Node.js aplikace postupně roste z 200 MB na 1,5 GB, může jít o paměťový únik. Vysoké využití RAM databází MySQL nebo MariaDB může být v některých případech v pořádku kvůli cache, ale je potřeba sledovat výkon dotazů a nastavení bufferů.
Typické příčiny vysoké spotřeby RAM
- PHP, Python nebo Node.js skripty uvězněné v nekonečné smyčce
- Nahrávání velkých CSV, XML nebo JSON souborů do paměti najednou
- Nefunkční nebo neoptimalizované WordPress pluginy a funkce šablon
- Specifické úlohy jako zpracování obrázků, tvorba PDF nebo převod videa
- Nedostatečné využití cache, které vede k opakovaným náročným dotazům
- Boty nebo útoky způsobující masivní spuštění stejného skriptu
- Dlouhodobě běžící služby s paměťovým únikem
Zabíjet procesy příkazem kill je jen dočasné řešení. Klíčové je zjistit, proč skript paměť nevrací a jak ho správně optimalizovat.
Vyhledávání, filtrování a stromová struktura v htop
Na serveru se stovkami procesů je manuální hledání náročné. htop poskytuje praktické klávesové zkratky: F3 pro vyhledávání, F4 pro filtrování a F5 pro přepnutí do stromového zobrazení. Stromové zobrazení je užitečné pro rychlé zjištění vztahů rodič-potomek mezi procesy. Můžete tak snadno vidět php-fpm child procesy pod nginx nebo Apache, cron úlohy, případně Node.js procesy spravované supervisorem.
Praktické příklady filtrování
- Zadejte
phppro zobrazení pouze PHP procesů. - Vyhledejte
pythonpro filtrování Python skriptů. - Hledejte
wp-cronpro kontrolu WordPress cron aktivit. - Vyfiltrujte
nodepro sledování Node.js aplikací. - Filtrovat podle uživatele pro zobrazení procesů konkrétního hostingového účtu.
Tyto filtry výrazně pomáhají při správě více uživatelů a webů na jednom serveru. Pokud potřebujete zjednodušit správu doménových projektů, doporučujeme Dotaz na doménu a registraci.
Bezpečný postup zásahu u podezřelých PID
Při zjištění procesu s vysokou spotřebou je lákavé ho ihned ukončit příkazem kill -9. Tento postup ale může vést ke ztrátě dat, neukončeným zápisům nebo nestabilitě služeb. Lepší je postupovat opatrně a podle plánu.
1. Zdokumentujte si proces
Zapište PID, uživatele, příkaz, hodnoty CPU%, MEM% a čas běhu. Pokud možno, pořiďte screenshot htop. Tyto záznamy usnadní případné opakované analýzy nebo komunikaci s klienty v agenturních či e-shop projektech.
2. Potvrďte cestu k souboru
Pomocí ps -fp PID a lsof -p PID ověřte, kde se spouštěný skript nachází. Pokud jde o webový adresář, prohlédněte logy aplikace – WordPress má wp-content/debug.log, webserver access a error logy, PHP-FPM slow logy a podobně.
3. Zkuste nejprve jemné ukončení
Odešlete standardní signál ukončení:
kill PID
Počkejte pár vteřin a zkontrolujte, zda proces zmizel z htop. Pokud se neukončí a ohrožuje stabilitu serveru, použijte až jako poslední možnost:
kill -9 PID
Signál kill -9 proces ukončí bez možnosti úklidu, proto je vhodný jen v krajních případech, například u databázových operací nebo záloh buďte zvlášť opatrní.
4. Pokud se proces restartuje, hledejte příčinu
Pokud se proces po ukončení okamžitě znovu spouští, může za tím stát cron, systemd služba, supervisor, webový požadavek nebo bot. Prozkoumejte cron příkazy pomocí crontab -l, stav služeb příkazem systemctl status nazev_sluzby a webový provoz v access logu. Pokud je problém ve WordPress wp-cron, ověřte nastavení skutečného cron úložiště a cache systémy.
Propojení zjištění z htop s logy

htop ukazuje, co zatěžuje systém, ale logy prozradí proč. Bez analýzy logů může být diagnostika neúplná. Například proces php-fpm může mít v htop 180 % CPU, ale bez přístupu k access logům nepoznáte, které URL nebo bot to způsobuje.
Užitečné logy k prozkoumání:
- Access log webserveru – ukazuje nejvytíženější URL
- Error log webserveru – chyby PHP, problémová oprávnění, chyby 500
- PHP-FPM slow log – pomalé PHP skripty a funkce
- MySQL slow query log – náročné SQL dotazy
- Auth nebo secure log – pokusy o neoprávněný přístup
- Cron log – historie spouštění plánovaných úloh
Pokud htop ukazuje vysoké CPU u PID, a současně access log zaznamenává tisíce požadavků na /wp-admin/admin-ajax.php, problém může být v pluginu, botu nebo špatně navrženém AJAX. V takovém případě je vhodné aktivovat WAF, omezit požadavky rate limit, použít cache a optimalizovat pluginy. Pro komplexní vylepšení výkonu doporučujeme Optimalizace rychlosti webových stránek.
Jak rozlišit normální a problematickou zátěž
Vysoké využití zdrojů nemusí vždy znamenat krizovou situaci. Záleží na hardwarovém vybavení serveru, zatížení provozem, typu aplikace a probíhající údržbě. Například u VPS se 2 jádry je load average 6–8 po delší dobu varovné, zatímco u dedikovaného serveru s 16 jádry může být stejná hodnota v pořádku. Při hodnocení load average proto vždy zohledněte počet CPU jader.
| Situace | Možný důvod | Doporučený postup |
|---|---|---|
| Krátkodobé CPU 100 %, pak návrat k normálu | Dočasný výpočetní špičkový úkol | Ověřit v logu, zásah není nutný |
| Stejný PID dlouhodobě vysoký CPU | Nekonečná smyčka nebo náročná úloha | Zjistit cestu k souboru, analyzovat skript |
| RAM neustále roste bez poklesu | Paměťový únik | Prověřit kód služby a nastavení workerů |
| Rychlý nárůst využití swapu | Nedostatečná fyzická paměť | Optimalizovat RAM nebo navýšit kapacitu |
| Velké množství stejných PHP procesů | Boty nebo extrémní provoz | Kontrola access logů, firewallu a cache |
Tento přehled pomáhá rozlišit paniku od skutečného výkonového problému. Například e-shopy v době kampaní nebo aktualizací mohou mít dočasný nárůst zátěže, který je normální. Pokud ale ovlivňuje uživatelský komfort, je potřeba optimalizovat aplikace a případně rozšířit kapacity serveru.
Bezpečnostní podezření: může být zdrojový skript škodlivý?
Vysoce zatěžující skript nemusí být vždy chybný, často může jít o známku kompromitace serveru. Útočníci mohou využívat napadené weby k rozesílání spamu, těžbě kryptoměn, proxy provozu, DDoS útokům nebo k instalaci zadních vrátek. V htop sledujte procesy pod neobvyklými uživateli, náhodně pojmenované soubory, spouštěné binárky z adresářů jako /tmp nebo public_html/uploads – to jsou varovné signály.
Známky podezřelých procesů
- Nečitelná nebo náhodná jména souborů v COMMAND
- Procesy běžící z
/tmp,/dev/shmnebo složky uploads - Nepřirozené perl, python nebo bash procesy
- Procesy s vysokým odchozím síťovým provozem
- Jednotlivec spouští mnoho procesů během krátké doby
- Neautorizované změny souborů na webu
Při podezření vždy zachovejte důkazy – výpis procesů, cesty, logy. Následně upravte oprávnění, izolujte škodlivé soubory, změňte hesla panelů a CMS, aktualizujte jádro i pluginy a proveďte bezpečnostní audit. Dlouhodobou prevencí je dvoufaktorové ověřování v administraci a omezení zbytečných zápisových práv.
Nejlepší postupy, jak zabránit opakování výkonových problémů
Najít příčinu v htop je základ, ale nesmíte zapomenout na kroky, které zabrání dalším výpadkům:
- Správně nastavte PHP hodnoty
memory_limit,max_execution_timeapm.max_childrenpodle kapacity serveru - Využívejte cache systémy u WordPressu, Joomla a dalších aplikací
- Odstraňujte nepotřebné pluginy, šablony a moduly
- Optimalizujte pomalé SQL dotazy pomocí
slow query log - Nespouštějte všechny cron úlohy najednou, rozložte je časově
- Proti botům a škodlivému provozu nastavte rate limiting, robots.txt a firewall pravidla
- Pravidelně spravujte logy, aby nepřetěžovaly disk a RAM
- Sledujte metriky serveru nejen v krizových momentech, ale průběžně
Pokud i přes optimalizace zůstává spotřeba vysoká, může být problém na straně aplikace, zvýšeného provozu nebo nedostatečné infrastruktury. V takovém případě zvažte přechod na škálovatelný VPS, rozšíření RAM, rychlejší NVMe disky nebo dedikovaný server. Pro srovnání možností navštivte Hostingové balíčky a řešení korporátních serverů.
Příklad z praxe: Výkyv CPU na WordPress webu
Představme si reálný případ: VPS s 4 jádry a 8 GB RAM hostí několik WordPress webů. Uživatelé hlásí zpomalení a občas chybu 502. Po spuštění htop je load average na 12, všechna jádra jsou vytížená a mezi procesy opakovaně vidíme mnoho php-fpm procesů pod stejným uživatelem.
Filtrujeme procesy podle uživatele (klávesou F4) a zaznamenáme PID jednoho z nejvíce zatěžujících procesů. Pomocí ps -fp PID zjistíme, že jde o php-fpm worker, lsof -p PID ukáže přístup k souboru /home/site/public_html/wp-content/plugins/example-importer/import.php. V access logu vidíme, že v danou chvíli tento soubor spouští administrátor a následují četné AJAX požadavky.
Řešení spočívá v pozastavení importu, deaktivaci naplánované úlohy, rozdělení importu na menší části a úpravě PHP parametru max_execution_time. Namísto wp-cron se zavádí skutečný systémový cron. Výsledkem je pokles load average z 12 na 1,8, návrat CPU do normálu a výrazné zrychlení odezvy webu. Tento příklad ukazuje sílu kombinace htop, ps, lsof a analýzy logů.
Časté chyby při používání htop
- Omezit se jen na ukončení nejvíce zatěžujícího procesu bez zjištění příčiny
- Považovat hodnotu VIRT za skutečnou spotřebu RAM
- Interpretovat MySQL cache využití RAM jako problém
- Okamžitě používat
kill -9místo šetrného ukončení - Obviňovat aplikaci nebo uživatele bez kontroly logů
- Vykládat load average bez ohledu na počet CPU jader
- Nedávat pozor na možné bezpečnostní hrozby a nezkoumat integritu souborů
Vyvarování se těchto chyb významně zkracuje dobu výpadků a snižuje riziko ztráty dat. Správná diagnostika je často důležitější než rychlá reakce.
Často kladené otázky
Co dělá příkaz htop na Linux serveru?
htop zobrazuje v reálném čase informace o běžících procesech – kolik CPU a RAM využívají, pod jakým uživatelem běží, jejich PID a příkaz. Pomáhá rychle najít skripty přetěžující server.
Jak najdu skript žeroucí CPU pomocí htop?
Seřaďte procesy podle CPU%, poznamenejte si PID a uživatele podezřelých procesů. Poté si přes příkazy ps -fp PID a lsof -p PID ověřte, jaký skript běží a odkud.
Co je důležitější při sledování RAM – MEM% nebo VIRT?
Pro analýzu je důležitější MEM% a především hodnota RES (rezidentní paměť), protože VIRT zobrazuje i rezervovanou paměť, která nemusí být skutečně využitá.
Je správné proces hned ukončit příkazem kill -9?
Obvykle ne. Nejprve proces identifikujte, zkuste ho ukončit standardním signálem kill PID. Pouze pokud to nefunguje a hrozí poškození systému, použijte kill -9.
Znamená vysoké využití CPU v htop vždy útok?
Ne vždy. Může jít o zálohy, importy, tvorbu cache nebo špičky provozu. Podezřelé jsou ale náhodné názvy souborů, procesy z /tmp, uploads a neznámí uživatelé.
Shrnuto, příkaz htop je na Linux serveru rychlý a praktický nástroj k nalezení skriptů přetěžujících CPU a RAM. Nejlepší výsledky dosáhnete kombinací htop s analýzou PID, výstupy lsof, kontrolou cron úloh a logů. Pokud se problémy se zdroji na serveru často opakují, je vhodné nejen ladit software, ale zvážit i vhodnější hostingovou infrastrukturu. Pro porovnání hostingových řešení, VPS a SSL certifikátů bez prodejního tlaku navštivte nabídku Hostragons.