Jump to content
Калькуляторы

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

Есть сервер 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 by iValera

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Решили проблему с резким всплесокм 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.

 

Share this post


Link to post
Share on other sites

 

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

 

 

 

Share this post


Link to post
Share on other sites
Ставить 7.0, или можно смело релиз-кандидейт лить?

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Всех СНГ!!!

 

Вобщем, пока все гуд. Накапливаем аптайм на "временной" машине с двумя интерфейсами 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

 

 

Share this post


Link to post
Share on other sites

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 с шифрованием.

 

Share this post


Link to post
Share on other sites
Откатиться на mpd 4.4.x

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

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

Share this post


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

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

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
jab, Вы ECC память ставите?

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

Share this post


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

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

Share this post


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

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

Share this post


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

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

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

Share this post


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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this