LINUX.ORG.RU

тачка под нагрузкой почти умерла


1

1

Впервые за многие годы увидел как умерла практически пустая тачка (без свопа, но это, похоже, в данном случае неважно). Всего-то нужно было iscsi настроить. Вот мне теперь интересно что за память исчерпалась. Могут ли местные гуру сделать post-mortem анализ?

top - 16:33:42 up  2:17,  1 user,  load average: 7.17, 6.35, 4.41
Tasks: 160 total,   2 running, 158 sleeping,   0 stopped,   0 zombie
%Cpu0  :  9.6 us, 20.1 sy,  0.0 ni, 57.4 id, 11.6 wa,  0.0 hi,  1.2 si,  0.0 st
%Cpu1  : 23.5 us, 76.5 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  3.0 us, 11.3 sy,  0.0 ni, 81.8 id,  4.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  2.3 us,  6.6 sy,  0.0 ni, 89.0 id,  2.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   2071532 total,  1957896 used,   113636 free,       32 buffers
KiB Swap:        0 total,        0 used,        0 free.  1727248 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                             
 2493 root      20   0    7580   3424   2400 R  99.8  0.2  10:43.24 syslog-ng                                                           
 5816 root      20   0   11704   4720   2828 D  48.8  0.2   0:50.53 mc
[skip]
=====================

From dmesg:


Mem-info:
Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd:  70
CPU    1: hi:  186, btch:  31 usd: 145
CPU    2: hi:  186, btch:  31 usd: 117
CPU    3: hi:  186, btch:  31 usd: 165
HighMem per-cpu:
CPU    0: hi:  186, btch:  31 usd:  31
CPU    1: hi:  186, btch:  31 usd:  12
CPU    2: hi:  186, btch:  31 usd:  52
CPU    3: hi:  186, btch:  31 usd:  15
active_anon:6363 inactive_anon:51 isolated_anon:0
 active_file:145592 inactive_file:169478 isolated_file:0
 unevictable:758 dirty:1429 writeback:14550 unstable:0
 free:161317 slab_reclaimable:26465 slab_unreclaimable:3724
 mapped:3522 shmem:370 pagetables:242 bounce:0
 free_cma:39559
Normal free:164216kB min:3512kB low:4388kB high:5268kB active_anon:0kB inactive_anon:0kB active_file:310856kB
lowmem_reserve[]: 0 10215 10215
HighMem free:481052kB min:512kB low:1996kB high:3484kB active_anon:25452kB inactive_anon:204kB active_file:27
lowmem_reserve[]: 0 0 0
Normal: 1042*4kB (UEMC) 396*8kB (UEMC) 120*16kB (C) 120*32kB (C) 120*64kB (C) 120*128kB (C) 100*256kB (C) 84*
HighMem: 1*4kB (U) 1*8kB (U) 1*16kB (U) 2*32kB (UM) 1*64kB (U) 1*128kB (U) 2*256kB (UM) 200*512kB (UM) 161*10
315887 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
1048064 pages of RAM
324434 free pages
12298 reserved pages
28396 slab pages
558866 pages shared
0 pages swap cached
smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
swapper/0: page allocation failure: order:3, mode:0x106020
[<c0014e2c>] (unwind_backtrace+0x0/0xf4) from [<c00928c4>] (warn_alloc_failed+0xd4/0x114)
[<c00928c4>] (warn_alloc_failed+0xd4/0x114) from [<c0095910>] (__alloc_pages_nodemask+0x720/0x980)
[<c0095910>] (__alloc_pages_nodemask+0x720/0x980) from [<c0095b80>] (__get_free_pages+0x10/0x24)
[<c0095b80>] (__get_free_pages+0x10/0x24) from [<c03ead64>] (__kmalloc_reserve+0x64/0x70)
[<c03ead64>] (__kmalloc_reserve+0x64/0x70) from [<c03eadec>] (__alloc_skb+0x7c/0x144)
[<c03eadec>] (__alloc_skb+0x7c/0x144) from [<c03eb418>] (__netdev_alloc_skb+0xb8/0xe8)
[<c03eb418>] (__netdev_alloc_skb+0xb8/0xe8) from [<bf058f40>] (rx_submit+0x2c/0x204 [usbnet])
[<bf058f40>] (rx_submit+0x2c/0x204 [usbnet]) from [<bf059154>] (rx_alloc_submit+0x3c/0x98 [usbnet])
[<bf059154>] (rx_alloc_submit+0x3c/0x98 [usbnet]) from [<bf0593a4>] (usbnet_bh+0x1f4/0x268 [usbnet])
[<bf0593a4>] (usbnet_bh+0x1f4/0x268 [usbnet]) from [<c002b69c>] (tasklet_action+0x78/0x110)
[<c002b69c>] (tasklet_action+0x78/0x110) from [<c002b86c>] (__do_softirq+0xf0/0x1a8)
[<c002b86c>] (__do_softirq+0xf0/0x1a8) from [<c002bc10>] (irq_exit+0x58/0x68)
[<c002bc10>] (irq_exit+0x58/0x68) from [<c000efe0>] (handle_IRQ+0x44/0x90)
[<c000efe0>] (handle_IRQ+0x44/0x90) from [<c0008554>] (gic_handle_irq+0x38/0x68)
[<c0008554>] (gic_handle_irq+0x38/0x68) from [<c000dcc0>] (__irq_svc+0x40/0x70)
Exception stack(0xc063ff10 to 0xc063ff58)
ff00:                                     c063ff58 00001dbf 504cbebc 000006ed
ff20: 504b40bd 000006ed c16ec3f0 00000000 c06691c0 c0663c60 00000000 00000000
ff40: 00000018 c063ff58 c0059988 c038cb24 60000153 ffffffff
[<c000dcc0>] (__irq_svc+0x40/0x70) from [<c038cb24>] (cpuidle_wrap_enter+0x48/0x94)
[<c038cb24>] (cpuidle_wrap_enter+0x48/0x94) from [<c038c8c0>] (cpuidle_enter_state+0x18/0x58)
[<c038c8c0>] (cpuidle_enter_state+0x18/0x58) from [<c038c998>] (cpuidle_idle_call+0x98/0xf8)
[<c038c998>] (cpuidle_idle_call+0x98/0xf8) from [<c000f3b0>] (cpu_idle+0x9c/0xec)
[<c000f3b0>] (cpu_idle+0x9c/0xec) from [<c0614b34>] (start_kernel+0x3b8/0x3c4)
     

