Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: v 20. 02. 2017, 13:27:29

Název: Linux, memory leak a OOM killer
Přispěvatel: v 20. 02. 2017, 13:27:29
RssAnon procesu roste i když strace neukazuje volání (s)brk/mmap a po nějaké době dorazí oom reaper
pomoc
Název: Re:linux, memory leak
Přispěvatel: MP 20. 02. 2017, 13:52:35
valgrind ?
Název: Re:linux, memory leak
Přispěvatel: Jenda 20. 02. 2017, 13:55:14
Protože ti při různých příležitostech dá kernel stránky, které vůbec nemá, nebo je přes CoW sdílíš s někým jiným. Teprve v okamžiku, kdy je začneš špinit, ti je musí dát a začne růst RSS.
Název: Re:linux, memory leak
Přispěvatel: v 20. 02. 2017, 14:25:12
Protože ti při různých příležitostech dá kernel stránky, které vůbec nemá, nebo je přes CoW sdílíš s někým jiným. Teprve v okamžiku, kdy je začneš špinit, ti je musí dát a začne růst RSS.
není rss dirty + clean?
Název: Re:linux, memory leak
Přispěvatel: v 20. 02. 2017, 14:42:01
valgrind ?
zatím není k dispozici, ale můžu říct, že nepozoruju volání malloc/free/etc (uneseny přes LD_PRELOAD) i když rss roste
Název: Re:linux, memory leak
Přispěvatel: lopata 20. 02. 2017, 15:12:29
Linux dělá memory overcommit, takže ti klidně dá paměť, kterou ve skutečnosti nemá. Stačí, když uděláš fork nebo mmap s MAP_PRIVATE. Když tu paměť potom skutečně chceš použít, tak Linuxu může dojít a zaúřaduje OOM killer. Můžeš si to nastavit: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
Název: Re:linux, memory leak
Přispěvatel: v 20. 02. 2017, 15:19:18
Linux dělá memory overcommit, takže ti klidně dá paměť, kterou ve skutečnosti nemá. Stačí, když uděláš fork nebo mmap s MAP_PRIVATE. Když tu paměť potom skutečně chceš použít, tak Linuxu může dojít a zaúřaduje OOM killer. Můžeš si to nastavit: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
tohle určitě nemůžu vyvrátit
jak tedy zjistit kolik má program naslibováno? třeba z /proc/PID/status? vmsize?
Název: Re:linux, memory leak
Přispěvatel: lopata 20. 02. 2017, 15:32:14
jak tedy zjistit kolik má program naslibováno? třeba z /proc/PID/status? vmsize?
třeba
Kód: [Vybrat]
pmap pid
Název: Re:linux, memory leak
Přispěvatel: v 20. 02. 2017, 15:45:06
Kód: [Vybrat]
pmap pid
vidím total cca 47MB na systému s 32MB paměti, asi přihořívá
Název: Re:linux, memory leak
Přispěvatel: Lopatlal 20. 02. 2017, 16:02:56
Tady to je detailne rozepsano + par tipu jak se tomu vyhnout

