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]
То есть, несколько тредов одновременно постоянно дерутся за доступ к
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
и пересобрать ядро (и при каждом обновлении исходников придется руками
поддерживать патченым так).
--
WBR, Vadim Goncharov
