Lassú gép? MI-ügynök a háttérben

MI-t vagy saját ügynökrendszert használ? A háttérben annak a munkája is lefoglalhatja a gépet. Érdemes megnézni, melyik folyamat használja a processzort és a memóriát, mielőtt bármit leállítana.

Hangos a ventilátor, lassan nyílnak meg a programok, pedig látszólag alig használja a gépet? A számítógép attól még dolgozhat, hogy nincs előtte nyitott ablak: frissítést telepíthet, fájlokat szinkronizálhat, vírusellenőrzést végezhet, vagy egy korábban elindított feladat folytatódhat a háttérben. Néha viszont egy program nem áll le rendesen, és munka nélkül is lefoglalja a processzort vagy a memóriát.

A háttérben dolgozhat idegen kód, az Ön saját MI-ügynöke, vagy egyszerűen beakadhatott egy folyamat. Először azt érdemes kideríteni, mi dolgozik, mennyi ideje, és indokolt-e a terhelése. Egy nyitva felejtett böngészőlap, egy sokáig tartó frissítés és egy beragadt ügynök hasonló tünetet okozhat, de más megoldást igényel.

Az útmutató egyszerű ellenőrzéssel kezdődik, amelyet bárki meg tud nézni a Windows Feladatkezelőjében. Utána egy valós esetből indulva megmutatjuk a részletesebb Windows–Linux/WSL hibakeresést is: hova kell beírni a parancsokat, mit jelent a kimenet, és mikor nem szabad még semmit leállítani.

Mi történhet a háttérben?

A processzor – a Feladatkezelőben CPU – végzi a számításokat. A memória, vagyis RAM a futó programok munkaterülete. Ha sok feladat verseng értük, az Ön által használt alkalmazásnak is kevesebb erőforrás jut. A ventilátor közben a keletkező hőt próbálja elvezetni. A hang önmagában ezért nem hibajel: az számít, hogy a gép ténylegesen végez-e olyan munkát, amely ezt indokolja.

• Rövid, érthető terhelés: programindítás, rendszerfrissítés, vírusellenőrzés vagy videófeldolgozás. Figyelje meg, csökken-e a terhelés a feladat végén.
• Sok párhuzamos feladat: böngészőlapok, felhős szinkronizálás, helyi MI-modell és más alkalmazások együtt is túl soknak bizonyulhatnak.
• Saját MI-ügynökrendszer: az ügynök több programot, böngészőt vagy számítást indíthat el. Ellenőrizze, hogy ezek még a kívánt feladaton dolgoznak-e, és csökken-e a terhelés a munka befejezésével.
• Beragadt háttérmunka: a látható ablak bezárult, de a hozzá tartozó folyamat tovább fut, vagy hibás ciklusban ismétli ugyanazt a műveletet.
• Más eredetű lassulás: a lemez túlterhelése, kevés szabad tárhely vagy hűtési probléma is számíthat. Alacsony CPU mellett jelentkező melegedést nem old meg feltétlenül egy folyamat leállítása.
• Biztonsági probléma: szintén lehetséges, de ehhez a magas terhelésen túl más jeleket is keresni kell.

A biztonságos sorrend: nézze meg a terhelést → azonosítsa az érintett programot → mentse a munkát → csak ezután döntsön beavatkozásról. Céges gépen a vállalati szabályok és az informatikai támogatás útmutatása az elsődleges.

Lehet egyszerű beragadt folyamat – de akár biztonsági probléma is

Észrevette már, hogy a számítógépe úgy kezd el dolgozni, mintha komoly feladatot végezne, miközben Ön éppen alig csinál valamit?

Felpörög a ventilátor. Melegszik a laptop. A böngésző vagy más programok lassabban reagálnak. Gyorsabban fogy az akkumulátor. Vagy egyszerűen csak azt érzi: valami nincs rendben a géppel.

