Freebsd 7.0 - NAS server \ проблема с SMP

[iValera]

Есть сервер 3logic

 

MicroStar (MSI) P1-105A2, i7230+ICH7R (Mulciteo2), S775

Intel Q6600 LGA775 CORE QUAD 2.4 2x4M 1066 BOX

512MB DDR2-533 PC2-4200 две

Seagate 80Gb SATA-2

 

 

А точнее два. Почти идентичны по железу, но ПО стоит одинаковое:

Задача - сервера доступа.

Freebsd 7.0-STABLE-200807, mpd 5.1.1, ipfw (на таблицах), netgraph, ng_nat, utm5_rfw, dynashape

Прокачка 1го сервера 30Мбит/с, примерно 450 pptp одновременных туннелей.

Прокачка 2го сервера 30Мбит,с 300pptp туннелей.

Т.к. сейчас утро, top с загрузкой выложить не могу, пока только так (250 pptp tun online)

last pid: 96252;  load averages:  0.07,  0.08,  0.04   up 19+15:16:48  10:51:57
58 processes:  2 running, 44 sleeping, 12 waiting
CPU:  0.0% user,  0.0% nice, 37.8% system, 26.6% interrupt, 35.5% idle
Mem: 58M Active, 249M Inact, 174M Wired, 68K Cache, 112M Buf, 1520M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
   11 root        1 171 ki31     0K     8K RUN    162.9H 65.33% idle
   21 root        1 -68    -     0K     8K -      122.1H 14.65% em1 taskq
   12 root        1 -44    -     0K     8K WAIT   112.8H 11.96% swi1: net
   24 root        1 -68    -     0K     8K WAIT   641:42  1.32% irq10: em0 atap
   27 root        1 -68    -     0K     8K -       41.5H  0.00% dummynet
   20 root        1 -68    -     0K     8K -      788:38  0.00% em0 taskq
   13 root        1 -32    -     0K     8K WAIT   111:04  0.00% swi4: clock

В пик idle 0,0% em1 taskq и swi1: net делят загрузку между собой пополам, la подскакивает до двух, новых pptp пользователей начинает отбрасывать (ошибка 800), шелл лагает.

 

Как видно SMP отключен, с его работой - фря может работать без перебоев как один день, так и неделю - а потом виснет или уходит в ребут. Пробовали и SMP, SMP+polling, с HTT - безуспешно, действительно ли SMP ещё сыроват?

Второй сервер с нагрузкой послабее - всё тоже самое - ребуты и зависание, причём могут быть как в 10 утра (когда нагрузки никакой, а могут быть и в вечером). Ставили 6.x - тоже самое.

 

Сейчас от безысходности работаем на одном ядре, нагрузка постепенно растёт, трафик + туннели. не знаем как дальше тянуть.

cat /etc/sysctl.conf

net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=5
net.link.ether.inet.proxyall=1

net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
kern.ipc.somaxconn=512
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.inet.ip.redirect=0
net.inet.ip.dummynet.hash_size=1024
net.inet.ip.dummynet.expire=1
net.inet.ip.dummynet.max_chain_len=32
net.inet.ip.dummynet.io_fast=1

# em driver tuning
dev.em.0.rx_processing_limit=200
dev.em.1.rx_processing_limit=200

 

Куда копнуть?

Спасибо.

Edited December 22, 2008 by iValera

[jab]

 

Откатиться на mpd 4.4.x

[kaN5300]

А нам так нравился netflow из коробки =)

[mikevlz]

в 4.4.х тоже есть нетфлоу из коробки

[kaN5300]

Низнал. mikevlz, спасибо. Но мы для начала попробуем 5.2 (сейчас стоит 5.1).

[a_andry]

Стоит 3 впн-а с немного разным железом, все с SMP mpd 5.2. Один тоже постоянно в ребут уходил. Помогло обновление до 7.1-PRERELEASE и выкидывание всего лишнего/никритичного.

[kaN5300]

Решили проблему с резким всплесокм lavg при высоком к-ве ng-интерфейсов. Ядро не выделяло больше 60 мегов на процесс (mpd5). Решили путем введения следующих параметров ядра:

 

