[telefan]

После перехода на новый nas наблюдался странный глюк: после 30 часов работы пропал из сети сервер, причем его оба интерфейса один с реальным адресом, а второй с серым смотрящим в сеть. Отсутствовал пинг на оба, при этом на управляемом коммутаторе оба порта показывали активное состояние. При подключение клавы и монитора, обнаружилось что система не висит! А нормально логиниться в консоле, но при попытке пропинговать другие сервера проскочил только один случайный пинг! К сожалению перезагрузку проводил не я лично, поэтому провести диагностику системы не удалось. Может у кого возникали подобные ситуации, было бы неплохо предупредить заранее такие приколы системы. Конфигурация системы:

7.0-RELEASE FreeBSD 7.0-RELEASE #4: Mon Dec 29 17:39:11 EET 2008 ***********:/usr/obj/usr/src/sys/VPNGATE i386

конфиг ядра стандартный, добавлено вот что:

# netgraph

options NETGRAPH

options NETGRAPH_IPFW

options NETGRAPH_PPP

options NETGRAPH_PPTPGRE

options NETGRAPH_L2TP

options IPFIREWALL

options IPFIREWALL_DEFAULT_TO_ACCEPT

options DUMMYNET

ну и выкинуты лишние девайсы из железа которого нет.

Железо такое:

CPU: Intel® Core2 CPU E8500 @ 3.16GHz (3165.08-MHz 686-class CPU)

Origin = "GenuineIntel" Id = 0x1067a Stepping = 10

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLU

SH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0x309<SSE3,MON,TM2,SSSE3>

AMD Features=0x20100000<NX,LM>

AMD Features2=0x1<LAHF>

Cores per package: 2

real memory = 1071620096 (1021 MB)

avail memory = 1038602240 (990 MB)

ACPI APIC Table: <INTEL S3200SHV>

FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs

cpu0 (BSP): APIC ID: 0

cpu1 (AP): APIC ID: 1

сетевые PCI-E INTEL 1000/ буквы не помню, дрова родные фряки em

 

На системе кроме mpd4 который термирует PPTP еще крутиться ng_nat и шейпер средствами ipfw, больше ничего.

[kaN5300]

Знакомая ситуация, только у нас один из ифейсов жил. В следующий раз сфотографируйте вывод top -S и обратите внимание на STATE процессов ядра типа swi1: net. И загляните в нашу тему соседнюю:

 

http://forum.nag.ru/forum/index.php?showtopic=46227

 

Может быть вам тоже для профилактики не помешает пощаманить с ipfw или можно еще обновиться на 7.1 и 5.2.

[doubtpoint]

Знакомая ситуация, только у нас один из ифейсов жил. В следующий раз сфотографируйте вывод top -S и обратите внимание на STATE процессов ядра типа swi1: net. И загляните в нашу тему соседнюю:

 

http://forum.nag.ru/forum/index.php?showtopic=46227

 

Может быть вам тоже для профилактики не помешает пощаманить с ipfw или можно еще обновиться на 7.1 и 5.2.

Так а решение нейдено?

И почему до нового года все тоже самое работало, а сейчас два раза на дню глючит?

[kaN5300]

Лолово! У нас ДО НОВОГО ГОДА два раза на дню глючило. С нашей т.з. надо копать в сторону ipfw+dummynet. Параллельно (если есть возможность) подготовьте тачку с 7.1 + mpd 5.2. Отключите SMP пока на время. В личку можно было не писать, я подписан на тему.

[doubtpoint]

глючит и при отключенном ipfw+dummynet(голая система-только mpd4.4.1_1). 6.4 и 7.1 релизы ставить не помогает. МПД 5 версию пока не ставил

 

PS: Заметил, что без СМП нагрузка(общая на систему) если не меньше, то точно не больше :-) Хотя может сам не заметив, что то подкрутил.

PSS: Блин, а у нас с нового года глючит. Все праздники уже испортило и нам и нашим абонентам.

 

[AlKov]

В июне прошлого года, когда я еще только собирался "строить" NAS, также хотел ставить mpd5 на FreeBSD 7.0.

Но один человек, имеющий отношение к разработке mpd, отсоветовал ставить на 7.0, сказав что на ней у мпд есть проблемы. В итоге сейчас имею в качестве NAS такой "комплект":

FreeBSD 6.3+mpd5.1+ng_car.