Sokan ilyenkor újraindítják a számítógépet, és ha a jelenség megszűnik, nem foglalkoznak vele tovább. Pedig érdemes legalább egyszer megnézni, mi okozta a terhelést.

A háttérben lehet egészen ártalmatlan ok: egy beragadt alkalmazás, egy hibás háttérszolgáltatás, túl sok párhuzamos munkafolyamat, vagy egy fejlesztői környezet valamelyik komponense. De ugyanilyen tüneteket okozhat nem kívánt vagy rosszindulatú program is.

A magas terhelés önmagában tehát nem bizonyít támadást. Viszont jelzésértékű. Ha megtanuljuk felismerni, mi számít normálisnak a saját gépünkön, sokkal hamarabb észrevehetjük, amikor valami eltér a megszokottól.

ELSŐ LÉPÉS: NÉZZÜK MEG, MIT CSINÁL A GÉP

Windows alatt ehhez nem kell külön programot telepíteni.

Nyomja meg:
Ctrl + Shift + Esc

Ezzel megnyílik a Feladatkezelő.

Első körben mindössze két értéket érdemes megnézni:

• CPU / Processzor
• Memória / RAM

Ha éppen nem végez komoly feladatot, de a CPU több percen keresztül 80–100% közelében marad, érdemes megkeresni az okát. Ugyanez igaz arra, ha a memória tartósan nagyon magas, és a gép közben érezhetően lassul.

Egy rövid csúcs természetesen nem feltétlenül probléma. Egy frissítés, vírusellenőrzés, videófeldolgozás vagy nagyobb számítás rövid időre teljesen kihasználhatja a processzort.

A kérdés inkább ez:
mi használja az erőforrást, mióta, és van-e rá ésszerű magyarázat?

MIÉRT FONTOS EZ AKKOR IS, HA MESTERSÉGES INTELLIGENCIÁVAL DOLGOZUNK?

Az AI-alapú fejlesztői és irodai munkakörnyezetek egyre több háttérfolyamatot használhatnak.

Egy kódoló agent vagy fejlesztői környezet mögött futhat például Node.js, Python, böngészőautomatizálás, lokális modell, adatbázis, WSL/Linux környezet vagy több párhuzamos worker. Ezek közül sok teljesen legitim.

A probléma nem az, hogy futnak.

A probléma az, ha egy folyamat befejezte volna a munkáját, de továbbra is jelentős CPU-t vagy memóriát foglal; ha egy agent hibás ciklusba kerül; vagy ha a Windows és a Linux/WSL közötti réteg valamelyik komponense ragad be.

AI-val dolgozó munkaállomáson ezért különösen hasznos néha ránézni arra, hogy:

• a nagy terhelés tényleges munkához kapcsolódik-e;
• egy régi folyamat nem maradt-e órák vagy napok óta aktív;
• a memória visszaesik-e a feladat befejezése után;
• és van-e elegendő tartalék ahhoz, hogy a gépet közben normál munkára is lehessen használni.

Érdemes annyi memória-tartalékot hagyni, hogy a Windows és a közben használt alkalmazások is kényelmesen működjenek. Erre nincs minden gépre érvényes százalékos szabály. Ha a memória tartósan majdnem megtelik, a lemezaktivitás is megnő és a programok lassulnak, az együtt már erőforráshiányra utalhat. A magas memóriaérték önmagában nem teljes hibadiagnózis.

EGY VALÓS ESET TANULSÁGA

A cikk apropóját egy valós, anonimizált eset adta.

Egy Windows-alapú munkaállomáson több fejlesztői és AI-alapú folyamat futott. A gép feltűnően hangossá vált. A Feladatkezelő közel teljes CPU-terhelést és nagyon magas memóriahasználatot mutatott.

Elsőre több magyarázat is elképzelhető volt:

• túl sok párhuzamos AI/fejlesztői folyamat;
• Linux alatt beragadt program;
• memóriaszivárgás vagy fölöslegesen ismétlődő számítás;
• háttérben futó hibás szolgáltatás;
• vagy akár biztonsági incidens.

