i2pd
i2pd copied to clipboard
PurpleI2P
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
I have 2 systems. One with hidden service (256 Mb RAM) and another transit only with 1Gb RAM. Both started to OOM
Сейчас у меня так
i2pd version 2.31.0 (0.9.45)
Boost version 1.67.0
OpenSSL 1.1.1d 10 Sep 2019
Транзитных туннелей приблизително 1110-1120
На этом vds 512 МБ ОЗУ, swap специально отключил сейчас.
По моим наблюдениям нужно расчитываь на 100 МБ ОЗУ для процесса i2pd.
Оно просто так не вылетает. Надо оставить на какое-то время. На следующий день обычно уже видишь несколько OOMов Пиково возрастает usage
Как на 512 МБ vds оставить 256 МБ? Насколько помню, OOM срабатывает при общем недостатке ОЗУ и убивает не самый большой процесс, а самый "негодный", которым вероятнее всего окажется самый большой. Возможно какой-то значительно более мелкий процесс провоцирует вызов OOM.
Uptime 45 часов, ОЗУ 512 MB, swap временно отключен в top virt: 675396, res: 77616, shr: 376 приблизительно 4000 транзитных туннелей OOM killer не наблюдался
@bol-van у вас сервис автоматически перезапускается при помощи systemd?
Да, после падений подредактировал юнит на перезапуск У меня обе системы debian stretch. Может из-за версии буст
А в syslog не смотрели кто вызывет данный процесс?
Я подобное встречал от fail2ban и nginx, они инициировали подобное:
kernel: [586820.270152] nginx invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0
kernel: [586820.270154] nginx cpuset=/ mems_allowed=0
kernel: [586820.270161] CPU: 2 PID: 666 Comm: nginx Not tainted 4.19.0-8-amd64 #1 Debian 4.19.98-1
...
Не факт что именно i2pd начал потреблять больше памяти, а система убивает только того кто использует больше всех.
Соответственно там есть и пункт "Tasks state (memory values in pages)" с информацией о процессах в момент проверки.
В общем да. 32 МБ - это копейки, а не причина для oom killer
[68787110.977385] Out of memory in UB 217: OOM killed process 22593 (i2pd) score 0 vm:1110060kB, rss:32028kB, swap:218172kB
Где-то в логах бывает подробное описание ситуации с определением виновного и жертвы, которые не всегда совпадают.
А еще OOM Killer можно настраивать на конкретные процессы или вообще отключать, например первое попавшееся описание https://habr.com/ru/company/southbridge/blog/464245/
В частности сервер ssh в любой ситуации будет убит в самую последнюю очередь или вообще никогда. См. /proc/<pid>/oom_score_adj
Может, конечно, дело и не в i2pd. Там еще tor вертится. Он тоже жрет прилично. Но почему-то ставишь 29, и на той же системе оомы исчезают К сожалению там openvz, в dmesg output очень скудный
кстати, rss:32028kB, swap:218172kB ведь это значит 32M в RAM и 218Mb в swap, не так ли ? То есть всего 250M активной памяти процесса ? Не много ли ?
Похоже многовато, и остальные такие же. А по какой причине ядро его в своп выгнало, кому память понадобилась? Попробую посмотреть. Debian Stretch 64 bit? Что в i2pd.conf поменять?
Хм, весьма странно что 250Мб памяти всего... На ноде с 1Гб ОЗУ имею потребление 49Мб за 14 суток (транзит с лимитом 1К).
Stretch 64 bit, i2pd 2.31+ 4 суток 21 час, пока работает нормально. На 5000 транзитных туннелей 80 МБ ОЗУ, swap отключен. @bol-van, что написать в i2pd.conf?
Похоже, что воспроизводится. i2pd от 30 апреля, Stretch 64 bit, 256 MB RAM, swap отключен. Началось так
May 06 19:12:09 cs793965 kernel: i2pd: page allocation failure: order:0, mode:0x2080120(GFP_ATOMIC|__GFP_COLD)
May 06 19:12:12 cs793965 kernel: CPU: 0 PID: 1160 Comm: i2pd Not tainted 4.9.0-12-amd64 #1 Debian 4.9.210-1
May 06 19:12:12 cs793965 kernel: Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
May 06 19:12:12 cs793965 kernel: 0000000000000000 ffffffff84d36bfe ffffffff85402988 ffff998c0fc03bf0
May 06 19:12:12 cs793965 kernel: ffffffff84b8dfba 020801200fffba50 ffffffff85402988 ffff998c0fc03b90
May 06 19:12:12 cs793965 kernel: ffff998c00000010 ffff998c0fc03c00 ffff998c0fc03bb0 7f05f918e24f9e8f
May 06 19:12:12 cs793965 kernel: Call Trace:
May 06 19:12:12 cs793965 kernel: <IRQ>
May 06 19:12:12 cs793965 kernel: [<ffffffff84d36bfe>] ? dump_stack+0x66/0x88
May 06 19:12:12 cs793965 kernel: [<ffffffff84b8dfba>] ? warn_alloc+0x13a/0x160
May 06 19:12:12 cs793965 kernel: [<ffffffff84b8e29b>] ? __alloc_pages_slowpath+0x24b/0xb30
May 06 19:12:12 cs793965 kernel: [<ffffffff84f5504b>] ? ip_local_deliver+0x6b/0xf0
May 06 19:12:12 cs793965 kernel: [<ffffffff84f4ef02>] ? rt_cache_seq_start+0x2/0x10
May 06 19:12:12 cs793965 kernel: [<ffffffff84b8ed81>] ? __alloc_pages_nodemask+0x201/0x260
May 06 19:12:12 cs793965 kernel: [<ffffffff850045a0>] ? packet_rcv+0x40/0x430
May 06 19:12:12 cs793965 kernel: [<ffffffff84be0871>] ? alloc_pages_current+0x91/0x140
May 06 19:12:12 cs793965 kernel: [<ffffffff84ef959e>] ? skb_page_frag_refill+0xae/0xe0
May 06 19:12:12 cs793965 kernel: [<ffffffffc0210f30>] ? try_fill_recv+0x260/0x6c0 [virtio_net]
May 06 19:12:12 cs793965 kernel: [<ffffffffc0211f2c>] ? virtnet_receive+0x72c/0x930 [virtio_net]
May 06 19:12:12 cs793965 kernel: [<ffffffff84ab0000>] ? active_load_balance_cpu_stop+0x210/0x230
May 06 19:12:12 cs793965 kernel: [<ffffffffc0212148>] ? virtnet_poll+0x18/0x70 [virtio_net]
May 06 19:12:12 cs793965 kernel: [<ffffffff84f13fe6>] ? net_rx_action+0x246/0x380
May 06 19:12:12 cs793965 kernel: [<ffffffff85021ead>] ? __do_softirq+0x10d/0x2b0
May 06 19:12:12 cs793965 kernel: [<ffffffff84a81fa2>] ? irq_exit+0xc2/0xd0
May 06 19:12:12 cs793965 kernel: [<ffffffff85020f37>] ? do_IRQ+0x57/0xe0
May 06 19:12:12 cs793965 kernel: [<ffffffff8501eade>] ? common_interrupt+0x9e/0x9e
May 06 19:12:12 cs793965 kernel: <EOI>
May 06 19:12:12 cs793965 kernel: Mem-Info:
May 06 19:12:12 cs793965 kernel: active_anon:37144 inactive_anon:680 isolated_anon:0
active_file:586 inactive_file:441 isolated_file:0
unevictable:549 dirty:0 writeback:0 unstable:0
slab_reclaimable:2959 slab_unreclaimable:5727
mapped:1521 shmem:722 pagetables:513 bounce:0
free:655 free_pcp:67 free_cma:0
May 06 19:12:12 cs793965 kernel: Node 0 active_anon:148576kB inactive_anon:2720kB active_file:2344kB inactive_file:1764kB unevictable:2196kB isolated(anon):0kB isolated(file):0kB mapped:6084kB dirty:0kB write
May 06 19:12:12 cs793965 kernel: Node 0 DMA free:848kB min:132kB low:164kB high:196kB active_anon:2436kB inactive_anon:0kB active_file:360kB inactive_file:480kB unevictable:0kB writepending:0kB present:15992k
May 06 19:12:12 cs793965 kernel: lowmem_reserve[]: 0 201 201 201 201
May 06 19:12:12 cs793965 kernel: Node 0 DMA32 free:1772kB min:1748kB low:2184kB high:2620kB active_anon:146140kB inactive_anon:2720kB active_file:1972kB inactive_file:1280kB unevictable:2196kB writepending:0k
May 06 19:12:12 cs793965 kernel: lowmem_reserve[]: 0 0 0 0 0
May 06 19:12:12 cs793965 kernel: Node 0 DMA: 42*4kB (UE) 75*8kB (U) 5*16kB (U) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 848kB
May 06 19:12:12 cs793965 kernel: Node 0 DMA32: 93*4kB (H) 77*8kB (H) 48*16kB (H) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1756kB
May 06 19:12:12 cs793965 kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
May 06 19:12:12 cs793965 kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
May 06 19:12:12 cs793965 kernel: 2216 total pagecache pages
May 06 19:12:12 cs793965 kernel: 0 pages in swap cache
May 06 19:12:12 cs793965 kernel: Swap cache stats: add 0, delete 0, find 0/0
May 06 19:12:12 cs793965 kernel: Free swap = 0kB
May 06 19:12:12 cs793965 kernel: Total swap = 0kB
May 06 19:12:12 cs793965 kernel: 65438 pages RAM
May 06 19:12:12 cs793965 kernel: 0 pages HighMem/MovableOnly
May 06 19:12:12 cs793965 kernel: 3869 pages reserved
May 06 19:12:12 cs793965 kernel: 0 pages hwpoisoned
Закончилось так
May 06 19:12:12 cs793965 kernel: [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
May 06 19:12:12 cs793965 kernel: [ 179] 0 179 13830 312 24 3 0 0 systemd-journal
May 06 19:12:12 cs793965 kernel: [ 217] 0 217 11348 434 23 3 0 -1000 systemd-udevd
May 06 19:12:12 cs793965 kernel: [ 292] 0 292 7788 170 20 3 0 0 cron
May 06 19:12:12 cs793965 kernel: [ 295] 0 295 62528 367 28 3 0 0 rsyslogd
May 06 19:12:12 cs793965 kernel: [ 298] 105 298 11282 435 27 4 0 -900 dbus-daemon
May 06 19:12:12 cs793965 kernel: [ 312] 0 312 11617 140 26 3 0 0 systemd-logind
May 06 19:12:12 cs793965 kernel: [ 313] 0 313 6991 383 19 3 0 0 atd
May 06 19:12:12 cs793965 kernel: [ 352] 0 352 1045 22 7 3 0 0 minissdpd
May 06 19:12:12 cs793965 kernel: [ 368] 0 368 3954 373 13 3 0 0 agetty
May 06 19:12:12 cs793965 kernel: [ 449] 0 449 5089 527 13 3 0 0 dhclient
May 06 19:12:12 cs793965 kernel: [ 733] 0 733 74084 2653 48 3 0 0 fail2ban-server
May 06 19:12:12 cs793965 kernel: [ 744] 107 744 14038 188 30 3 0 0 exim4
May 06 19:12:12 cs793965 kernel: [ 998] 0 998 4010 327 13 3 0 0 agetty
May 06 19:12:12 cs793965 kernel: [ 1001] 0 1001 17489 507 38 4 0 -1000 sshd
May 06 19:12:12 cs793965 kernel: [ 1008] 0 1008 1065 353 8 3 0 -1000 watchdog
May 06 19:12:12 cs793965 kernel: [ 1155] 108 1155 175864 32268 113 4 0 0 i2pd
May 06 19:12:12 cs793965 kernel: [ 6857] 100 6857 30768 215 28 3 0 0 systemd-timesyn
May 06 19:12:12 cs793965 kernel: Out of memory: Kill process 1155 (i2pd) score 525 or sacrifice child
May 06 19:12:12 cs793965 kernel: Killed process 1155 (i2pd) total-vm:703456kB, anon-rss:129072kB, file-rss:0kB, shmem-rss:0kB
May 06 19:12:12 cs793965 kernel: oom_reaper: reaped process 1155 (i2pd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
В kern.log более 600 строк, oom-killer был вызван процессом systemd-journal, жертвой стал i2pd. Кроме i2pd только один прожорливый процесс fail2ban.
Хм, значит в момент отвала потребление ОЗУ i2pd было 175 Мб?
Так, а что включено/выключено?
А разве не 32268 kB?
В i2pd.conf: log = file logfile = /var/log/i2pd/i2pd.log loglevel = warn logclftime = true daemon = true ntcp = false nat = false bandwidth = X notransit = false floodfill = false elgamal = true transittunnels = 5000
А разве не 32268 kB?
Нет, это количество страниц.
Да и я не в тот столбец посмотрел, в итоге получается anon-rss:129072kB (32268*4k), что соответствует потреблению в 129MB.
Есть предположение что это SSU утекает.
Он даже не утекает, а просто сохраняет много пакетов для повторной посылки.
подскоки потребления памяти могут быть довольно высокие. но потом чистится
Это не проблема на традиционной системе вроде PC или смартфон. Но проблема на эмбеддед. Сразу отсекаются лов-енд системы, и не только роутеры, а даже лов-енд впс
У меня есть впс с 256 мегов памяти. Никаких проблем не наблюдается. Главное транзит ограничивать, в частности bandwidth=L ставить. А то ведь у вас наверное все выставлено по максимуму,
У меня там хидден сервис, и не хотелось бы, чтобы он совсем лагал. i2p - это безумно тормозная сеть Сеттинги такие bandwidth = 128 share = 25 transittunnels = 100
Uptime 2 суток, заполненная при предыдущем запуске netDB, 4000 транзитных туннелей, bandwidth=X, процесс занимает 75000 КВ ОЗУ, swap отключен. Вероятно очень немаленький подскок потребления памяти, до 129000 КB или больше.