ipfw и dummynet не юзаю, шейпер на ng_car, сейчас максимум в он-лайн чуть более 160 pptp сессий, полгода полет нормальный.

 

P.S Ставил 6.3 amd64, SMP.

 

[jab]

 

6.2-STABLE i386, SMP, polling, mpd4 - PPPoE до 800 сессий в пике, аптайм больше года.

7.0-STABLE amd64, SMP, polling, mpd4 - PPPoE до 1000 сессий, аптайм два месяца с момента апгрейда.

 

mpd5 в тестах больше недели не живет. По симптомам - намертво виснет netghraph а за ним ядро. Отлаживать нет никакого желания,

и так все работает.

[IvanI]

гы

7.1-BETA2 из портов mpd5.1, проц E4700, памяти 2 гига, 1ая сетевуха встроенная, 2ая сетевуха PCI-E за 1500 р, полинга нет, есть NG_NAT, NG_CAR примерно 1/3 отовсех тунелей и NG_NETFLOW

ща

last pid: 98988; load averages: 0.16, 0.07, 0.02 up 23+22:00:38 14:54:42

59 processes: 3 running, 44 sleeping, 12 waiting

CPU 0: 0.0% user, 0.0% nice, 6.4% system, 14.7% interrupt, 78.9% idle

CPU 1: 0.4% user, 0.0% nice, 6.8% system, 20.3% interrupt, 72.6% idle

Mem: 27M Active, 139M Inact, 202M Wired, 60K Cache, 199M Buf, 1625M Free

Swap: 4096M Total, 4096M Free

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

12 root 1 171 ki31 0K 8K RUN 0 477.7H 82.57% idle: cpu0

11 root 1 171 ki31 0K 8K CPU1 1 472.8H 71.00% idle: cpu1

13 root 1 -44 - 0K 8K WAIT 1 122.7H 35.99% swi1: net

22 root 1 -68 - 0K 8K - 1 19.8H 6.49% em1 taskq

21 root 1 -68 - 0K 8K - 0 701:31 3.17% em0 taskq

14 root 1 -32 - 0K 8K WAIT 1 30.8H 0.00% swi4: clock

7552 root 1 96 0 39900K 22120K select 0 83:55 0.00% mpd5

16 root 1 44 - 0K 8K - 0 80:42 0.00% yarrow

34 root 1 20 - 0K 8K syncer 0 33:07 0.00% syncer

497 root 1 44 0 3184K 1220K select 1 6:27 0.00% syslogd

 

test# ifconfig | grep 0xffffffff -c

343

 

input (vlan41) output

packets errs bytes packets errs bytes colls

6346 0 5811641 5409 0 2433655 0

5716 0 5230470 4866 0 2054890 0

6144 0 5820495 5230 0 2269229 0

6004 0 5872299 4886 0 2001080 0

6059 0 5911207 4964 0 1958307 0

6107 0 6013049 5101 0 2151798 0

5716 0 5465627 4722 0 2037892 0

5789 0 5598561 4670 0 2017926 0

5365 0 4879966 4519 0 2045118 0

6558 0 6558699 5262 0 1987275 0

6006 0 5986959 4899 0 2058705 0

5895 0 5521508 5082 0 2256015 0

5872 0 5381156 4980 0 2196205 0

5329 0 4997774 4475 0 2003883 0

5318 0 4871710 4662 0 1973492 0

5354 0 4960851 4594 0 2114040 0

пик

test# ifconfig | grep 0xffffffff -c

983

 

last pid: 93517; load averages: 0.11, 0.13, 0.12 up 6+05:00:23 21:54:27

81 processes: 5 running, 65 sleeping, 11 waiting

CPU: 3.0% user, 0.0% nice, 13.3% system, 42.1% interrupt, 41.5% idle

Mem: 42M Active, 136M Inact, 205M Wired, 60K Cache, 199M Buf, 1610M Free

Swap: 4096M Total, 4096M Free

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

13 root 1 -44 - 0K 8K CPU0 0 888:04 95.07% swi1: net

11 root 1 171 ki31 0K 8K RUN 1 136.5H 50.39% idle: cpu1

12 root 1 171 ki31 0K 8K RUN 0 136.7H 31.88% idle: cpu0

22 root 1 -68 - 0K 8K - 1 138:57 11.67% em1 taskq

21 root 1 -68 - 0K 8K - 0 85:02 6.30% em0 taskq

14 root 1 -32 - 0K 8K WAIT 1 216:03 0.20% swi4: clock