A vizsgálat során azonban egy érdekes eltérés jelent meg: Windows szerint a Linux/WSL-hez kapcsolódó rész nagyon erősen terhelte a processzort, miközben Linuxon belül a folyamatlista nagyrészt nyugodt volt.

Ez fontos nyom.

Ha a „guest”, vagyis a Linux oldal alig számol, miközben a Windows „host” oldal mégis nagyon magas WSL-terhelést mutat, akkor nem biztos, hogy maga a Linux-program a hibás. Lehetséges, hogy a Windows–WSL közötti egyik hostfolyamat került hibás állapotba.

A problémás hostfolyamat azonosítása és kontrollált leállítása/újraindítása után a teljes CPU-terhelés közel 100%-ról néhány százalékra esett vissza.

A legfontosabb tanulság:
ugyanaz a tünet – hangos gép, magas CPU, magas memória – lehet normális számítás, hibás folyamat vagy akár támadásgyanú is. A különbséget nem érzésre, hanem méréssel érdemes eldönteni.

Ha mélyebbre szeretne menni

Ha Windows mellett Linuxot/WSL-t is használ, vagy szeretné pontosan azonosítani a nagy terhelést okozó folyamatot, a következő lépések és parancsok segítenek a részletesebb vizsgálatban.

Hibakeresés parancsokkal – Windows és WSL

Hogyan használja a parancsokat? A kódmezőből a teljes parancsot másolja ki, illessze a PowerShell-ablakba, majd nyomjon Entert. A több sorból álló parancs összetartozik: a sorvégi függőleges vonal a következő műveletnek adja tovább az eredményt. Ne másoljon mellé magyarázatot vagy képen látható példakimenetet. A vizsgálati parancsok adatot kérdeznek le; a később külön jelzett wsl --shutdown viszont leállítást végez.

Az útmutató a Windows mellett WSL-t használóknak ad további lépéseket. Ha nincs Linux/WSL a gépén, a Windows-ellenőrzés így is hasznos, de a WSL-parancsokat hagyja ki: csak a cikk kedvéért ne telepítsen fejlesztői környezetet. Nem kell minden lépést végrehajtania, ha már az elején megtalálja a terhelést indokoló alkalmazást.

1. LÉPÉS – WINDOWS FELADATKEZELŐ, FOLYAMATOK RENDEZÉSE

Nyissa meg a Feladatkezelőt:
Ctrl + Shift + Esc

A „Folyamatok” lapon kattintson a CPU oszlop fejlécére. Ezzel a legtöbb CPU-t használó folyamat kerül felülre.

Ezután kattintson a Memória oszlopra is, és nézze meg a legnagyobb memóriafogyasztókat.

A „Teljesítmény” lapon látható, hogy a magas terhelés csak rövid csúcs-e, vagy hosszabb ideje fennáll.

Mit érdemes feljegyezni?

• folyamat neve;
• CPU%;
• memóriahasználat;
• nagyjából mióta áll fenn;
• van-e közben magas hálózati vagy lemezaktivitás.

Ne állítson le ismeretlen rendszerfolyamatot csak azért, mert magas értéket mutat. Előbb azonosítsa.

Érdemes ugyanazt az ablakot egy-két perc múlva ismét megnézni. Ha a frissítés közben magas érték a feladat végén visszaesik, az más helyzet, mint amikor egy látszólag tétlen program tartósan a lista élén marad. Ha inkább a lemez oszlopa magas, vagy a gép kevés CPU-terhelés mellett is forró, ne csak processzorhibát keressen.

2. LÉPÉS – HA LINUX/WSL IS FUT, NYISSON POWERSHELLT

Windows alatt:
Start menü → írja be: PowerShell → Enter.

A megjelenő PowerShell-ablak alján villogó kurzor után írja a parancsokat.

Először nézzük meg, milyen WSL/Linux környezetek vannak, és melyik fut:

