Перейти к содержимому
Калькуляторы

Freebsd 8 stable(cvs) + igb

Кто использует igb двух/четырех портовые - поделитесь впечатлениями/опытом - как они работают в freebsd 8 stable(cvs)? и стоит ли драйвер от яндекса ставить на них? и какой тюнинг для них полезен если использовать сервер в качестве pppoe-сервера +ng_car ?

 

И еще - вопросик знатокам:

 

есть сервер pppoe - на нем примерно 400-600 клиентов все работает, но иногда - происходит такое:

 

netstat -I em0 -h -w 1

29K 0 0 19M 28K 0 18M 0

30K 0 0 20M 29K 0 19M 0

32K 0 0 20M 30K 0 19M 0

31K 0 0 20M 29K 0 19M 0

29K 0 0 16M 28K 0 16M 0

33K 0 0 18M 28K 0 16M 0

17K 1.9K 0 9.2M 17K 0 9.4M 0

9.1K 4.8K 0 3.3M 8.7K 0 3.3M 0

7.1K 3.5K 0 1.9M 6.7K 0 1.8M 0

5.8K 3.2K 0 1.6M 5.4K 0 1.5M 0

6.1K 2.7K 0 1.4M 5.7K 0 1.4M 0

5.4K 2.8K 0 1.1M 5.0K 0 1.0M 0

4.8K 2.6K 0 977K 4.3K 0 931K 0

4.4K 2.7K 0 823K 4.0K 0 783K 0

при этом:

 

last pid: 77605; load averages: 5.79, 2.83, 2.27 up 5+00:21:16 20:40:07

785 processes: 7 running, 755 sleeping, 23 waiting

CPU 0: 0.8% user, 0.0% nice, 9.2% system, 3.1% interrupt, 87.0% idle

CPU 1: 3.8% user, 0.0% nice, 7.7% system, 0.8% interrupt, 87.7% idle

CPU 2: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle

CPU 3: 1.5% user, 0.0% nice, 6.9% system, 10.7% interrupt, 80.9% idle

Mem: 170M Active, 470M Inact, 263M Wired, 100K Cache, 111M Buf, 89M Free

Swap: 1515M Total, 1515M Free

 

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND

0 root -68 0 0K 64K CPU2 2 58.3H 100.00% {em0 taskq}

11 root 171 ki31 0K 32K CPU1 1 114.2H 89.16% {idle: cpu1}

11 root 171 ki31 0K 32K RUN 0 115.5H 85.35% {idle: cpu0}

11 root 171 ki31 0K 32K CPU3 3 116.9H 81.93% {idle: cpu3}

12 root -32 - 0K 184K WAIT 3 462:56 5.66% {swi4: clock}

12 root -32 - 0K 184K WAIT 0 0:39 5.13% {swi4: clock}

12 root -32 - 0K 184K WAIT 1 0:52 0.34% {swi4: clock}

11 root 171 ki31 0K 32K RUN 2 62.1H 0.00% {idle: cpu2}

3731 root 44 0 300M 196M flowcl 1 104:49 0.00% {mpd5}

...

подскажите в каком направлении копать?

Изменено пользователем gorec2005

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

поп поводу тюнинга, у нас пока так. Пока хаватает.

 

net.graph.recvspace=256000
net.graph.maxdgram=256000
kern.ipc.maxsockbuf=1024000

 

мне кажется у вас mpd многовато памяти жрет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3731 root 44 0 300M 196M flowcl 1 104:49 0.00% {mpd5}

из ядра FLOWTABLE нах!

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8.0 уже не актуально. В 8.1 работает без проблем, драйвер от Яндекса для igb не нужен. Но желательно все же обработчики прерываний igb и ее процессы пригвоздить к ядрам жестко.

 

netstat -I em0 -h -w 1
А где igb то ? em это простая однопоточная плата.

 

По идее, netgraph сам раскидывает нагрузку по ядрам (начиная с 7.2 он создает процессы по кол-ву ядер).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

мне кажется у вас mpd многовато памяти жрет.
вероятно это из-за:

785 processes: 7 running, 755 sleeping, 23 waiting

т.е. при съеме top -SHP я захватил момент когда mpd породил много тридов аккаунтинга...