515 root 1 96 0 38364K 21836K RUN 1 32:36 0.00% mpd5

16 root 1 44 - 0K 8K - 1 17:15 0.00% yarrow

34 root 1 20 - 0K 8K syncer 1 7:49 0.00% syncer

497 root 1 44 0 3184K 1220K select 0 0:43 0.00% syslogd

3 root 1 -8 - 0K 8K - 0 0:14 0.00% g_up

2 root 1 -8 - 0K 8K - 1 0:14 0.00% g_event

4 root 1 -8 - 0K 8K - 1 0:13 0.00% g_down

663 root 1 44 0 5876K 3444K select 1 0:08 0.00% sendmail

35 root 1 -16 - 0K 8K sdflus 1 0:06 0.00% softdepflush

18438 ivan 1 44 0 8428K 3960K select 0 0:04 0.00% sshd

 

packets errs bytes packets errs bytes colls

25651 0 30901097 16957 0 3059234 0

25917 0 31298582 17049 0 3119562 0

25335 0 30135416 17072 0 3265536 0

25133 0 30418535 16513 0 3054320 0

24977 0 30217477 16351 0 3098735 0

25360 0 29722012 16981 0 3210105 0

25608 0 30341137 16889 0 3107878 0

25604 0 30283843 17188 0 3131430 0

25373 0 30668572 16621 0 3080581 0

24319 0 28819196 16248 0 3168691 0

25544 0 30037259 17099 0 3383235 0

25360 0 30247126 16816 0 3283032 0

25327 0 30634926 16688 0 3079939 0

25442 0 30234449 16719 0 3094359 0

24889 0 29933375 16426 0 2943514 0

24590 0 29462213 16232 0 3072699 0

25262 0 29874257 16786 0 3118942 0

25344 0 30312720 16756 0 3123351 0

25324 0 30158998 16893 0 3112708 0

25375 0 29927559 17090 0 3390987 0

input (vlan41) output

packets errs bytes packets errs bytes colls

25444 0 30234870 17043 0 3338572 0

25148 0 29896943 16603 0 3094190 0

25177 0 29938128 16543 0 3251703 0

25387 0 30193201 16711 0 3270854 0

25029 0 29817014 16716 0 3363488 0

25182 0 29985351 16563 0 3281746 0

25605 0 30351401 16871 0 3133067 0

25541 0 30339304 16826 0 3364707 0

24924 0 29691744 16521 0 3276049 0

25204 0 30503856 16653 0 3217027 0

[mikevlz]

живет, вот только я наверное что-то недотюнил, у меня оно на 6.3/mpd5.2 не хочет тащить больше 600 подключений нормально...

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

Но это решаемо...

[Mechanic]

соглсен, почему-то после 500-600 тунелей начинаются проблемы вида- небольшого числа потери пакетов, не соответствие скоростей у абонентов

система 7.0+mpd5.2 ng_nat_netflow ipfw+dummynet тарифы нарезаем- стандартные анлимы

на системе с 6.3+mpd4.1 (потом mpd5.2)

[doubtpoint]

В июне прошлого года, когда я еще только собирался "строить" NAS, также хотел ставить mpd5 на FreeBSD 7.0.

как уже писал - на 7.0 и 6.3 + mpd 4.4.1 работало нормально более двух лет на 3х серверах с количеством ссейсий одновременно более 1000(>200мбит+15Кpps в каждую сторону на каждом). Но потом, что-то поменялось(возможно, обновтлось ядро к 6.4 и 7.1) и началось...

 

Сейчас поставил без SMP 6.3. Работает второй день. Раньше было 2 ядра 3ггца(вроде xeon 3110). Теперь 1(проц тот же). Нагрузка уменьшилась до 20%(была 50, но возможно поменяли что-то в конфигах).

[IvanI]

Mechanic

Были глюки при количестве тунелей более 800, вылечил так:

sysctl net.inet.ip.fw.dyn_max=65000

[kaN5300]

Mechanic

Были глюки при количестве тунелей более 800, вылечил так:

sysctl net.inet.ip.fw.dyn_max=65000

net.inet.ip.fw.dyn_max - целочисленная переменная. Максимальное количество одновременно существующих динамических правил. Значение по умолчанию - 8192.

 

А может ну их нафиг эти динамические правила? Переводить ipfw в stateless режим не пробовали?

[No_name]

В июне прошлого года, когда я еще только собирался "строить" NAS, также хотел ставить mpd5 на FreeBSD 7.0.

