LINUX.ORG.RU

Проблемы с памятью при свопинге

 


0

2

Система Scientific Linux 6.2. Иногда, когда заполнена вся память и часть свопа, некоторые команды из консоли не срабатывают с первого раза, например:

[root@mky p]# ip link set up dev eth4
RTNETLINK answers: Cannot allocate memory
В момент выполнения команды наблюдается интенсивная работа диска (видимо свопинг), повторный запуск этой же команды выполняется замечательно.

При этом в свопе достаточно места:

[root@mky p]# free
             total       used       free     shared    buffers     cached
Mem:        511788     449196      62592          0       3608      98516
-/+ buffers/cache:     347072     164716
Swap:       851436     245800     605636

Аналогично ведёт себя tcpdump, может ещё какие команды. Разумется, что 512 Мбайт памяти по современным меркам очень мало, но всё таки интерестно, почему система завершает команду «ip» с ошибкой, а не приостанавливает её выполнение на время работы со свопом? И можно ли что-то с этим сделать (кроме увеличения ОЗУ)?

★★★★★

Ответ на: комментарий от Kroz

Сейчас «/proc/sys/vm/overcommit_memory = 0». Попробую поставить в «1», но не знаю, проблема стабильно не воспроизводится, ошибка возникает обыно после долгого простоя (10-12 часов).

При этом система не считает, что память кончается, oom-killer не запускается, все другие процессы как работали, так и работают.

В логах появляется такое (Call Trace поскипан):

Oct 18 15:48:10 mky kernel: ip: page allocation failure. order:4, mode:0x80d0
Oct 18 15:48:10 mky kernel: Pid: 16906, comm: ip Not tainted 2.6.32-220.4.1.el6.
Oct 18 15:48:10 mky kernel: Call Trace:
Oct 18 15:48:10 mky kernel: [<c04df4e9>] ? __alloc_pages_nodemask+0x589/0x6f0
Oct 18 15:48:10 mky kernel: [<c04073ba>] ? dma_generic_alloc_coherent+0x5a/0xd0
Oct 18 15:48:10 mky kernel: [<e0f899b6>] ? rtl8139_open+0x316/0x3b4 [8139too]
Oct 18 15:48:10 mky kernel: [<c0812004>] ? notifier_call_chain+0x44/0x60
Oct 18 15:48:10 mky kernel: [<c0407360>] ? dma_generic_alloc_coherent+0x0/0xd0
Oct 18 15:48:10 mky kernel: [<c076b5ad>] ? dev_open+0x8d/0xf0
...
Oct 18 15:48:10 mky kernel: [<c080f45c>] ? syscall_call+0x7/0xb
Oct 18 15:48:10 mky kernel: Mem-Info:
Oct 18 15:48:10 mky kernel: DMA per-cpu:
Oct 18 15:48:10 mky kernel: CPU    0: hi:    0, btch:   1 usd:   0
Oct 18 15:48:10 mky kernel: Normal per-cpu:
Oct 18 15:48:10 mky kernel: CPU    0: hi:  186, btch:  31 usd:   0
Oct 18 15:48:10 mky kernel: active_anon:29596 inactive_anon:44114 isolated_anon:0
Oct 18 15:48:10 mky kernel: active_file:13858 inactive_file:11716 isolated_file:32
Oct 18 15:48:10 mky kernel: unevictable:0 dirty:10 writeback:10 unstable:0
Oct 18 15:48:10 mky kernel: free:16492 slab_reclaimable:2094 slab_unreclaimable:7100
Oct 18 15:48:10 mky kernel: mapped:5950 shmem:55 pagetables:940 bounce:0
Oct 18 15:48:10 mky kernel: DMA free:2072kB min:84kB low:104kB high:124kB active_anon:308kB inactive_anon:1160kB active_file:2564kB inactive_file:1372kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15864kB mlocked:0kB dirty:0kB writeback:0kB mapped:1136kB shmem:0kB slab_reclaimable:20kB slab_unreclaimable:16kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Oct 18 15:48:10 mky kernel: lowmem_reserve[]: 0 492 492 492
Oct 18 15:48:10 mky kernel: Normal free:63896kB min:2792kB low:3488kB high:4188kB active_anon:118076kB inactive_anon:175296kB active_file:52868kB inactive_file:45492kB unevictable:0kB isolated(anon):0kB isolated(file):128kB present:503852kB mlocked:0kB dirty:40kB writeback:40kB mapped:22664kB shmem:220kB slab_reclaimable:8356kB slab_unreclaimable:28384kB kernel_stack:1720kB pagetables:3760kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Oct 18 15:48:10 mky kernel: lowmem_reserve[]: 0 0 0 0
Oct 18 15:48:10 mky kernel: DMA: 6*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2072kB
Oct 18 15:48:10 mky kernel: Normal: 8824*4kB 3517*8kB 27*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 63896kB
Oct 18 15:48:10 mky kernel: 30541 total pagecache pages
Oct 18 15:48:10 mky kernel: 4881 pages in swap cache
Oct 18 15:48:10 mky kernel: Swap cache stats: add 284962, delete 280081, find 2968218/2997783
Oct 18 15:48:10 mky kernel: Free swap  = 642784kB
Oct 18 15:48:10 mky kernel: Total swap = 851436kB
Oct 18 15:48:10 mky kernel: 131050 pages RAM
Oct 18 15:48:10 mky kernel: 0 pages HighMem
Oct 18 15:48:10 mky kernel: 3119 pages reserved
Oct 18 15:48:10 mky kernel: 27909 pages shared
Oct 18 15:48:10 mky kernel: 96143 pages non-shared

mky ★★★★★ ()
Ответ на: комментарий от mky

Нашёл как раньше ругался tcpdump:

[root@mky p]# tcpdump -i eth4
tcpdump: can't create rx ring on packet socket: Cannot allocate memory

в dmesg при этом ничего не было. И, как у уже писал раньше, при повторном запуске tcpdump работает нормально.

mky ★★★★★ ()
Ответ на: комментарий от mky

почему система завершает команду «ip» с ошибкой, а не приостанавливает её выполнение на время работы со свопом?

Система не «завершает команду с ошибкой», программа сама завершается, попытавшись сделать системный вызов и получив от него возврат ENOMEM. Т.е. ошибка выделения памяти касается не запроса процесса, а запроса модуля ядра, так что

При этом система не считает, что память кончается, oom-killer не запускается, все другие процессы как работали, так и работают.

вполне естественно.

ABW ★★★★★ ()
Ответ на: комментарий от ABW

Где-то настраивается, чтобы система всегда держала резерв памяти под модули ядра? Мне просто не нравится, что сейчас команда ip может выполнится, а может быть ENOMEM. Причём ладно, это система «дохлая», мне от неё особо ничего не надо, но и на нормальном сервере тоже может быть свопинг.

Можно ли считать, что проблема именно в данном конкретном модуле (8139too) или с любыми сетевыми карточками может быть подобное поведение?

mky ★★★★★ ()
Ответ на: комментарий от mky

Я с ходу не могу сказать, надо почитать что-нибудь по теме.
Тебе бы лучше выставить «ядерные» теги или прямо скастовать специалистов.

ABW ★★★★★ ()
Ответ на: комментарий от mky

Похоже, что

/proc/sys/vm/overcommit_memory = 2

помогло. Во всяком случае за прошедшие 15 дней проблем с памятью не возникало. Правда, при fork() процесса система стала требовать наличие свободной виртуальном памяти в размере этого процесса, пришлось увеличить размер swap.

mky ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.