а может это из-за того что долго работал и какие-то течки скопились... случайно тут набрел на

https://sourceforge.net/projects/mpd/forums...2/topic/3767313 посмотрел у себя - и правда -

NetGraph items: 36, 4130, 18, 3758, 4143291927, 476

NetGraph data items: 36, 1062, 0, 413, 24100697376, 915

теперь добавил в loader.conf

net.graph.maxdata="1024"

net.graph.maxalloc="16384"

 

из ядра FLOWTABLE нах!
а какой в этом смысл? ( одно время flowtable процесс действительно создавал сложности, но на текущем CVS-STABLE он почти ничего не расходует )

 

уже после прочтения своего сообщения - подумалось, что основная трабла зарыта в

0 root -68 0 0K 64K CPU2 2 58.3H 100.00% {em0 taskq}
но что с этим делать - пока ума не приложу...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А что за железо? У нас с такими потоками справляется E8500, так еще и работает на 20 процентов. Был баг с netgraph c pptp, то же жрало один процессор, но это еще на 7.2.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 8.1 работает без проблем
это радует!
желательно все же обработчики прерываний igb и ее процессы пригвоздить к ядрам жестко
а каким образом это делается? sysctl ? - можно пример?
А где igb то ? em это простая однопоточная плата.
да! Вы абсолютно правы - просто возникла проблема - подумал о наиболее вероятном пути ее решения - написал, а потом решил и про проблему написать :-) - вдруг есть другие решения...

 

 

А что за железо?
CPU: Intel® Core2 Quad CPU Q9400 @ 2.66GHz (2666.38-MHz 686-class CPU)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на em0 подымаете vlan? каково количество?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на em0 подымаете vlan?
да
каково количество?
на тек момент 43

 

сет. карта pci-e 1x 82574l

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

желательно все же обработчики прерываний igb и ее процессы пригвоздить к ядрам жестко
а каким образом это делается? sysctl ? - можно пример?

Поправить /sys/dev/e1000/if_(em|igb).c . Более никак. Там не сильно сложно :) Или искать как узнать td_tid, и через cpuset -l.. -t.. прибивать.

 

сет. карта pci-e 1x 82574l
Поставьте пару: карточки дешевые. Или igb.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4 igb на 8.1 при большом трафике давали ватчдоги, не победил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4 igb на 8.1 при большом трафике давали ватчдоги

какой в Вашем понимании трафик большой? и , самое главное сколько pps?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

FreeBSD 8.1. SR1600UR igb 2-х портовая на борту. Один внутрь, второй наружу, сервер все в одном через pptp (mpd5). Трафик более 300 мбит с и-нета, kpps до 50 в одну сторону на одно интерфейсе. Итого в понятиях циски 300 kpps и 600 мбит. Полет прекрасный...

Изменено пользователем Hawk128

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

gorec2005 1,8-19Gbit/s, pps порядка 1,2-1,3Mpps. Попробовал ставить 6 карт,в режиме бриджа все это, трафик был 2,4-2,7Ж и 1,7Mpps. Сейчас откатился на 7.3

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сейчас откатился на 7.3

а почему? - 8.1 - не стабильна или работает хуже 7.3 ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

gorec2005

на 8.1 были постоянные watchdog, на 7.3 их нету.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на 8.1 были постоянные watchdog

На каких нагрузках?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

поставил igb (intel et dual ports)

вот результат:

 

