Ha egy alkalmazás belassul vagy nem válaszol, előbb mérj, és csak utána növeld a VPS erőforrásait. A CPU, a memória, a lemez telítettsége és a szolgáltatás naplója más-más hibára utalhat.
Ez a cikk biztonságos, olvasási célú parancsokkal segít összegyűjteni a hibakereséshez szükséges tényeket, majd eldönteni, mikor kell alkalmazáshibát javítani és mikor indokolt nagyobb csomag.
1. Rögzítsd a tünetet és az időpontját
- Csak egy oldal lassú, vagy az SSH és más szolgáltatás is?
- Mikor kezdődött, és volt-e előtte telepítés, frissítés vagy forgalomnövekedés?
- Időszakos a hiba, vagy tartós? Van hozzá 5xx HTTP-válasz vagy alkalmazáshiba?
2. Nézd meg a rendszer állapotát
| Jel | Lehetséges következő kérdés |
|---|---|
| Magas CPU-terhelés | Melyik folyamat fogyasztja, és mennyi ideje? |
| Kevés szabad memória | Van-e memóriahiány vagy gyakori swap-használat? |
| Betelt fájlrendszer | Melyik csatolási pont telt be? |
| Betelt inode-készlet | Sok apró fájl vagy napló keletkezett? |
uptime
free -h
df -h
df -i
ps aux --sort=-%cpu | head -n 12
ps aux --sort=-%mem | head -n 123. Szűkítsd a hibát a szolgáltatás naplójával
Ha ismered a szolgáltatás systemd-egységének nevét, például nginx.service, ezekkel olvashatod az állapotát és a közelmúlt hibáit.
systemctl status nginx.service --no-pager
sudo journalctl -u nginx.service --since '1 hour ago' --no-pager
sudo journalctl -p err --since '1 hour ago' --no-pager4. Ne automatikusan nagyobb csomagot válassz
- Ha egy folyamat szokatlanul sok erőforrást használ, nézd meg a friss változásait és a hibanaplót.
- Ha a lemez telik, azonosítsd a növekvő adatkört; a mentést és naplót ne töröld találomra.
- Ha a kapacitáshatár tartós, dokumentált terhelés mellett jelentkezik, akkor becsüld meg a szükséges CPU-, RAM- vagy tárhelynövelést.
- Ha elérhetetlenség vagy adatvesztés gyanúja van, kérj segítséget a mért adatokkal és időpontokkal.