wsl -l -v

Mit fog látni?

• NAME: disztribúció neve;
• STATE: Running vagy Stopped;
• VERSION: WSL-verzió.

Ha a STATE mezőben Running szerepel, az adott Linux környezet aktív.

A csillag az alapértelmezett disztribúciót jelöli; a következő, külön név nélkül megadott WSL-parancsok ezt használják. Több Linux-környezet esetén ezért előbb ellenőrizze, hogy a vizsgált munka valóban ebben fut-e. A WSL-parancs elindíthat egy korábban leállított alapértelmezett környezetet is, tehát a parancs előtti és utáni állapot különbözhet.

3. LÉPÉS – PILLANATNYI LINUX CPU-TERHELÉS

PowerShellben:

wsl -- top -b -n 2 -d 1 -o %CPU

Ez két folyamatlistát ír ki, egy másodperc különbséggel, CPU szerint rendezve. Az aktuális terhelés megítéléséhez a második listát nézze; egyetlen első mintából ne vonjon le következtetést.

Fontos oszlopok:

• PID: folyamat azonosítója;
• %CPU: processzorterhelés;
• %MEM: memóriahasználat;
• COMMAND: folyamat neve.

Ha Windows szerint a WSL nagyon erősen terhel, itt pedig a CPU nagy része idle, az fontos eltérés.

4. LÉPÉS – A LEGERŐSEBB LINUX FOLYAMATOK RÉSZLETESEBBEN

PowerShellben:

wsl -e bash -lc "ps -eo pid,ppid,%cpu,%mem,etime,comm --sort=-%cpu | head -20"

Mit mutat?

• PID: a folyamat azonosítója;
• PPID: a szülőfolyamat azonosítója;
• %CPU: a folyamat indulása óta számított átlagos CPU-használat, nem pillanatnyi terhelés;
• %MEM: memória;
• ETIME: mióta fut;
• COMM: folyamat neve.

Az ETIME különösen hasznos. Ha egy háttérfolyamat órák vagy napok óta fut, miközben már nem kellene aktívnak lennie, azt érdemes megvizsgálni.

Ha tmux háttérmunkameneteket is használ:

wsl -e bash -lc "tmux list-sessions"

Ez megmutatja a tmux munkameneteket. Egy régi munkamenet önmagában nem hiba. Ha a tmux nincs telepítve, a „command not found” üzenet csak az eszköz hiányát jelzi; emiatt nem kell telepítenie.

5. LÉPÉS – WINDOWS MAGAS, LINUX ALACSONY: VIZSGÁLJUK A WSL HOST OLDALT

PowerShellben:

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process |
Where-Object { $_.Name -match 'wsl|lxss' } |
Select-Object Name,IDProcess,PercentProcessorTime,ThreadCount,HandleCount |
Format-Table -AutoSize

Ez kilistázza a WSL-hez kapcsolódó Windows-oldali folyamatokat és azok terhelését.

Fontos megjegyzés:
a PercentProcessorTime többmagos gépen 100 fölé is mehet, mert a teljesítményszámláló a logikai processzorok terhelését összegezheti. Ha például 16 logikai processzor van a gépben, az 800 körüli érték nagyságrendileg a teljes gép felének felelhet meg.

A cél nem egyetlen szám vak értelmezése, hanem annak megkeresése, hogy egy konkrét wslhost példány feltűnően eltér-e a többitől.

6. LÉPÉS – EGY GYANÚS PID PONTOS AZONOSÍTÁSA

Ha például egy konkrét PID feltűnően sok CPU-t használ, az első parancs kérdésére írja be annak számát; az utána következő parancsok ugyanazt a PID-et használják:

$targetProcessId = [int](Read-Host "A vizsgált folyamat PID-je")
Get-CimInstance Win32_Process -Filter "ProcessId=$targetProcessId" |
Format-List Name,ProcessId,ParentProcessId,ExecutablePath,CommandLine