cast tailgunner

★★★★★

Последнее исправление: true_admin (всего исправлений: 1)

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

Да я тоже так считаю, но доказать это никак не могу. Вернее, не мог. Щас посмотрим что местные аналитики скажут по этому случаю.

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

Наоборот настолько умный, что рассчитан на глупого пользователя.

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

кто ты такой чтобы называть что то глупым когда сам небось и половины не написал того что критикуешь

YLoS ★★★
()

Я уже давно живу без свопа. Мне конец?

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

кстати да, при 4 гигах своп вообще не использовался, а ныне при двух он немного используется

YLoS ★★★
()

Вангую, что какой-то процесс на машине генерировал слишком много данных, которые не успевали уходить по usbnet. Но вообще выделять память, да тем более с таким order в обработчике прерывания - это похоже на баг в ДНК. Если можешь каким-то образом (любым) уменьшить размер пакета для сетевого интерфейса - попробуй.

А тачка точно умерла? Это не похоже на панику.

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

Не только suse, все {псевдо}графические установщики так говорят.

kir64 ★★
()

Разве это нормальная ситуация? Должно же быть убийство зазравшегося процесса, а не падение системы.

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

А тачка точно умерла?

Неточно выразился, она не то чтобы совсем умерла, но дико залагала и половина ядер были якобы чем-то заняты на 100%. Комманды запускались очень долго. Да и mc не должен столько жрать, имхо.

В ребут сама уйти не смогла, я ей «помог». Но тут, возможно, проблема была в отвалившемся сторадже.

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

Должно же быть убийство зазравшегося процесса

Там нечего убивать - проблема обнаружена в обработчике прерывания.

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

выходит недаром установщик сузи говорит что нельзя без swap

win98 без свопа тоже не могла. даже при 512мб оперативы

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

она не то чтобы совсем умерла, но дико залагала и половина ядер были якобы чем-то заняты на 100%

Я думаю, этот ваш iscsi тупо не тестировался поверх usbnet, вот и полезли ошибки.

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

У подавляющего большинства точно. В любом случае не стоит пихать этот анахронизм в предложения. А то ньюфаги и правда тыкнут, хотя практически у всех больше 2 гигов оперативки всяко.

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

Загрузка была на io, раз сторадж отвалился?

Да, я скопировал два гига данных на сторадж. Потом удалил всё что скопировал, создал btrfs subvolume и начал копировать опять. Вот тут всё и сдохло.

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

Поможет ли в этом случае своп

Снова через iscsi? %)

Даже локальный - вряд ли. У тебя достаточно памяти, она просто фрагментирована. Очень странно, что usbnet хочет сразу order 3.

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

