Leaking RAM? na Linuxu

Re:Leaking RAM? na Linuxu
« Odpověď #15 kdy: 27. 12. 2018, 08:49:44 »
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ů.


esparky

Re:Leaking RAM? na Linuxu
« Odpověď #16 kdy: 27. 12. 2018, 09:00:59 »
Díky za odpovědi, trošku to rozepíšu:
Citace
Jak bylo receno, KDE/JAK zjistujes volnou RAM? (a to tam nevidis co ji zabira nejvic pri vyplejch programech?)
Volnou paměť zjišťuji pomocí
Kód: [Vybrat]
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.

Citace
Nemáte /tmp nebo podobný dir na tmpfs, tj. v ramdisku? Některé distribuce to tak dnes dělají.
Kód: [Vybrat]
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1202844k,mode=700,uid=1000,gid=1000)Ramdisk je ale prázdný:
Kód: [Vybrat]
tmpfs              1202844        40  1202804   1% /run/user/1000
Citace
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

esparky

Re:Leaking RAM? na Linuxu
« Odpověď #17 kdy: 27. 12. 2018, 09:05:03 »
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?

ByCzech

  • *****
  • 1 848
    • Zobrazit profil
    • E-mail
Re:Leaking RAM? na Linuxu
« Odpověď #18 kdy: 27. 12. 2018, 09:26:02 »
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.

ByCzech

  • *****
  • 1 848
    • Zobrazit profil
    • E-mail
Re:Leaking RAM? na Linuxu
« Odpověď #19 kdy: 27. 12. 2018, 09:31:08 »
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.


esparky

Re:Leaking RAM? na Linuxu
« Odpověď #20 kdy: 27. 12. 2018, 10:26:47 »
Citace
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:
Kód: [Vybrat]
[    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

Re:Leaking RAM? na Linuxu
« Odpověď #21 kdy: 27. 12. 2018, 10:33:08 »
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?

esparky

Re:Leaking RAM? na Linuxu
« Odpověď #22 kdy: 27. 12. 2018, 11:12:06 »
Citace
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á...

Neviditelný

Re:Leaking RAM? na Linuxu
« Odpověď #23 kdy: 27. 12. 2018, 12:47:05 »
Únik paměti v Xkách by to být mohl, protože by vypadal přesně takhle „neviditelně” - viz tenhle bug. 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í.

k3dAR

  • *****
  • 2 838
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Leaking RAM? na Linuxu
« Odpověď #24 kdy: 27. 12. 2018, 19:04:17 »
muzes zkusit restartovat jen desktop, tzn kernel a non-gui zaklad by bezel dal stejnej, jestli mas lightdm, tak:
Kód: [Vybrat]
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

Re:Leaking RAM? na Linuxu
« Odpověď #25 kdy: 27. 12. 2018, 20:34:25 »
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 ).

Stepan

Re:Leaking RAM? na Linuxu
« Odpověď #26 kdy: 13. 01. 2019, 00:04:32 »
Nemáte /tmp nebo podobný dir na tmpfs, tj. v ramdisku? Některé distribuce to tak dnes dělají.

Kód: [Vybrat]
mount | grep tmpfs

Ano mam. Muze to byt problem?

Stepan

Re:Leaking RAM? na Linuxu
« Odpověď #27 kdy: 13. 01. 2019, 00:07:51 »
Ř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

Re:Leaking RAM? na Linuxu
« Odpověď #28 kdy: 13. 01. 2019, 09:04:14 »
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).

Vilith

  • *****
  • 660
    • Zobrazit profil
Re:Leaking RAM? na Linuxu
« Odpověď #29 kdy: 16. 01. 2019, 17:53:24 »
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