Adatvédelmi figyelmeztetés: a CommandLine mező fájlutakat, felhasználónevet vagy akár hozzáférési adatot is tartalmazhat. Ezt a kimenetet nyilvánosan ne ossza meg.

Mit tudunk meg?

• a folyamat valódi nevét;
• szülőfolyamatát;
• az executable pontos helyét;
• a parancssort.

Ezután:

Get-Process -Id $targetProcessId |
Select-Object Id,ProcessName,Path,StartTime,Handles,@{N='Threads';E={$_.Threads.Count}}

Ezzel látható például:

• mikor indult;
• hány threadet használ;
• hány handle-je van.

A nagyon gyorsan növekvő thread- vagy handle-szám erőforrásszivárgásra utalhat, de önmagában még nem bizonyít rosszindulatú működést.

Ha nincs eredmény vagy hibaüzenetet kap: a folyamat időközben leállhatott, vagy bizonyos adataihoz nincs jogosultsága. Egy hiányzó Path vagy StartTime nem jelenti automatikusan azt, hogy kártékony programot talált. Ellenőrizze újra a PID-et a Feladatkezelőben. Újraindítás után egy korábbi azonosító már más folyamathoz tartozhat; mindig a most futó példányt vizsgálja. Jogosultsági hibát ne próbáljon védelmi beállítások kikapcsolásával megoldani.

7. LÉPÉS – DIGITÁLIS ALÁÍRÁS ELLENŐRZÉSE

Ezt ugyanabban a PowerShell-ablakban futtassa, ahol megadta a vizsgált PID-et. Csak akkor működik, ha a folyamat fájlútvonala elérhető; hiányzó útvonal esetén előbb az azonosítást kell tisztázni.

Windows rendszerkomponensnél hasznos ellenőrizni, hogy a fájl hitelesen aláírt-e:

Get-AuthenticodeSignature (Get-Process -Id $targetProcessId).Path |
Select-Object Status,@{N='Signer';E={$_.SignerCertificate.Subject}}

Ha a Status „Valid”, és a várt gyártó aláírása szerepel, az erősen csökkenti annak valószínűségét, hogy egyszerűen egy rendszerfolyamatnak álcázott fájlról van szó.

Fontos:
a hiteles digitális aláírás nem bizonyítja, hogy a folyamat biztosan hibátlan vagy hogy a rendszer biztosan nem kompromittált. Csak egy fontos ellenőrzési pont.

8. MIKOR GONDOLJUNK BIZTONSÁGI PROBLÉMÁRA?

A magas CPU önmagában nem vírusjel.

Komolyabban érdemes biztonsági irányba vizsgálódni, ha több jel együtt jelenik meg:

• ismeretlen executable vagy gyanús fájlútvonal;
• nincs vagy hibás a digitális aláírás ott, ahol elvárható lenne;
• váratlan hálózati forgalom;
• a folyamat újra és újra visszaindul;
• szokatlan automatikus indítási bejegyzések;
• védelmi szoftver riasztása;
• a gép terhelése akkor is magas, amikor semmilyen ismert feladat nem fut.

Ilyenkor ne csak a CPU-t csökkentse. Vizsgálja meg az eredetet, frissítse a védelmi rendszert, és szükség esetén futtasson teljes vagy offline vírusellenőrzést.

9. MIT NE CSINÁLJON?

Ne „lőjön ki” találomra rendszerfolyamatokat.

Különösen ne állítsa le ellenőrzés nélkül a Windows alapvető rendszerfolyamatait vagy az összes WSL-folyamatot, ha éppen munka fut bennük.

A helyes sorrend:
1. tünet észlelése;
2. mérés;
3. folyamat azonosítása;
4. fájlútvonal/eredet ellenőrzése;
5. futó munka mentése/checkpoint;
6. csak ezután célzott beavatkozás.

10. HA A WSL-T KELL ÚJRAINDÍTANI

