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)
Ответ на: комментарий от mashina

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

Ни разу не сталкивался, чтобы на время suspend не хватало батареи. Тем более не актуально для стационара.
А когда памяти 16-64ГБ, боюсь представить, сколько времени она будет загоняться в своп. И протекающие процессы вызовут только лишние проблемы.

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

какое значение zone_reclaim_mode имеет после загрузки системы.

Нету такой переменной на тачке :( Ядро 3.8.14 (точнее, ветка 3.8 из git), конфиг тут: http://dpaste.com/hold/1565877/

Я пока не понял почему нет этого sysctl, по сырцам пока непонятно.

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

Если интересно, я для гибернации делал vm.drop_caches=3 и включал компрессию. Разница на моих задачах была в разы.

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

На моём ноутбуке 6 гигабайт оперативы, 9 гигабайт свопа, в данный момент чуть меньше двух гигабайт свопа занято.

Не вижу смысла экономить на свопе. ОЗУ дешевая, но ПЗУ ещё дешевле.

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

CONFIG_COMPACTION не поможет?

оно уже стоит

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

На моём ноутбуке 6 гигабайт оперативы, 9 гигабайт свопа, в данный момент чуть меньше двух гигабайт свопа занято.

На десктопах не сталкивался с нехваткой памяти со времен, когда было 2ГБ. А если не хватает - то что-то пошло не так и течет. Для специфических задач нужно рассчитать потребление и действовать из необходимой отзывчивости/производительности.

Не вижу смысла экономить на свопе. ОЗУ дешевая, но ПЗУ ещё дешевле.

Своп в ПЗУ? Оригинально.

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

Всё, виновник найден, это smsc95xx драйвер и параметр turbo_mode

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

нашёл что это распространённая проблема с usbnet: https://github.com/raspberrypi/linux/issues/153

Там приведен и вполне логично выглядящий воркароунд. Или, если чувствуешь в себе Силу, попробуй настроить дефрагментатор памяти.

Жесть :(

Обычное дело.

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

Там приведен и вполне логично выглядящий воркароунд

Ты про smsc95xx.turbo_mode=N, vm.min_free_kbytes=2048 или про патч ядра?

Я уже воткнул внешнюю сетевушку. Увы, 100мбит какашка, но хоть драйвер другой.

попробуй настроить дефрагментатор памяти.

Это как? CONFIG_COMPACTION=y уже стоит.

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

Ты про smsc95xx.turbo_mode=N, vm.min_free_kbytes=2048 или про патч ядра?

Про отключение turbo.

попробуй настроить дефрагментатор памяти.

Это как? CONFIG_COMPACTION=y уже стоит.

Дефрагментатор настраивается. См. Documentation/sysctl/vm.txt

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

Своп в ПЗУ? Оригинально.

Прошу прощения, имел в виду энергонезависимую память.

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

Постоянные потребители: 60 вкладок в фаерфоксе (не все, правда, загружены в память), около десяти вкладок в хромиуме в куча открытых pdf, libreoffice. Приложения не закрываю днями.

Иногда запускаю что-нибудь тяжелое, что всё это хозяйство вытесняется в своп.

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

а swappiness какая была выставлена?

vm.swappiness = 60, но свопа не было — спасибо btrfs.

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

Видимо у нас разные юзкейсы относительно этого.

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

Это всё очень на как повезёт. Сравни магии и шаманству.

Ну почему же, я это регулярно вижу. Своп из текущего дизайна убирать не хотят, и своппинесс трогать тоже, поэтому любая сволочь, пищущая много байт без O_DIRECT, часто вызывает ситуацию наподобие как у ТС (атомик пул пустой), либо столько сегментов данных у многочисленных .so'шек в памяти не окажется, что очень нервный вотчдог срабатывает.

На приватных билдах со своппинесс=0 ничего такого нет.

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