Hello, Vadim Goncharov!
On Sat, Mar 19, 2011 at 01:18:13AM +0600
vadimnucli...@tpu.ru wrote about "Re: [freebsd] em, input errors and kernel
load":
> 18.03.11 @ 21:45 Alexey Karguine wrote:
>
>
> >>Ну так vmstat вышеуказанный-то где?
> >>
> >Только что был очередной приступ. vmstat -{zm} сделать успел. Результат
> >в приложенных файлах. Посмотрите пожалуйста, сам я в эти цифрахникогда
> >не разберусь.
>
> В vmstat -z ничего такого нет, кроме большого числа кэша vnode (к 82000
> файлов обращались), да еще строки:
>
> 128: 128, 0, 137977, 50663, 107517508, 0
>
> которую проясняет vmstat -m:
>
> Type InUse MemUse HighUse Requests Size(s)
> libalias 137337 17231K - 107197469 128
>
> Число не ахти какое большое, но больше ничего подозрительного в vmstat
> -m/-z нет.
>
> >>Это программная проблема, taskq уже не в hardware interrupt крутится,
> >>так что не поможет.
> >>
> >>http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html
> >>
> >>- пересобрать ядро по инструкции отсюда, попробовать остальные шаги во
> >>время затыка.
> >
> >Сделал. Чтобы не поднимать трафик в рассылке файл с выходными данными
> >(~290 килобайт) выложил тут: http://dl.dropbox.com/u/83258/hwpmc.txt
> >
> >Делал так:
> >- во время затыка запустил pmcstat -S instructions -O /tmp/sample.out
> >- нажал ctrl-c после того, как затык прошёл. Получил такое вообщение в
> >консоле:
> >pmcstat: WARNING: some events were discarded. Please consider tuning
> >the "kern.hwpmc.nbuffers" tunable.
> >- pmcstat -R /tmp/sample.out -k /boot/kernel/kernel -g
> >- gprof /boot/kernel/kernel /tmp/INSTR_RETIRED_ANY/kernel.gmon
>
> Да в общем-то можно было не выкладывать, там самое главное в строчках
> Top-5 пожирателей времени (80% времени в сумме):
>
> % cumulative self self total
> time seconds seconds calls ms/call ms/call name
> 36.9 233576.00 233576.00 3080 75836.36 76859.98 sched_idletd [9]
> 28.2 411599.00 178023.00 799402 222.70 222.70 _mtx_lock_sleep [11]
> 11.8 485951.00 74352.00 252 295047.62 296047.62 _FindLinkIn [16]
> 2.1 499405.00 13454.00 2390 5629.29 116656.65 ipfw_chk [6]
> 1.8 510634.00 11229.00 11536 973.39 1001.30 rn_match [26]
>
> Это явный lock contention (glebius@ тут считает, что если сделать ядро с
> MUTEX_PROFILING, то будет видно, что libalias лок - most contended). Там
> выше в call graph есть подтверждение:
>
> called/total parents
> index %time self descendents called+self name index
> called/total children
>
> 485.00 227154.59 678354/678354 ipfw_nat [8]
> [10] 36.0 485.00 227154.59 678354 LibAliasIn [10]
> 151066.41 1.70 678355/799402 _mtx_lock_sleep [11]
> 1053.00 75033.48 794/794 LibAliasInLocked [14]
>
> То есть, несколько тредов одновременно постоянно дерутся за доступ к
Вадим, можно мне пояснить, вернее разжевать, такое: нагрузка в emX:
taskq. Так? В первых постах топикстартер показывает свой трафик:
7-10кппс и 7-9МБс. На такой нагрузке нат как бы не должен
выпендриваться. Почему вспсплески по CPU у топикстартера получаются?
У меня более слабая машинка натила под 200мбит без проблем!
> instance ната - оно не параллелится. Решение: натить в несколько внешних
> IP-адресов, для каждого заводить отдельный инстанс libalias (ipfw nat). Я
> в свое время бил кусками по /28 (16 адресов на один внешний), исходя из
> лимитов числа соединений с адреса на торрент-трекерах, аськосерверах и т.д.
>
> Еще вариант, менее выигрышный и более сложный: пропатчить исходники, в
> /usr/src/sys/netinet/libalias/alias_local.h необходимо найти и заменить
> две константы, которые cо времен 7.1 равняются 4001. Сделать их такими:
>
> #define LINK_TABLE_OUT_SIZE 8123
> #define LINK_TABLE_IN_SIZE 16411
>
> и пересобрать ядро (и при каждом обновлении исходников придется руками
> поддерживать патченым так).
--
Lystopad Olexandr