options         MAXDSIZ=(2048UL*1024*1024)
options         MAXSSIZ=(728UL*1024*1024)
options         DFLDSIZ=(1024UL*1024*1024)

 

Но и не смотря на это, существует еще одна большая проблема. Сервак виснет произвольно в любой момент времени не важно при какой нагрузке. При этом остается возможность удаленного доступа (ssh). top -S кажет в поле STATE для swi1: net *in_mu, а для dummynet *if_ad. Согласно man, STATE, это событие, на котором происходит ожидание процесса. Как правило, это WAIT (в штатном режиме функционирования нашего сервера доступа). По вышеуказанным статусам я ничего не нагуглил.

 

Есть подозрение, что "не вытягивает" dummynet. В ipfw всего 2889 правил, из них 2850 - пайпы. Сейчас у пользователей приобладают высокоскоростные безлимитные тарифы и мы не исключаем, что причиной сбоя является зараженный клиент. В ближайшее время постараемся перевести dummynet на таблицы, либо вобще уйти от ipfw в пользу pf, а шейпинг будет реализован через ng_car.

 

[jab]

 

Правильно сконфигуреный pf все-равно жрет больше проца, чем ipfw с dummynet в stateless mode при примерно одинаковых конфигурациях.

То есть - если не нужно делать pf nat + altq, то лучше обойтись dummynet с табличками и ветвлением через skipto. Если же в ipfw делается

навороченный stateful, то имеет смысл смотреть на pf.

[kaN5300]

Ув. jab, благодарю за ответ. Таблицы успешно удалось внедрить в механизм контроля доступа, с pipe пытался - не вышло. Буду пробовать снова. Вместе с этим посмотрим в сторону использования skipto.

 

Еще в догонку (пока везут новое железо для экспериментов). Ставить 7.0, или можно смело релиз-кандидейт лить?

[jab]

Ув. jab, благодарю за ответ. Таблицы успешно удалось внедрить в механизм контроля доступа, с pipe пытался - не вышло. Буду пробовать снова. Вместе с этим посмотрим в сторону использования skipto.

А чего там внедрять-то ? И здесь и на opennet'е десять раз обсасывалось. Хоть с tablearg, хоть без него. skipto используется для того, чтобы минимизировать количество

правил, сквозь которые проходит каждый пакет. Чем длиннее цепочка, тем больше нагрузка на CPU, и после некоторого количества правил ( скажем более 1000 ) нагрузка

растет экспоненциально. В результате при попытке прогнать 10kpps сквозь последнее правило - тачка встает намертво. Особенно если там allow from any to any.

 

Еще в догонку (пока везут новое железо для экспериментов). Ставить 7.0, или можно смело релиз-кандидейт лить?

Ну я бы не ставил, у меня по-моему моложе 7.0-RELEASE-p4 ничего нету...

[kaN5300]

С наступающим!

 

Что было сделано:

 

1) Перевели шейпирование на таблицы (вот такая конструкция):

 

pipe 40961 config bw 4096Kbit/s mask src-ip 0xffffffff
pipe 40962 config bw 4096Kbit/s mask dst-ip 0xffffffff
100 pipe tablearg ip from table\(2\) to any in recv ng*
200 pipe tablearg ip from any to table\(22\) out xmit ng*

 

2) Полностью отказались от stateful режима. Сейчас есть сервера работающие в старом режиме (statefull - пускай и частичный). Там к-во динамических правил примерно равно к-ву абонентов онлайн помноженного на 1.5. Т.е. сейчас на наиболее загруженном насе 534 динамических правила.

 

3) Почистили сами правила, оставили самое необходимое. Сократили к-во правил с 2955 до 30. Помогло как введение таблиц, так и выкидывание ненужных строчек.

 

4) С целью исключения двойного прохождения пакетов по одному правилу постарались максимально подробно указать направление прохождение пакета (in, out / recv, xmit).

 

Чего не делали:

 

1) Для skipto применения не нашлось. Решили, что с 30-ю правилами и так будет нормально.

2) Читаем про тюнинг sysctl-ов для более производительной работы dummynet

 

О результатах тестирования отпишусь.

 

 

 

[Blackmore]

Ставить 7.0, или можно смело релиз-кандидейт лить?