last pid: 43769;  load averages:  0.08,  0.05,  0.01                                                                                                                                                                   up 0+19:05:49  10:04:34
152 processes: 5 running, 117 sleeping, 30 waiting
CPU 0:     % user,     % nice,     % system,     % interrupt,     % idle
CPU 1:     % user,     % nice,     % system,     % interrupt,     % idle
CPU 2:     % user,     % nice,     % system,     % interrupt,     % idle
CPU 3:     % user,     % nice,     % system,     % interrupt,     % idle
Mem: 83M Active, 275M Inact, 232M Wired, 184K Cache, 111M Buf, 402M Free
Swap: 1170M Total, 1170M Free

  PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root       171 ki31     0K    32K CPU1    1  17.9H 100.00% {idle: cpu1}
   11 root       171 ki31     0K    32K CPU2    2  17.9H 98.97% {idle: cpu2}
   11 root       171 ki31     0K    32K RUN     0 982:11 95.36% {idle: cpu0}
   11 root       171 ki31     0K    32K CPU3    3  18.0H 73.00% {idle: cpu3}
   12 root       -32    -     0K   240K WAIT    1  28:51 30.08% {swi4: clock}
   12 root       -68    -     0K   240K WAIT    0 103:04  6.05% {irq256: igb0:que}
   12 root       -68    -     0K   240K WAIT    0  47:14  2.29% {irq261: igb1:que}
   12 root       -68    -     0K   240K WAIT    3  46:11  1.66% {irq264: igb1:que}
   12 root       -68    -     0K   240K WAIT    1  44:18  1.56% {irq262: igb1:que}
   12 root       -68    -     0K   240K WAIT    2  46:03  1.17% {irq263: igb1:que}
5409 root        44    0 57244K 39136K select  3  10:05  0.00% {mpd5}
    0 root       -68    0     0K   120K -       2   9:07  0.00% {igb0 que}
    0 root       -68    0     0K   120K -       1   3:23  0.00% {igb1 que}
   13 root        44    -     0K     8K -       1   1:49  0.00% yarrow
4051 bind        44    0 77216K 64720K ucond   0   1:38  0.00% {named}
4051 bind        44    0 77216K 64720K ucond   1   1:38  0.00% {named}
4051 bind        44    0 77216K 64720K ucond   3   1:38  0.00% {named}
4051 bind        44    0 77216K 64720K ucond   3   1:38  0.00% {named}
3943 root        44    0  3352K  1312K select  2   1:07  0.00% syslogd
4051 bind        44    0 77216K 64720K kqread  1   1:06  0.00% {named}
    0 root       -16    0     0K   120K sched   0   0:34  0.00% {swapper}
   17 root        44    -     0K     8K syncer  0   0:25  0.00% syncer
4270 freeradius  44    0 28728K 10512K select  2   0:25  0.00% {radiusd}
    0 root       -68    0     0K   120K -       0   0:23  0.00% {ale0 taskq}
   12 root       -68    -     0K   240K WAIT    3   0:16  0.00% {irq259: igb0:que}
4051 bind        44    0 77216K 64720K ucond   1   0:14  0.00% {named}
   12 root       -68    -     0K   240K WAIT    2   0:14  0.00% {irq258: igb0:que}
5410 root        44    -     0K    32K sleep   1   0:14  0.00% {ng_queue3}
5410 root        44    -     0K    32K sleep   2   0:14  0.00% {ng_queue2}
5410 root        44    -     0K    32K sleep   2   0:14  0.00% {ng_queue0}
5410 root        44    -     0K    32K sleep   1   0:14  0.00% {ng_queue1}
4271 root        76    0  3632K  1396K wait    1   0:10  0.00% sh
   12 root       -68    -     0K   240K WAIT    1   0:10  0.00% {irq257: igb0:que}
4453 root        44    0  5884K  4176K select  2   0:08  0.00% bsnmpd
3115 root        44    0  5172K  3052K select  2   0:08  0.00% ospfd
   12 root       -44    -     0K   240K WAIT    2   0:07  0.00% {swi1: netisr 0}
   12 root       -32    -     0K   240K WAIT    1   0:04  0.00% {swi4: clock}
3109 root        44    0  5036K  2588K select  1   0:03  0.00% zebra
   12 root       -32    -     0K   240K WAIT    2   0:03  0.00% {swi4: clock}
   12 root       -32    -     0K   240K WAIT    1   0:02  0.00% {swi4: clock}
    0 root       -68    0     0K   120K -       2   0:02  0.00% {igb0 que}
    2 root        -8    -     0K     8K -       1   0:02  0.00% g_event
    0 root       -68    0     0K   120K -       3   0:02  0.00% {igb0 que}
4270 freeradius  44    0 28728K 10512K uwait   3   0:02  0.00% {radiusd}
4270 freeradius  44    0 28728K 10512K uwait   3   0:02  0.00% {radiusd}

результат пока непонятен - под нормальной нагрузкой пока не посмотрел... но уже появился вопрос - что такое "swi4: clock" - почему у него такая загрузка?