что такого случилось за последний год, что так сильно подорожала память? когда собирал дешёвую замену сдохнувшему штеуду, память стоила около 300 р. за 2 гб, а нынче не менее 800. ну я помню была ситуация с дорогими HDD из за наводнения там где то, ну а с памятью то что? и игори ААА стали стоить не 600 р.

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

тот ваш iscsi тупо не тестировался поверх usbnet

А разве это не независимые подсистемы? Кмк, iscsi должно быть всё равно что там за сеть.

Да и выбора нет — не подключать же iscsi через usb wifi? Впрочем, могу попробовать с другой usb-сетевушкой. Текущая распаяна на плате.

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

от ваш iscsi тупо не тестировался поверх usbnet

А разве это не независимые подсистемы?

Это неважно. Характер нагрузки решает.

Да и выбора нет

Про размер пакета я сказал, еще где-то в недрах /proc должны быть настройки дефрагментации памяти - попробуй их покрутить.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от YLoS

Я отталкиваюсь от наименьшего знаменателя, при котором своп уж точно не нужен. У меня на ноуте 2 гига памяти. Даже если специально пооткрывать кучу всего, то забивается полтора гига. Обычно при работе меньше гига занято. Так что уже при таких значениях в своп лезть банально нечему => он не нужен.

А память дорожает скорее всего из-за скорого перехода на DDR4. Хотя могу и глупость сказать, меня эти железки особо не интересуют.

Akamanah ★★★★★
()
Последнее исправление: Akamanah (всего исправлений: 1)
Ответ на: комментарий от anonymous

CONFIG_COMPACTION не поможет?

Сам по себе вряд ли, но да, двигаться надо в этом направлении.

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

почему oom-killer не включился?

Баг я считаю: при нулевом свопе, вообще не должно было быть попытки его запроса (swapper/0: page allocation)

sdio ★★★★★
()

При чем тут swap?

Swapper это idle тред для каждого ядра. при чем тут swap?

Судя по backtrace код не смог выделить 8 кб памяти (order 3) с флагом GFP_ATOMIC (т.е. получить ее сразу/синхронно), видимо из-за фрагментации

Покрутите /proc/sys/vm/min_free_kbytes.

anonymous
()

Поставь vm.swappiness=0 и, может быть, vm.zone_reclaim_mode=1. Первый точно надо, иначе пейдж кэш выест всю память, и вот такие атомик аллоки начнут обламываться.

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

ЗЯ отталкиваюсь от наименьшего знаменателя, при котором своп уж точно не нужен. У меня на ноуте 2 гига памяти. Даже если специально пооткрывать кучу всего, то забивается полтора гига. Обычно при работе меньше гига занято. Так что уже при таких значениях в своп лезть банально нечему => он не нужен.

Он нужен чтобы в него можнно было загибернейтится. Особенно на ноуте.

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

иначе пейдж кэш выест всю память

Так он по-любому выжрет всё память. Мне казалось что page cache это такая память которую система в любой момент может чуть ли не целиком высвободить, разве нет?

Указанные параметры попробую завтра...

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

Так он по-любому выжрет всё память. Мне казалось что page cache это такая память которую система в любой момент может чуть ли не целиком высвободить, разве нет?

Как ты сам убедился, в контексте прерывания не может.

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

какашка вместо сетевухи детектед!

спасибо, кэп.

true_admin ★★★★★
() автор топика

Это линукс, детка, он умирает когда кончается память. С другой стороны щито ему остаётся делать если памяти взять негде?

anonymous
()
Ответ на: комментарий от mv

Не поможет, AFAIR непрерывную в PA зону реклейминг не трогает, хотя 100 лет прошло, могу и наврать.

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

надо по модулям смотреть кто сожрал всю физически смежную память

а как?

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

Не поможет, AFAIR непрерывную в PA зону реклейминг не трогает, хотя 100 лет прошло, могу и наврать.

Там вопрос в том, что умолчательный swappiness может выгрузить части .so'шек в угоду незаписанным закэшированным данным. В итоге, потребитель сетевого трафика может быть заблокирован на подгрузке с диска, а сетевой драйвер между тем выжрет атомик пул, и привет.

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

не то чтобы совсем умерла, но дико залагала и половина ядер были якобы чем-то заняты на 100%. Комманды запускались очень долго.

Это похоже на симптомы zone_reclaim_mode == 1.

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

Т.е. мне лучше сделать zone_reclaim_mode = 2?

= 0. И сначала проверить, какое значение zone_reclaim_mode имеет после загрузки системы.

Но вообще, лучше делать методично: добиться устойчивого воспроизведения ошибки и попробовать все рекомендации.

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