релиз кандидат ставить - в чистой 7,0 есть проблемы, которые уже пофиксили, с mpd5.2 на релизе кандидате проблем пока нет

[kaN5300]

Я кстати, когда качал rc1 почему-то при переходе на ftp-сцылу обнаружил RC2. А в новостяъ про это ничего нет. В роадмапе у них помоему 7.1 уже вот-вот. Её-то и поставим при первой же возможности.

[kaN5300]

Всех СНГ!!!

 

Вобщем, пока все гуд. Накапливаем аптайм на "временной" машине с двумя интерфейсами rtl8139 =)

 

last pid: 86725;  load averages:  0.01,  0.01,  0.00    up 5+06:31:52  20:45:48
62 processes:  2 running, 44 sleeping, 16 waiting
CPU:  0.8% user,  0.0% nice,  4.3% system, 21.9% interrupt, 73.0% idle
Mem: 16M Active, 204M Inact, 144M Wired, 92K Cache, 112M Buf, 1625M Free
Swap: 1024M Total, 1024M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
   11 root        1 171 ki31     0K     8K RUN    107.7H 84.28% idle
   22 root        1 -68    -     0K     8K WAIT   596:11 13.87% irq10: rl0 rl1
   12 root        1 -44    -     0K     8K WAIT   288:13  4.59% swi1: net
   30 root        1 -68    -     0K     8K -      146:42  0.00% dummynet
   13 root        1 -32    -     0K     8K WAIT    33:09  0.00% swi4: clock sio
   15 root        1  44    -     0K     8K -       15:06  0.00% yarrow
  719 root        1  44    0  8824K  5168K select   7:01  0.00% snmpd
   36 root        1  20    -     0K     8K syncer   4:20  0.00% syncer

 

Дамминет судим по показателю TIME. После всяческих оптимизаций этот показатель упал по сравнению с остальными процессами.

 

<kan5300@nas4>netstat -s -p ip
ip:
        2424834596 total packets received
        43 bad header checksums
        0 with size smaller than minimum
        5 with data size < data length
        0 with ip length > max ip packet size
        0 with header length < data size
        0 with data length < header length
        0 with bad options
        0 with incorrect version number
        1432783 fragments received
        0 fragments dropped (dup or out of space)
        4851 fragments dropped after timeout
        712790 packets reassembled ok
        699142507 packets for this host
        2875 packets for unknown/unsupported protocol
        1438769544 packets forwarded (0 packets fast forwarded)
        130636 packets not forwardable
        433661 packets received for unknown multicast group
        0 redirects sent
        888643261 packets sent from this host
        0 packets sent with fabricated ip header
        452 output packets dropped due to no bufs, etc.
        0 output packets discarded due to no route
        83994 output datagrams fragmented
        168186 fragments created
        14517 datagrams that can't be fragmented
        0 tunneling packets that can't find gif
        0 datagrams with bad address in header

 

 

[mikevlz]

vpn2# netstat -s -p ip
ip:
        1706042421 total packets received
        100704 bad header checksums
        0 with size smaller than minimum
        45 with data size < data length
        0 with ip length > max ip packet size
        0 with header length < data size
        0 with data length < header length
        0 with bad options
        0 with incorrect version number
        0 fragments received
        0 fragments dropped (dup or out of space)
        0 fragments dropped after timeout
        0 packets reassembled ok
        2102676878 packets for this host
        4821130 packets for unknown/unsupported protocol
        367003331 packets forwarded (631763883 packets fast forwarded)
        14493113 packets not forwardable
        5366937 packets received for unknown multicast group
        0 redirects sent
        976081913 packets sent from this host
        1892783 packets sent with fabricated ip header
        65925 output packets dropped due to no bufs, etc.
        0 output packets discarded due to no route
        424738 output datagrams fragmented
        898993 fragments created
        116612 datagrams that can't be fragmented
        0 tunneling packets that can't find gif
        2273 datagrams with bad address in header