Изменено пользователем gorec2005

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на 8.1 были постоянные watchdog
На каких нагрузках?

IGB Нормально не работает

у меня в кору вывалилась система где то на 900 суммарных мегабитах

500+400

 

сколько pps не смотрел

вообщем рано

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

поставил igb (intel et dual ports)

вот результат:

результат пока непонятен - под нормальной нагрузкой пока не посмотрел... но уже появился вопрос - что такое "swi4: clock" - почему у него такая загрузка?

#cat /etc/rc.local

THREADS=`procstat -at | grep clock | awk '{ print $2 }'`
for THREAD in ${THREADS}
do
        /usr/bin/cpuset -t ${THREAD} -l 0
done

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

поставил igb (intel et dual ports)

вот результат:

результат пока непонятен - под нормальной нагрузкой пока не посмотрел... но уже появился вопрос - что такое "swi4: clock" - почему у него такая загрузка?

#cat /etc/rc.local

THREADS=`procstat -at | grep clock | awk '{ print $2 }'`
for THREAD in ${THREADS}
do
        /usr/bin/cpuset -t ${THREAD} -l 0
done

я так понимаю - это чтобы прибить обработку прерываний по ядрам? - а почему тогда "-l 0" ? - все переползло на 0-е ядро...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

и еще - наблюдаю не совсем понятную картину - может кто объяснит?

12 root       -68    -     0K   240K WAIT    0 344:38 11.67% {irq256: igb0:que}
   12 root       -68    -     0K   240K WAIT    1 175:58  7.28% {irq262: igb1:que}
   12 root       -68    -     0K   240K WAIT    0 173:19  6.30% {irq261: igb1:que}
   12 root       -68    -     0K   240K WAIT    2 182:46  5.76% {irq263: igb1:que}
   12 root       -68    -     0K   240K WAIT    3 181:42  5.66% {irq264: igb1:que}
   12 root       -68    -     0K   240K WAIT    2   0:48  0.00% {irq258: igb0:que}
   12 root       -68    -     0K   240K WAIT    3   0:45  0.00% {irq259: igb0:que}
   12 root       -68    -     0K   240K WAIT    1   0:39  0.00% {irq257: igb0:que}

 

почему igb1 нормально на ядра раскладывается, а igb0 - нет! ?

при этом на igb1 основная нагрузка на один влан а в igb0 несколько.

Изменено пользователем gorec2005

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

поставил igb (intel et dual ports)

вот результат:

результат пока непонятен - под нормальной нагрузкой пока не посмотрел... но уже появился вопрос - что такое "swi4: clock" - почему у него такая загрузка?

#cat /etc/rc.local

THREADS=`procstat -at | grep clock | awk '{ print $2 }'`
for THREAD in ${THREADS}
do
        /usr/bin/cpuset -t ${THREAD} -l 0
done

я так понимаю - это чтобы прибить обработку прерываний по ядрам? - а почему тогда "-l 0" ? - все переползло на 0-е ядро...

Если присмотреться - это потоки обрабатывающие событие таймера, не прерывания. Их создается системой при старте по количеству ядер, каждый поток прибивается к своему ядру, но, насколько я понял, прерывания от таймера в любом случае попадают на ядро 0 и уже потом активируется поток на нужном ядре. У меня основной потребитель таймера dummynet, который тоже прибит к ядру 0, вот и прикинул - зачем метаться по ядрам херя при этом кеш, когда можно крутится на одном ядре, помогло.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

из ядра FLOWTABLE нах!
а какой в этом смысл? ( одно время flowtable процесс действительно создавал сложности, но на текущем CVS-STABLE он почти ничего не расходует )

Уверены, что сейчас с этим все тип-топ? Причем конкретно в связке с mpd.

Несколько дней назад помогал коллегам победить регулярное падение NAS-ов (4 штуки) с FreeBSD 8.1-STABLE-201011. Машинки вставали в полный ступор без кернел паник, ни на что не реагируя и без предсмертных записей в логах. Трафик и ппс-ы перед падением были невысокие (не более 100М/20к) и каждый раз по-разному.

Пересобрали ядра, отключив flowtable и.. Пятый день полёт нормальный.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.