Fórum Root.cz
Hlavní témata => Desktop => Téma založeno: Stepo 26. 12. 2018, 15:44:42
-
pozoruju na svem systemu s postupem casu dochazejici pamet RAM. Hned po startu mam zabrano treba 0.5M. Pak pocitac pouzivam (ok, treba mesic bez vypnuti) a kdyz ukoncim vsechny aplikace mam zabrano treba 6G. Pouzivam PC na beznou praci Eclipse, Web, videa... Nic specialniho. Puvodne jsem myslel, ze za to muze nejaka cache. Tak jsem ji pomoci nejakych zazracny prikazu zahodil a nic. Takze jde o RAM, ktera unikla treba z prohlizece a uz ji nejde uvolnit? Stava se to taky nekomu? Jak zjistit jaka aplikace to dela? Jak pamet ziskat zpet bez restartu?
https://pastebin.com/1imgV8bX
https://pastebin.com/K93Bb8R6
Dekuji
-
Když jsem takovéhle drobnosti kdysi ještě řešil, tak jsem se naučil jednou denně prohlížeč vypnout, a jednou týdně se odhlásit a zase přihlásit. Před deseti lety to stačilo.
-
@Radovan
On tu neuvádza, že by aj prehliadač nechal mesiac otvorený a to sa mi zdá nepravdepodobné. Samozrejme, že aj prehliadač má cache, ktorá sa vymaže pri zatvorení prehliadača. Alebo sa dá vymazať ručne.
-
I kdyz prohlizec zavru, tak to nepomuze. V podstate zavru vse co rucne pustim. Prohlizec, spravce souboru, slovnik... Je pravda, ze se neodhlasim. Ale odhlasit se restart uz je rozdil jen par sekund. radji bych to vyresil prave tim, ze najdu tu aplikace a ukoncim jen tu.
-
Jak jste přišel na to, že RAM „dochází“? To, že je RAM během používání počítače plná, je v pořádku. Špatně by bylo, kdyby zůstávala volná. V RAM jsou např. načtená data z disku, o kterých systém soudí, že budou v nejbližší době potřeba. Kdyby data v té RAM nebyla, budete mít víc volné RAM (což je vám k ničemu), a budete čekat, než se data z disku načtou.
Takze jde o RAM, ktera unikla treba z prohlizece a uz ji nejde uvolnit?
Takhle správa paměti v Linuxu nefunguje. Alokovaná paměť je vždy alokovaná pro určitý proces, s jeho ukončením se veškerá alokovaná paměť vrátí systému. K únikům paměti může docházet uvnitř procesu, pokud je v něm chyba a program nepozná, že danou paměť už nepotřebuje.
Zeptám se jinak – řešíte nějaký problém? Pokud ne, tak se nepokoušejte používat žádné zázračné příkazy a nechte to být – linuxová správa paměti funguje v drtivé většině případů dobře, a když se v tom budete šťourat nevěda, co děláte, můžete to akorát zhoršit.
-
To by nemal byť problém ju nájsť
sudo ps -e -orss=,args=,pid= | sort -b -k1,1n
-
Jednou za čas restartovat prohlížeč docela často postačí, ;).
-
Jak jste přišel na to, že RAM „dochází“? To, že je RAM během používání počítače plná, je v pořádku. Špatně by bylo, kdyby zůstávala volná. V RAM jsou např. načtená data z disku, o kterých systém soudí, že budou v nejbližší době potřeba. Kdyby data v té RAM nebyla, budete mít víc volné RAM (což je vám k ničemu), a budete čekat, než se data z disku načtou.
Takze jde o RAM, ktera unikla treba z prohlizece a uz ji nejde uvolnit?
Takhle správa paměti v Linuxu nefunguje. Alokovaná paměť je vždy alokovaná pro určitý proces, s jeho ukončením se veškerá alokovaná paměť vrátí systému. K únikům paměti může docházet uvnitř procesu, pokud je v něm chyba a program nepozná, že danou paměť už nepotřebuje.
Zeptám se jinak – řešíte nějaký problém? Pokud ne, tak se nepokoušejte používat žádné zázračné příkazy a nechte to být – linuxová správa paměti funguje v drtivé většině případů dobře, a když se v tom budete šťourat nevěda, co děláte, můžete to akorát zhoršit.
Tak řeším problém.
Mám 8G RAM, nemám swap(nepovažuje ho za nutný). Řeším to, že po čistém startu a stejných (skoro žádných) aplikaci mám asi 10x víc volné ram než po dvou týdnech. Časem paměť dojde až tak, že systém vytuhne na pár minut a pak asi jádro sestřeli nějaký proces. Čímž se systém zase rozhybe. O tom, že systém používá RAM jako cache disku vím. Ale je to cache a měl by ji uvolnit hned jak ji potřebuje nějaká aplikace. Proč teda to vytuhnuti os->sestreleni nějakého procesu? Tohle chování si nedokážu vysvětlit.
-
Už několik let pozoruji stejný problém (nemám swap, systém pouze uspávám, 12GB RAM). Cca 1x za týden musím shodit Xka a znovu se přihlásit. Pokud někdo máte elegantnější řešení pak budu rád ;)
-
Řeším to, že po čistém startu a stejných (skoro žádných) aplikaci mám asi 10x víc volné ram než po dvou týdnech.
To není problém.
Časem paměť dojde až tak, že systém vytuhne na pár minut a pak asi jádro sestřeli nějaký proces. Čímž se systém zase rozhybe.
Na to jste přišel jak, že to je způsobené tím, že dojde paměť a jádro to vyřeší odstřelením procesu? Kdyby to tak bylo, najdete v logu hlášku „killed process“.
Proč teda to vytuhnuti os->sestreleni nějakého procesu? Tohle chování si nedokážu vysvětlit.
Zaměřil bych se na vysvětlení tohohle místo spekulací o úniku paměti. Jak se to „vytuhnutí OS“ projevuje? Co je pak v logách?
-
Nemáte /tmp nebo podobný dir na tmpfs, tj. v ramdisku? Některé distribuce to tak dnes dělají.
mount | grep tmpfs
-
Tak řeším problém.
Mám 8G RAM, nemám swap(nepovažuje ho za nutný). Řeším to, že po čistém startu a stejných (skoro žádných) aplikaci mám asi 10x víc volné ram než po dvou týdnech. Časem paměť dojde až tak, že systém vytuhne na pár minut a pak asi jádro sestřeli nějaký proces. Čímž se systém zase rozhybe. O tom, že systém používá RAM jako cache disku vím. Ale je to cache a měl by ji uvolnit hned jak ji potřebuje nějaká aplikace. Proč teda to vytuhnuti os->sestreleni nějakého procesu? Tohle chování si nedokážu vysvětlit.
Kristova noho! Swap se má nastavovat, právě proto, aby se systém mohl vyrovnat s těmito situacemi. Systém neswapuje zbytečně. Pokud jste swap vypnul, tak je očekavatelné, že se něco takového stane.
Při dnešních cenách pamětí bych neotravoval a posílil z 8 GB na něco rozumnějšího.
-
Kristova noho! Swap se má nastavovat, právě proto, aby se systém mohl vyrovnat s těmito situacemi. Systém neswapuje zbytečně. Pokud jste swap vypnul, tak je očekavatelné, že se něco takového stane.
Při dnešních cenách pamětí bych neotravoval a posílil z 8 GB na něco rozumnějšího.
No tak zapnu 8GB swap a nestane se to za týden, ale za dva týdny, ne? Je to pouze oddálení problému, ne řešení příčiny.
Pozoroval někdo něco podobného na systému se zapnutým swapem?
-
Pozoroval někdo něco podobného na systému se zapnutým swapem?
Ne
Jak bylo receno, KDE/JAK zjistujes volnou RAM? (a to tam nevidis co ji zabira nejvic pri vyplejch programech?)
Kdyz se ti jak pises system sekne a pak neco odstreli, CO MAS v LOGu? ze neco system odstrelil?
-
No tak zapnu 8GB swap a nestane se to za týden, ale za dva týdny, ne? Je to pouze oddálení problému, ne řešení příčiny.
Pozoroval někdo něco podobného na systému se zapnutým swapem?
Kdysi jsem měl počítač který bez zapnutého swapu vytuhnul do 5 minut po startu. Jakmile jsem mu dal i jenom minimální swap (tuším asi 128 MB tenkrát?) tak problém zmizel.
Dostal jsem z toho pocit, že jádro prostě bez swapu odmítne dělat některé věci, se kterými se ve správně paměti počíta jako že budou vždycky. I když ten swap reálně k ničemu nepoužije.
-
No tak zapnu 8GB swap a nestane se to za týden, ale za dva týdny, ne? Je to pouze oddálení problému, ne řešení příčiny.
Pozoroval někdo něco podobného na systému se zapnutým swapem?
No nejprve je vždy vhodné jít pomocí doporučených postupů. Tj. vymyslím řešení - nefunguje dobře - vrátím se k doporučenému postupu. Teprve ani když při dodržení best practices nenajdete řešení problému, stojí za to řešit dál.
Co se týče poznámky o rozšíření paměti: mohou nastat dvě další situace, které vidím. 1. bude RAM už dostatek a problém vymizí, 2. (jak píšete) oddálíte projev problému a mezitím může přijít aktualizace, která problém vyřeší.
Podle všeho nejste na tolik zběhlý, abyste dokázal tyto situace analyzovat - tj. Váš postup není přínosný, ani kdybyste ho reportoval jako bug. To mě opět vede k tomu, že lepší je držet se zavedených postupů.
-
Díky za odpovědi, trošku to rozepíšu:
Jak bylo receno, KDE/JAK zjistujes volnou RAM? (a to tam nevidis co ji zabira nejvic pri vyplejch programech?)
Volnou paměť zjišťuji pomocí
free -m
dlouho jsem si myslel, že jde o důsledek cache souborového systému, ale problém je, že čase začne OOM killer zabíjet procesy.
Nemáte /tmp nebo podobný dir na tmpfs, tj. v ramdisku? Některé distribuce to tak dnes dělají.
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1202844k,mode=700,uid=1000,gid=1000)Ramdisk je ale prázdný:
tmpfs 1202844 40 1202804 1% /run/user/1000
To by nemal byť problém ju nájsť
sudo ps -e -orss=,args=,pid= | sort -b -k1,1n
Momentálně mám systém restartovaný, ale jak se do toho stavu dostane, tak přidám. Ale zkoušel jsem leekující proces tímto způsobem hledat a tváří se to tak, že součet zabrané paměti zdaleka neodpovídá celkové RAM, tj celkem mám třeba zabráno 5GB RAM, ale pomocí free -m vidím, že mám volno méně, než kolik by mělo zbývat.
Můj systém běží na Debianu/Buster, jádra jsem zkoušel od 3.18 až po 4.19. X.Org 1.20.3, VGA - HD Graphics 5500 (rev 09)
Typuju, že jde o nějaký leak v Xkách, popř. driveru grafiky. [Stepo], jakou máte konfiguraci?
Co se týče nutnosti swapu...řekl bych, že většina linuxových systémů jede bez swapu (prakticky všechny embedded/mobile), na VPS také jedu bez swapu i několik měsíců a leekování nepozoruji.
Díky
-
No tak zapnu 8GB swap a nestane se to za týden, ale za dva týdny, ne? Je to pouze oddálení problému, ne řešení příčiny.
Pozoroval někdo něco podobného na systému se zapnutým swapem?
No nejprve je vždy vhodné jít pomocí doporučených postupů. Tj. vymyslím řešení - nefunguje dobře - vrátím se k doporučenému postupu. Teprve ani když při dodržení best practices nenajdete řešení problému, stojí za to řešit dál.
Co se týče poznámky o rozšíření paměti: mohou nastat dvě další situace, které vidím. 1. bude RAM už dostatek a problém vymizí, 2. (jak píšete) oddálíte projev problému a mezitím může přijít aktualizace, která problém vyřeší.
Podle všeho nejste na tolik zběhlý, abyste dokázal tyto situace analyzovat - tj. Váš postup není přínosný, ani kdybyste ho reportoval jako bug. To mě opět vede k tomu, že lepší je držet se zavedených postupů.
Díky za typ, samozřejmě mohu zapnout swap, popř pořídit více RAMky, ale není lepší zjistit, zda podobný problém neřeší i někdo další a (možná) dát do kupy dost informací k tomu, aby bylo dost informací k nahlášení bugu?
-
Pokud nenajdeš proces, který by to dělal, nejspíše to bude leakovat na grafice. Typický problém bývá z mých zkušeností třeba s packagekit. Čas od času se vyplatí tohoto daemona restartovat. Když hledám podobné věci, osvědčil se mi htop, umí seřazovat procesy např. podle zabrané RAM.
Jirsáka a jeho teorie neposlouchej, ten člověk je úplně odtržený od reality. Teoretické znalosti má, ale v praxi k ničemu.
-
Kristova noho! Swap se má nastavovat, právě proto, aby se systém mohl vyrovnat s těmito situacemi. Systém neswapuje zbytečně. Pokud jste swap vypnul, tak je očekavatelné, že se něco takového stane.
Při dnešních cenách pamětí bych neotravoval a posílil z 8 GB na něco rozumnějšího.
No tak zapnu 8GB swap a nestane se to za týden, ale za dva týdny, ne? Je to pouze oddálení problému, ne řešení příčiny.
Pozoroval někdo něco podobného na systému se zapnutým swapem?
Pravdu máte oba, každý kousek. je dobré mít polštář v podobě swap (klidně jen v souboru dočasně nebo dynamicky přidělovanou např. pomocí swapspace), protože se může stát, že se mu sejde v určitý okamžik větší požadavky na pamět (stačí zlobivý web, nebo nějaká služba co zrovna začala něco dělat a nanárokovala si více paměti, kterou by později vrátila) a bez swapu to OS nemůže vyřešit jinak, než ze povolá OOM killer.
Ale taky je možné, že to vůbec nepomůže, protože mu leakuje pamět např. GPU, takže si tím nijak nepomůže, jen problém oddálí.
Takže bych se neodvážil tvrdit ani jedno ani druhé bez nalezení příčiny.
-
Pokud nenajdeš proces, který by to dělal, nejspíše to bude leakovat na grafice. Typický problém bývá z mých zkušeností třeba s packagekit. Čas od času se vyplatí tohoto daemona restartovat. Když hledám podobné věci, osvědčil se mi htop, umí seřazovat procesy např. podle zabrané RAM.
Děkuji za odpověď, htop jsem také zkoušel, bohužel z něj nyní nemám uložen výstup. Nemáte nějaký nápad, jak potvrdit leak v grafice?
Nyní používám:
[ 47.098] (II) LoadModule: "intel"
[ 47.098] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[ 47.535] (II) Module intel: vendor="X.Org Foundation"
[ 47.535] compiled for 1.20.1, module version = 2.99.917
[ 47.535] Module class: X.Org Video Driver
[ 47.535] ABI class: X.Org Video Driver, version 24.0
[ 47.535] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[ 47.535] (II) intel: Driver for Intel(R) HD Graphics
[ 47.535] (II) intel: Driver for Intel(R) Iris(TM) Graphics
[ 47.535] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
[ 47.554] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20180719
[ 47.554] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.99.917+git20180925-2 (Andreas Boll <aboll@debian.org>)
[ 47.554] (II) intel(0): SNA compiled for use with valgrind
[ 47.581] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 5500
-
problém je, že čase začne OOM killer zabíjet procesy.
Z vašich komentářů vyplývá, že to zabití procesu pomůže, tedy oom-killer funguje správně a vybere ten správný proces. To, že oom-killer zabíjí procesy víte určitě ze systémového logu, kde je na tom samém řádku také napsané, který proces byl zabit – což je tedy ten proces, který dělá problémy. Za celou dobu jste jméno toho procesu nenapsal ani jednou. Od nás tedy chcete co? Abychom vám jméno toho procesu z logu přečetli?
-
Z vašich komentářů vyplývá, že to zabití procesu pomůže, tedy oom-killer funguje správně a vybere ten správný proces. To, že oom-killer zabíjí procesy víte určitě ze systémového logu, kde je na tom samém řádku také napsané, který proces byl zabit – což je tedy ten proces, který dělá problémy.
Za celou dobu jste jméno toho procesu nenapsal ani jednou. Od nás tedy chcete co? Abychom vám jméno toho procesu z logu přečetli?
Nemám z toho nyní log, stane se to cca po týdnu běžného používání (přesně jak psal původní tazatel). OOM zabíjí prakticky náhodně, dle toho, který proces si o paměť zažádá (nebo tak se mi to alespoň jeví)...rozhodně se to nechová tak, že by OOM zabil ten správný proces a pak byl zas týden klid.
Ve výpisech využití paměti, žádný proces, který by chybějící paměť využíval vidět není, jen je prostě obsazená...
-
Únik paměti v Xkách by to být mohl, protože by vypadal přesně takhle „neviditelně” - viz tenhle bug (https://bugs.freedesktop.org/show_bug.cgi?id=106106). Mohlo by být zajímavé zkusit použít generický ovladač modesetting místo Intelího DDXka a sledovat, zda se něco změní.
-
muzes zkusit restartovat jen desktop, tzn kernel a non-gui zaklad by bezel dal stejnej, jestli mas lightdm, tak:
sudo service lightdm restart &mozna to bude potreba pustit z prihlasene text console (ctrl+alt+f2), v zavialosti na tom zda to restartovani stihne dojet driv nez ho systemd zabije
-
oom-killer by měl fungovat konsistentně a zabít "největší" proces. Důkladnější popis včetně různých nastavení viz například zde: https://unix.stackexchange.com/questions/153585/how-does-the-oom-killer-decide-which-process-to-kill-first
Typicky to dneska sežere web browser (nebo několik oken web browserů), ne nutně vinou browseru, ale spíš chybou leaku ve webovém kódu. S novou architekturou rozdělení do různých procesů je hezké, že oom-killer sestřelí jenom jedno okno, na druhé straně to jedno špatné okno nemusí být v paměti dostatečně velké, aby přebilo ostatní systémové procesy (SQL servery, X server, web server či cokoliv většího na systému běží).
Řešením je nenechat otevřené prasečí stránky (což může být těžké identifikovat), případně nastavit limity na paměť pro stránku / tab (nějaké nastavaní má Chrome, ale do detailu jsem nikdy nešel).
Swap v zásadě nemá smysl nezapínat, pokud je k dispozici dostatek RAM. Jak už někdo napsal, prakticky to problém pouze oddálí a ještě k tomu učiní systém prakticky nepoužitelným, neboť ta špatná aplikace vytlačí ty skutečně důležité části (speciálně viditelné na rotačních discích kvůli zpoždění).
OOM killer lze spustit i manuálně, když dochází k nejhoršímu a systém zatuhává - Alt-SysRq-F (na novějších systémech může být nutné povolit - https://en.wikipedia.org/wiki/Magic_SysRq_key#Configuration ).
-
Nemáte /tmp nebo podobný dir na tmpfs, tj. v ramdisku? Některé distribuce to tak dnes dělají.
mount | grep tmpfs
Ano mam. Muze to byt problem?
-
Řeším to, že po čistém startu a stejných (skoro žádných) aplikaci mám asi 10x víc volné ram než po dvou týdnech.
To není problém.
Časem paměť dojde až tak, že systém vytuhne na pár minut a pak asi jádro sestřeli nějaký proces. Čímž se systém zase rozhybe.
Na to jste přišel jak, že to je způsobené tím, že dojde paměť a jádro to vyřeší odstřelením procesu? Kdyby to tak bylo, najdete v logu hlášku „killed process“.
Proč teda to vytuhnuti os->sestreleni nějakého procesu? Tohle chování si nedokážu vysvětlit.
Zaměřil bych se na vysvětlení tohohle místo spekulací o úniku paměti. Jak se to „vytuhnutí OS“ projevuje? Co je pak v logách?
No asi tak jako win98;) Kdyz pohnu mysi, reakce je v radu sekund. Vzdy po par sekundach poskoci, nebo se kousek pohne. Obnobna reakce na klavesnici, do nekolika sekund.
Export dmesg kde je videt, ze neco sestreli. Viz https://pastebin.com/rG1LzYP3
-
No asi tak jako win98;) Kdyz pohnu mysi, reakce je v radu sekund. Vzdy po par sekundach poskoci, nebo se kousek pohne. Obnobna reakce na klavesnici, do nekolika sekund.
Export dmesg kde je videt, ze neco sestreli. Viz https://pastebin.com/rG1LzYP3
V logu je hlavně vidět, že sestřelí Chromium, které mělo obsazené 1,5 GB paměti. To je i na prohlížeč docela dost, pokud jste tam měl otevřené jen normální webové stránky. Uvidíte, zda je Chromium odstřelováno opakovaně, nebo zda to postihuje náhodně různé aplikace. Můžete i průběžně sledovat Chromium, zda proces v paměti stále bobtná. Pokud používáte aktuální verzi Chromia bez nějakých úprav, memory leak přímo v Chromiu to asi nebude – to byste nebyl jediný, kdo by na to narazil. Ale mohl by to být problém s ovladačem grafické karty, jak už tu bylo řečeno. Můžete v Chromiu přepnout akceleraci vykreslování – předpokládám, že máte zapnutou hardwarovou akceleraci vykreslování, zkuste jí vypnout, zda se tím případné bobtnání Chromia v paměti zastaví (po restartu prohlížeče).
-
No asi tak jako win98;) Kdyz pohnu mysi, reakce je v radu sekund. Vzdy po par sekundach poskoci, nebo se kousek pohne. Obnobna reakce na klavesnici, do nekolika sekund.
Export dmesg kde je videt, ze neco sestreli. Viz https://pastebin.com/rG1LzYP3
V logu je hlavně vidět, že sestřelí Chromium, které mělo obsazené 1,5 GB paměti. To je i na prohlížeč docela dost, pokud jste tam měl otevřené jen normální webové stránky. Uvidíte, zda je Chromium odstřelováno opakovaně, nebo zda to postihuje náhodně různé aplikace. Můžete i průběžně sledovat Chromium, zda proces v paměti stále bobtná. Pokud používáte aktuální verzi Chromia bez nějakých úprav, memory leak přímo v Chromiu to asi nebude – to byste nebyl jediný, kdo by na to narazil. Ale mohl by to být problém s ovladačem grafické karty, jak už tu bylo řečeno. Můžete v Chromiu přepnout akceleraci vykreslování – předpokládám, že máte zapnutou hardwarovou akceleraci vykreslování, zkuste jí vypnout, zda se tím případné bobtnání Chromia v paměti zastaví (po restartu prohlížeče).
1.5G na prohlizec muze byt zcela v poradku. Problem je v tom, ze system nema dostatek RAM
Obecně platí, že out of memory killer (oom-killer) začne zabíjet procesy, a to i na serverech s velkým množstvím RAM