http://www.linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html?page=2
Název: Re:linux, memory leak
Přispěvatel: v 21. 02. 2017, 11:17:15
jak tedy zjistit kolik má program naslibováno? třeba z /proc/PID/status? vmsize?
třeba
Kód: [Vybrat]
pmap pid
děkuji, pmap jsem zatím neznal
existuje nějaký známý způsob jak poznat co je na které [ anon ] adrese?
Název: Re:linux, memory leak
Přispěvatel: lopata 21. 02. 2017, 11:36:02
existuje nějaký známý způsob jak poznat co je na které [ anon ] adrese?
Kód: [Vybrat]
cat /proc/PID/maps
Název: Re:linux, memory leak
Přispěvatel: v 21. 02. 2017, 11:42:31
existuje nějaký známý způsob jak poznat co je na které [ anon ] adrese?
Kód: [Vybrat]
cat /proc/PID/maps
tam právě není nic, prázdný řetězec, v pmap pak [anon]
mám teď na mysli nějakou instrumentaci v aplikaci, umím si představit heap, stack, nevím co si představit dál
Název: Re:linux, memory leak
Přispěvatel: lopata 21. 02. 2017, 11:46:44
mám teď na mysli nějakou instrumentaci v aplikaci, umím si představit heap, stack, nevím co si představit dál
Potom massif (http://valgrind.org/docs/manual/ms-manual.html) ideálně s --pages-as-heap=yes.
Název: Re:Linux, memory leak a OOM killer
Přispěvatel: v 22. 02. 2017, 09:18:31
takže overcommit je zřejmě to, co nám podrazilo nohy, teď potřebuju umravnit aplikaci

výběr z pmap :
Address   Kbytes     RSS   Dirty Mode  Mapping
76a1b000   13716   12148   12148 rw---   [ anon ]
RSS roste z cca 4000 po startu aplikace, toto je ze systému se 128M RAM, naneštěstí se musím vypořádat i se systémem s 32MB
mám cca 30 vláken, přes pthread_attr_getstack vím, že v tomto rozsahu se nacházejí (některé) zásobníky, ty jsou ovšem v ulimit nastaveny na 128k (30*128kB je mnohem méně než 12148)

pomoc prosím
Název: Re:Linux, memory leak a OOM killer
Přispěvatel: lopata 22. 02. 2017, 09:55:18
takže overcommit je zřejmě to, co nám podrazilo nohy, teď potřebuju umravnit aplikaci

výběr z pmap :
Address   Kbytes     RSS   Dirty Mode  Mapping
76a1b000   13716   12148   12148 rw---   [ anon ]
RSS roste z cca 4000 po startu aplikace, toto je ze systému se 128M RAM, naneštěstí se musím vypořádat i se systémem s 32MB
mám cca 30 vláken, přes pthread_attr_getstack vím, že v tomto rozsahu se nacházejí (některé) zásobníky, ty jsou ovšem v ulimit nastaveny na 128k (30*128kB je mnohem méně než 12148)

pomoc prosím

pmap je ořezaný, používej /proc/PID/maps. Pravděpodobně to nebude stack, stacky multithreadové aplikace vypadají nějak takhle:
Kód: [Vybrat]
cat /proc/27914/maps | grep stack
7f6cf2ff7000-7f6cf37f7000 rw-p 00000000 00:00 0                          [stack:27925]
7f6cf37f8000-7f6cf3ff8000 rw-p 00000000 00:00 0                          [stack:27924]
7f6cf3ff9000-7f6cf47f9000 rw-p 00000000 00:00 0                          [stack:27923]
7f6cf47fa000-7f6cf4ffa000 rw-p 00000000 00:00 0                          [stack:27922]
7f6cf4ffb000-7f6cf57fb000 rw-p 00000000 00:00 0                          [stack:27921]
7f6cf57fc000-7f6cf5ffc000 rw-p 00000000 00:00 0                          [stack:27920]
7f6cf5ffd000-7f6cf67fd000 rw-p 00000000 00:00 0                          [stack:27919]
7f6cf67fe000-7f6cf6ffe000 rw-p 00000000 00:00 0                          [stack:27918]
7f6cf6fff000-7f6cf77ff000 rw-p 00000000 00:00 0                          [stack:27917]
7f6cf7800000-7f6cf8000000 rw-p 00000000 00:00 0                          [stack:27916]
7f6cfc788000-7f6cfcf88000 rw-p 00000000 00:00 0                          [stack:27915]
7fffa652f000-7fffa6550000 rw-p 00000000 00:00 0                          [stack]
Název: Re:Linux, memory leak a OOM killer
Přispěvatel: v 22. 02. 2017, 10:03:03

# grep stack /proc/456/maps
7fd63000-7fd84000 rw-p 00000000 00:00 0          [stack]

osekaný embedded systém, valgrind je kvůli interakci s jiným i komponentami taky mimo hru

pthread_attr_getstack by měl vrátit adresu zásobníku a velikost, podle toho můžu zásobníky zařadit do toho rozsahu
Název: Re:Linux, memory leak a OOM killer
Přispěvatel: lopata 22. 02. 2017, 10:06:45
# grep stack /proc/456/maps
7fd63000-7fd84000 rw-p 00000000 00:00 0          [stack]

To je nějakých 132 KB, takže kvůli stacku asi paměť nedochází?
Název: Re:Linux, memory leak a OOM killer
Přispěvatel: v 22. 02. 2017, 10:16:06
# grep stack /proc/456/maps
7fd63000-7fd84000 rw-p 00000000 00:00 0          [stack]

To je nějakých 132 KB, takže kvůli stacku asi paměť nedochází?
to je jen jeden, mám jich 28 až 30, ale v maps nejsou označeny, podle zkoumání pomocí pthread_attr_getstack se nacházejí v tom velkém bloku, který jsem zmiňoval výše
Název: Re:Linux, memory leak a OOM killer
Přispěvatel: lopata 22. 02. 2017, 10:27:57
to je jen jeden, mám jich 28 až 30, ale v maps nejsou označeny, podle zkoumání pomocí pthread_attr_getstack se nacházejí v tom velkém bloku, který jsem zmiňoval výše

To je divné. Stacky se normálně v pmapu ukazují samostatně pro každý thread, ne společně. U mě je to takhle.

stack jednoho threadu z /proc/maps:
Kód: [Vybrat]
7f30aefff000-7f30af7ff000 rw-p 00000000 00:00 0                          [stack:30352]

stack toho stejného threadu v pmapu:
Kód: [Vybrat]
00007f30aefff000    8192       8       8 rw---   [ anon ]

Myslím, že jdeš po špatné stopě, pravděpodobně to nebude stack. Nebo máš Linux s nějakým zvláštním memory managementem.
Název: Re:Linux, memory leak a OOM killer
Přispěvatel: v 22. 02. 2017, 10:37:09
Myslím, že jdeš po špatné stopě, pravděpodobně to nebude stack. Nebo máš Linux s nějakým zvláštním memory managementem.
vlákna mám, [stack:tid] nemám, to je prostě fakt, může to být specifické pro platformu (powerpc 32b), asi
Název: Re:Linux, memory leak a OOM killer
Přispěvatel: v 22. 02. 2017, 16:45:55
a vítězem je nesmyslně velký kruhový buffer & overcommitment
děkuji za rady