last pid: 88707;  load averages:  0.17,  0.10,  0.03                                                                          up 43+05:09:51  17:43:04
79 processes:  3 running, 57 sleeping, 19 waiting
CPU states:  1.0% user,  0.0% nice,  1.4% system,  1.0% interrupt, 96.5% idle
Mem: 43M Active, 11M Inact, 85M Wired, 836K Cache, 55M Buf, 1857M Free
Swap:

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME    CPU COMMAND
   10 root        1 171   52     0K     8K CPU1   1 1031.0 98.93% idle: cpu1
   11 root        1 171   52     0K     8K RUN    0 871.2H 96.53% idle: cpu0
62360 root        2  96    0 52088K 28936K select 1 107:01  0.10% mpd5
   14 root        1 -44 -163     0K     8K WAIT   0 122.2H  0.05% swi1: net
  541 root        1  96    0  5988K  3588K select 1  55:31  0.05% zebra
   42 root        1 -68    0     0K     8K -      0  21.5H  0.00% dummynet
   12 root        1 -32 -151     0K     8K WAIT   0 779:24  0.00% swi4: clock sio

vpn2# uname -a
FreeBSD vpn2.******* 6.3-RELEASE-p3 FreeBSD 6.3-RELEASE-p3 #0: Mon Nov  3 14:21:59 MSK 2008     admin@***********:/usr/obj/nanobsd.full/usr/src/sys/router  i386

Вот как-то так...

mpd5.2 если интересно.

Камень - что-то из C2D Е8*00. Интелевская серверная мама на 3210SHLX. Сетевухи встроенные.

В пиках 500 человек на тазик, pptp с шифрованием.

 

[doubtpoint]

Откатиться на mpd 4.4.x

Вот как раз 4.4.1 стоит. Пробовали 7.1, 7.1 RC2, 6.4 везде виснет два раза в сутки. Причем рядом стоят еще два сервера с аналогичными конфигами и работают без проблем.

Решение найдено?

[jab]

Вот как раз 4.4.1 стоит. Пробовали 7.1, 7.1 RC2, 6.4 везде виснет два раза в сутки. Причем рядом стоят еще два сервера с аналогичными конфигами и работают без проблем.

Решение найдено?

Чудес не бывает. Если из трех одинаковых тачек с _идентичными_ конфигами одна виснет - либо меняйте железо, либо ищите чем они отличаются.

[Giga-Byte]

Чудес не бывает. Если из трех одинаковых тачек с _идентичными_ конфигами одна виснет - либо меняйте железо, либо ищите чем они отличаются.

jab, Вы ECC память ставите?

[mikevlz]

а смысл?

[kaN5300]

ECC ИМХО для СУБД имеет смысл ставить. На роутер смысла нет.

[jab]

jab, Вы ECC память ставите?

Нет. У меня стоимость двойной ошибки мизерная.

[YuryD]

Чудес не бывает. Если из трех одинаковых тачек с _идентичными_ конфигами одна виснет - либо меняйте железо, либо ищите чем они отличаются.

Бывают, на одной и той-же машине с ядром smp и без smp. C SMP виснет или трапается os, либо mpd5 тупо висит и не убивается. Железо одно и то-же, траффик аналогичен, то есть решение проблемы есть, но неправильное :)

[jab]

Бывают, на одной и той-же машине с ядром smp и без smp. C SMP виснет или трапается os, либо mpd5 тупо висит и не убивается. Железо одно и то-же, траффик аналогичен, то есть решение проблемы есть, но неправильное :)

Ну если Вы считаете что "с SMP" и "без SMP" - это идентичные конфиги, то мне тут добавить нечего. Тут в консерватории что-то.

[YuryD]

Бывают, на одной и той-же машине с ядром smp и без smp. C SMP виснет или трапается os, либо mpd5 тупо висит и не убивается. Железо одно и то-же, траффик аналогичен, то есть решение проблемы есть, но неправильное :)

Ну если Вы считаете что "с SMP" и "без SMP" - это идентичные конфиги, то мне тут добавить нечего. Тут в консерватории что-то.

Это разные сборки из одних и тех-же исходников :) Много чего разного и в библиотеках, но мне от того, что где-то присутствует неявный глюк(dummynet,netgraph, само ядро) как-то не очень хорошо...

[jab]

Это разные сборки из одних и тех-же исходников :) Много чего разного и в библиотеках, но мне от того, что где-то присутствует неявный глюк(dummynet,netgraph, само ядро) как-то не очень хорошо...

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