Ha a Linuxos munkát már mentette, a teljes WSL környezet kontrollált leállítására használható:

wsl --shutdown

Ez minden futó WSL disztribúciót és Linux-folyamatot leállít.

Ezért csak akkor használja, ha:

• a futó munkát mentette;
• tudja, hogy újra tudja indítani a szükséges szolgáltatásokat;
• és a célzottabb megoldás nem megfelelő vagy nem biztonságosan azonosítható.

Utána indítsa el újra a Linux környezetet, majd ellenőrizze ismét a Feladatkezelőt.

A leállítás nem távolítja el a Linux-környezetet, de megszakítja a benne futó feladatokat. Mentetlen szerkesztés, folyamatban lévő számítás vagy szolgáltatás ezért sérülhet. Ez nem első lépés és nem általános „gyorsító parancs”: csak az azonosított helyzethez illő, előkészített beavatkozás.

11. ELLENŐRZÉS A JAVÍTÁS UTÁN

Ne elégedjen meg azzal, hogy „most halkabb”.

Nézze meg ismét:

• CPU;
• memória;
• WSL/host folyamatok;
• szükséges szolgáltatások működése.

Ha a CPU például közel 100%-ról néhány százalékra esik, miközben a szükséges programok továbbra is működnek, az erős visszaigazolás.

12. HOSSZABB TÁVÚ MEGELŐZÉS AI/FEJLESZTŐI MUNKAÁLLOMÁSON

Ha rendszeresen futnak AI-agentek, fejlesztői workerek vagy WSL-szolgáltatások, érdemes nem csak hibakor vizsgálódni.

Hasznos lehet:

• a CPU- és memóriahasználat automatikus figyelése;
• a megszokott terhelés feljegyzése folyamatonként;
• a nagy erőforrásigényű feladatok sorba állítása, ha túl sok futna egyszerre;
• új nagy feladat indításának korlátozása, ha már nincs elég erőforrás a normál munkához;
• a nem sürgős munkák állapotának mentése és szükség esetén szüneteltetése;
• memória visszaadásának figyelése a feladat végén;
• host és guest terhelés külön mérése;
• szokatlan terhelésnél a hibakereséshez szükséges adatok rögzítése.

A cél nem az, hogy a számítógép soha ne használja ki a rendelkezésre álló erőforrást. Ha valódi munka folyik, teljesen indokolt lehet a magas CPU vagy RAM.

A cél az, hogy az erőforrás-fogyasztásnak legyen oka, legyen megfigyelhető, és ne maradjon észrevétlenül beragadt folyamat a háttérben.

ÖSSZEFOGLALÁS

A vállalkozásoknál ez nem pusztán a ventilátor hangjáról szól. A lassulás megszakíthatja a munkát, a találomra végzett leállítás pedig adatvesztést okozhat. Informatikai üzemeltetésnél ezért az azonosítható folyamat, a mentett munka és az ellenőrzött újraindítás együtt fontos. MI-eszközök használatakor pedig azt is érdemes tudni, mely feladatok futnak helyben, milyen adathoz férnek hozzá, és mikor fejeződnek be valóban.

A hangos gép vagy a 90–100%-os CPU nem jelenti automatikusan azt, hogy támadás történt.

De azt jelenti, hogy érdemes megnézni, mi történik.

Egy perc a Feladatkezelőben már rengeteg információt adhat. Haladóbb Windows+Linux/WSL környezetben pedig néhány PowerShell- és Linux-paranccsal szűkíthető az okok köre. Ezek az ellenőrzések önmagukban nem adnak teljes hibadiagnózist, és nem zárják ki a biztonsági problémát.

Minél jobban ismeri valaki a saját számítógépe normális működését, annál hamarabb veszi észre, amikor valami nincs rendben.

A parancsok dokumentációja

Microsoft: a WSL alapvető parancsai; top – használati útmutató; ps – a folyamatlista és a CPU-átlag értelmezése.