Но один человек, имеющий отношение к разработке mpd, отсоветовал ставить на 7.0, сказав что на ней у мпд есть проблемы...

mpd5 в тестах больше недели не живет. По симптомам - намертво виснет netghraph а за ним ядро. Отлаживать нет никакого желания,

и так все работает.

Правильно говорят. Ставил FreeBSD 7.0 + mpd 4.4.1 симптомы как у жаба были,

плюнул поставил FreeBSD 6.1 + mpd 4.4.1, все работает как часы до 500 сессий PPTP, правда канал не большой, но не суть, аптайм с сентября.

Изменено 10 января, 2009 пользователем ma4o

[IvanI]

Tак нет в конфиге динамики, есть таблици и "limit src-addr"

net.inet.ip.fw.dyn_count: 1062

с утра.

[Илья Дмитриевич]

А как себя ведёт 7.1 и mpd 5.2 сижу перед делемой стоит ли обновлять сервер .. потоки скромные, количество сессий маленькое .. ?

p.s сервер без smp

Изменено 11 января, 2009 пользователем Илья Дмитриевич

[jab]

А как себя ведёт 7.1 и mpd 5.2 сижу перед делемой стоит ли обновлять сервер .. потоки скромные, количество сессий маленькое .. ?

p.s сервер без smp

Тут весь раздел забит воплями тех, у кого зуд обновления сильнее зуда предварительного тестирования. Если работает - зачем апгрейдить ?

[kaN5300]

А как себя ведёт 7.1 и mpd 5.2 сижу перед делемой стоит ли обновлять сервер .. потоки скромные, количество сессий маленькое .. ?

p.s сервер без smp

Тут весь раздел забит воплями тех, у кого зуд обновления сильнее зуда предварительного тестирования. Если работает - зачем апгрейдить ?

Работает - не трогай, как говорится =)

 

Tак нет в конфиге динамики, есть таблици и "limit src-addr"

net.inet.ip.fw.dyn_count: 1062

с утра.

net.inet.ip.fw.dyn_count: 0

При 121-м туннеле на оптимизированном сервере.

 

На "старом":

net.inet.ip.fw.dyn_count: 289

 

Читайте внимательно, что такое stateless логика.

 

[AlKov]

Дополню еще немного..

В июне прошлого года, когда я еще только собирался "строить" NAS, также хотел ставить mpd5 на FreeBSD 7.0.

Но один человек, имеющий отношение к разработке mpd, отсоветовал ставить на 7.0, сказав что на ней у мпд есть проблемы...

До установки NAS, поинтересовался о том, на чем лучше реализовать шейпер в этой связке (FreeBSD+mpd5+Radius), получил ответ, что на dummynet это работает неустойчиво и лучше реализовать шейпер на ng_car. Что и сделал. Работает отменно! Тьфу-тьфу-тьфу! Тук-тук-тук! :D

При авторизации пользователя, отправляю к mpd с помощью Radius-а две reply пары

mpd-limit +=in#1=all shape 128000 8000 pass
mpd-limit +=out#1=all shape 128000 8000 pass

которые "вешаются" на соотв. фейс ng_car и все! Никакого громадья ipfw таблиц, ipfw на этой машине вообще не использую, есть только pf, в котором минимум правил (только фаервол), NAT на линукс-роутере. Как уже говорил, полгода все жужжит без проблем. Правда, пока-что трафик относительно мелкий и кол-во одновременных pptp сессий чуть более 160. Но сам видел (у того, с кем общался на эту тему) результат работы около 500 он-лайн - все путем..

Вот мои скромные текущие результаты (115 сессий он-лайн)

FreeBSD 6.3-RELEASE (SMP_MPD_PF) #0: Thu Jun 12 17:28:19 MSD 2008
last pid: 30508;  load averages:  0.25,  0.18,  0.17   up 95+01:18:10  12:35:42
158 processes: 1 running, 157 sleeping
CPU states:  1.9% user,  0.0% nice,  1.3% system,  1.1% interrupt, 95.7% idle
last pid: 30696;  load averages:  0.24,  0.19,  0.17   up 95+01:19:26  12:36:58
160 processes: 1 running, 159 sleeping
CPU states:  1.1% user,  0.0% nice,  1.7% system,  2.1% interrupt, 95.1% idle
Mem: 434M Active, 2890M Inact, 240M Wired, 186M Cache, 214M Buf, 31M Free
Swap: 8192M Total, 104K Used, 8192M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
91653 mysql     113  20    0   531M   185M kserel 1 158.0H  0.98% mysqld
84400 root        4  20    0 47592K 19600K kserel 0 164:18  0.00% mpd5
  649 root        1  96    0  3672K  1108K select 0  88:19  0.00% syslogd

