Jak řešit pády bota, paměť a zálohy
Redakce AxHost · Aktualizováno 5. listopadu 2026
U malého hostingu je důležité zjistit příčinu pádu před dalším restartem. Tato příručka pomůže rozlišit chybu konfigurace, chybějící knihovnu a vyčerpané prostředky. Nejde o záruku, že se každý projekt vejde do Free tarifu: spotřebu ovlivňuje knihovna, počet komunit i práce s daty.
Co znamená 128 MB RAM a 25 % CPU
RAM slouží běžícímu procesu, runtime i načteným knihovnám. Nejde o velikost souborů na disku. Projekt s několika kilobajty vlastního kódu proto může po načtení knihoven potřebovat více než 128 MB. Překročení paměťového limitu může vést k ukončení procesu. Hodnota 25 % CPU představuje omezení podílu výkonu jednoho jádra, nikoli čtvrtinu celého fyzického serveru.
Nech běžet jen potřebné funkce. Hlasové přehrávání, prohlížečová automatizace, zpracování obrázků nebo velké modely nejsou rozumným cílem pro tento tarif. Pokud projekt potřebuje vyšší prostředky už při startu, zvol odpovídající hosting; úprava názvu služby limit nezmění.
Proces končí hned po spuštění
Začni prvním konkrétním chybovým hlášením, ne posledním obecným oznámením o ukončení. Cannot find module nebo ModuleNotFoundError obvykle ukazuje na chybějící závislost, chybný název modulu nebo nesprávnou složku. SyntaxError ukazuje na zdrojový kód nebo nekompatibilní verzi runtime. Chyba přihlášení k platformě může znamenat neplatný token, ale také chybějící konfiguraci.
Pokud žádná chyba aplikace vidět není, podívej se na spotřebu paměti a události ukončení procesu. Samotný návratový kód 137 není úplnou diagnózou: znamená ukončení signálem SIGKILL a nedostatek paměti je jen jedna z možných příčin. Porovnej jej s grafem prostředků a informacemi panelu.
Paměť roste až během provozu
Sleduj spotřebu po startu a pak po opakování stejné akce. Pokud při každé zprávě přibývají záznamy v globálním poli a nikdy se nemažou, není řešením jen častější restart. Omez velikost cache, nastav dobu platnosti položek a nenačítej celou historii zpráv, když potřebuješ posledních několik záznamů.
Velké soubory zpracovávej postupně. Stahování celého souboru do paměti, jeho převod a vytvoření další kopie může krátkodobě spotřebu znásobit. Opakované časovače zaregistruj jen jednou a po ukončení práce uvolni připojení i dočasné objekty. Změny měř na stejném scénáři, aby šel výsledek porovnat.
Bot se připojuje stále dokola
Zkontroluj, zda neběží druhá kopie téhož projektu na osobním počítači. U Telegram long pollingu mohou dvě současné instance stejného tokenu způsobovat konflikty. U síťových chyb nepoužívej nekonečnou smyčku bez čekání: respektuj omezení platformy a mezi pokusy postupně prodlužuj interval.
Pokud nefunguje jen jeden příkaz, ověř oprávnění pro konkrétní kanál nebo chat. Nedostupné spojení s uzlem panelu a chyba autentizace bota jsou různé problémy. Při výpadku spojení s uzlem neprováděj naslepo změny tokenu ani reinstalaci projektu.
Záloha před změnou
Stáhni zdrojové soubory, seznam závislostí, konfigurační vzor bez tajných hodnot a data, která aplikace vytváří. Databázi zálohuj exportem jejího obsahu; samotný zdrojový kód databázová data neobsahuje. Přihlašovací údaje uchovávej odděleně a neveřejně.
U souborové databáze nejprve zastav zápisy nebo použij podporovaný postup zálohování dané databáze. Prosté kopírování souboru během zápisu může vytvořit nekonzistentní kopii. Občas si vyzkoušej obnovení do testovacího prostředí. Záloha je užitečná až tehdy, když víš, že ji lze načíst.
Co poslat podpoře
Na komunitní Discord pošli čas problému, prostředí Node.js či Python, poslední relevantní chybu a popis poslední změny. Tokeny, hesla, přístupové klíče a databázové údaje vynech. Uveď, zda chyba nastává při startu nebo až po konkrétní akci. Pro prvotní kontrolu projektu použij také postup nasazení bota.