Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: 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
-
valgrind ?
-
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.
-
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?
-
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
-
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
-
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?
-
jak tedy zjistit kolik má program naslibováno? třeba z /proc/PID/status? vmsize?
třeba
pmap pid
-
pmap pid
vidím total cca 47MB na systému s 32MB paměti, asi přihořívá
-
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
-
jak tedy zjistit kolik má program naslibováno? třeba z /proc/PID/status? vmsize?
třeba
pmap pid
děkuji, pmap jsem zatím neznal
existuje nějaký známý způsob jak poznat co je na které [ anon ] adrese?
-
existuje nějaký známý způsob jak poznat co je na které [ anon ] adrese?
cat /proc/PID/maps
-
existuje nějaký známý způsob jak poznat co je na které [ anon ] adrese?
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
-
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.
-
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
-
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:
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]
-
# 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
-
# 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í?
-
# 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
-
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:
7f30aefff000-7f30af7ff000 rw-p 00000000 00:00 0 [stack:30352]
stack toho stejného threadu v pmapu:
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.
-
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
-
a vítězem je nesmyslně velký kruhový buffer & overcommitment
děkuji za rady