netstat -bdh -w1
            input        (Total)           output
   packets  errs      bytes    packets  errs      bytes colls drops
       791     0       318K        880     0       470K     0     0
      1.4K     0       478K       1.5K     0       760K     0     0
      1.1K     0       459K       1.2K     0       784K     0     0
      1.1K     0       413K       1.2K     0       622K     0     0
      1.0K     0       393K       1.1K     0       608K     0     0
       817     0       339K        938     0       495K     0     0
       708     0       281K        811     0       390K     0     0
       787     0       282K        897     0       402K     0     0
       763     0       298K        862     0       424K     0     0
       798     0       299K        882     0       439K     0     0
      1.0K     0       359K       1.1K     0       523K     0     0
       761     0       267K        837     0       371K     0     0
       924     0       345K       1.0K     0       624K     0     0

Сейчас, конечно, вообще все скромно - спит еще народ, но и в часы пик тоже все с громадным запасом. Поэтому пока даже и не задумываюсь о каких-то апгрейдах ОС-и, или mpd. Все более чем устраивает.

 

P.S. До этого порядка трех лет держал NAS на Linux машине, шейпил скриптами на tc+iptables. Не скажу, что очень беспокоило, но проблемки были, учитывая то, что полгода назад кол-во он-лайн у меня было почти в два раза меньше. Сейчас на этой Linux машине только роутинг, NAT, фаервол и "нарезка полос" по приоритетам для различных групп пользователей.

 

 

[telefan]

пятый день работает пока NAS, нагрузка правда поболее чем здесь писали, сейчас около 360 чел онлайн.

 

last pid: 83921; load averages: 1.17, 0.66, 0.54 up 5+00:11:51 19:03:05

71 processes: 4 running, 50 sleeping, 16 waiting, 1 lock

CPU states: 2.6% user, 0.0% nice, 25.8% system, 20.5% interrupt, 51.1% idle

Mem: 15M Active, 226M Inact, 182M Wired, 332K Cache, 111M Buf, 572M Free

Swap: 1758M Total, 1758M Free

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

12 root 1 171 ki31 0K 8K RUN 0 84.1H 66.16% idle: cpu0

15 root 1 -44 - 0K 8K CPU1 0 31.5H 39.16% swi1: net

11 root 1 171 ki31 0K 8K CPU1 1 78.8H 38.92% idle: cpu1

45 root 1 -68 - 0K 8K - 0 19.5H 22.51% dummynet

32 root 1 -68 - 0K 8K - 1 663:38 11.47% em0 taskq

39 root 1 -68 - 0K 8K - 1 563:40 9.96% em1 taskq

558 root 1 121 0 20608K 10152K select 0 143:38 2.00% mpd4

23 root 1 -68 - 0K 8K *Giant 0 75:00 0.98% irq18: em1 uh

13 root 1 -32 - 0K 8K WAIT 1 66:22 0.00% swi4: clock s

 

и netstat -bdh -w1

input (Total) output

packets errs bytes packets errs bytes colls drops

21K 0 12M 22K 0 16M 0 0

20K 0 11M 21K 0 15M 0 0

21K 0 11M 21K 0 15M 0 0

22K 0 12M 22K 0 16M 0 0

21K 0 12M 22K 0 16M 0 0

периодически пишет dmesg вот такое:

ipfw: ouch!, skip past end of rules, denying packet

ipfw: ouch!, skip past end of rules, denying packet

Limiting icmp unreach response from 227 to 200 packets/sec

Limiting icmp unreach response from 232 to 200 packets/sec

 

[Giga-Byte]

два BRAS-а стоят на FreeBSD 7.0 mpd5.2, ipfw+dummynet уже 10-11 мес.

железо: Intel S3000AHV Core2Quad Q6600 EXPI9200 + EXPI9204 (всего 4-ре Intel PCI-E карты в if_lagg)

были пару раз за всё время ребуты (ichwd рулит) но ИМХО это было из-за проблем FBSD7.0 и dummynet

 

хочу перейти на ng_bpf + ng_car (но пока работает, и лопатит более чем достаточно kpps - занимаюсь другим)