i2pd: High memory usage and OOMs
After update to
i2pd version 2.31.0 (0.9.45) Boost version 1.62.0 OpenSSL 1.1.0l 10 Sep 2019
[67708947.806477] Out of memory in UB 217: OOM killed process 32394 (i2pd) score 0 vm:1174764kB, rss:78032kB, swap:179132kB
[68535249.712116] Out of memory in UB 217: OOM killed process 17406 (i2pd) score 0 vm:1043340kB, rss:64784kB, swap:190560kB
[68787110.977385] Out of memory in UB 217: OOM killed process 22593 (i2pd) score 0 vm:1110060kB, rss:32028kB, swap:218172kB
[69054903.040676] Out of memory in UB 217: OOM killed process 18801 (i2pd) score 0 vm:978448kB, rss:85044kB, swap:150092kB
[69443315.058899] Out of memory in UB 217: OOM killed process 13851 (i2pd) score 0 vm:978432kB, rss:60020kB, swap:167476kB
[69698865.768640] Out of memory in UB 217: OOM killed process 30296 (i2pd) score 0 vm:1043784kB, rss:77108kB, swap:176800kB
[69932155.987188] Out of memory in UB 217: OOM killed process 10240 (i2pd) score 0 vm:978404kB, rss:48728kB, swap:178256kB
System is 256mb vps with 256mb swap
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 160 (58 by maintainers)
Сейчас у меня на VPSке 768 mb RAM, на половину от этого - ZRAM, и еще 256 swap file. Больше всего проблем вызывает tor. Вот он вообще непонятно как растет. Падает это все, потому пришлось сделать рестарт тора каждые 2 дня. i2pd довольно стабилен по памяти
Линух по mmap лишь резервирует память, если его специально не попросили ее выделить через флаг MEM_POPULATE. Меняется VSZ, но не RSS. И только по мере обращения к памяти выделяются реальные страницы. C/C++ проги редко используют mmap напрямую. Вместо этого используется heap. heap по мере надобности выделяет блоки памяти через mmap (скорее всего сразу блоками по несколько страниц). освобождены они могут быть только, когда в блоке не останется ничего выделенного по malloc/new если прога много алокатит мелочи, то heap может быть фрагментирован. если хотя бы 1 байтик останется замаллочен в блоке 64K, то весь блок не удастся освободить. просто так перемещать данные не получится, ведь прога помнит указатели на конкретные адреса памяти. стратегия аллокации и освобождения блоков mmap зависит от реализации heap, и в разных libc или версиях libc может быть разная. но при неудачном стечении обстоятельств heap может быть как решето. например, выделено mmap-ом 100 mb, из которых реально задействовано 10 mb
что же касается RSS, то там не учитывается часть памяти, выгруженная в swap. это только резидентная часть в RAM если у вас памяти на компе 4 гб, еще 2 гб свопа, и выделить 4 гб блок, то RSS может быть 2.7 Gb, а своп занят на 1.3 Gb если какой-то процесс много сьел, у него может RSS стать 2 gb, но потом запустить еще какие-то процессы, им станет мало места, и первый может похудеть, скажем, до 1.5 gb. но это не значит память освободилась. это значит ее перекинули в своп. есть такой параметр sysctl vm.swappniess. определяет насколько охотно ядро будет выплевывать память в своп. прям чуть что так сразу, или уже когда совсем плохо