Portál AbcLinuxu, 13. května 2025 03:49
Pokud jádro zabilo syslog, tak ve /var/log samozřejmě nic nebude. Musíte se podívat do protokolu jádra (dmesg). Ale i ten je kruhový, takže ho možná budete chtít nafouknout (parametr jádra při bootu nebo překladu).
Pokud se opravdu bojíte OOM, tak prostě vypněte memory overcommitment (/proc/sys/vm/overcommit_memory), ale pak asi bude vašim aplikacím těsno.
Pro vás ale asi opravdu bude nejlepší nastavit hlídači -17 do oom_adj, aby přežil. Pro účely ladění byste si mohl nastavit /proc/sys/vm/oom_dump_tasks, abyste získal přehled o všech procesech v době zabití.
Pisu ted malou aplikaci pro sledovani procesu.Kanón na vrabce. Dejte si do cronu ps po minutě a pak na to kápnete hned. (Vím z vlastní zkušenosti.) Dalším logickým krokem bude opravit tu špatnou aplikaci, která bortí systém. To většinou zabere
Pokud chcete něco monitorovat, pořiďte si nagios (nebo jiný systém). Nepište si vlastní věci.
V nekterych pripadech (coz se mi nekolikrat stalo) system zacne strilet procesy a nez na to clovek prijde je system v nefunkcnim stavu a v logu ani zminka.Jako prevence by Vás mohly zajímat cgroups (control groups). Umožňují nastavit paměťovou kvótu tak aby se jeden proces nemohl rozpínat na úkor druhých.
Sledovani je jen jedna vec, dalsi je znovu spusteni/restart procesu pokud z nejake priciny spadne/nebezi, nebo vykonani jine akce. Kanon na vrabce mi pripadne spis ten Nagios. Nemam s nim sice takove zkusenosti, za to se Zabbixem nekolikalete a prave takovy Zabbix to co potrebuji neumi a nebo umi, ale velmi slozite a jen castecne.Samozřejmě záleží na tom co si přejete dělat. Pokud chcete jen odhalit škůdce tak IMHO nejpřímočařejší cesta je to 'ps' jak jsem navrhoval. Pokud chcete dlouhodobě sledovat dostupnost služeb, mít nad tím nějaké hlášení problémů, případně samočinné pokusy o restart... tak na to je (opět IMHO) vhodný nástroj ten Nagios. Klidně do něj můžete jako plugin zaintegrovat ten svůj úžasnej nezničitelnej program ale myslím si že to bude fungovat zrovna tak dobře s něčím obyčejným. Každopádně máte už ale hotovou veškerou hlídací a rozhodovací logiku a nemusíte vynalézat kolo.
Proc v urcitych situacich misto demona o velikosti par desitek KB pouivat moloch co potrebuje php, sql server, atp...?Vždycky když jsem měl takovéto tendence si něco malého psát tak jsem se prve porozhlédl jestli to už někdo nevyřešil předemnou. Konfiguraci Nagiosu pokud ho neznáte budete věnovat X dní a zrovna tak ten čas byste strávil psaním toho démona. Problém je, že pak když budete chtít "ještě tohle a ještě támto" tak v Nagiosu to už uděláte raz dva, zatímco ten démon budete zase X dní přepisovat, testovat, atp. Takže v delší trati se Vám přestane vyplácet udržovat ten bastl. PHP ani SQL server pokud vím to nepotřebuje, pouze Apache pokud chcete web front end.
Stejně tak přetečené, stejně tak přidelení (nepřidělení) volné paměti a všechno. Ono to vypadá jako buzerace, ale je to o tom, že co si uděláte, to máte. Ne vždy potřebujete velké a superkomplexní věci a proto používáte C a ne třeba Javu nebo C#. Nevýhoda toho je, že si musíte všecko ohlídat. ;)
Hodně zdaru.
Mne slo spis o to, jestli je mozne tu statickou brat tak, ze je alokovana v dobe spusteni procesu a proces s ni muze pracovat v kazde situaci a nikdo mu ji nevezme.Ne, vizte http://www.abclinuxu.cz/poradna/programovani/show/307603#3
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.