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

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}

...

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

Edited by gorec2005

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites
3731 root 44 0 300M 196M flowcl 1 104:49 0.00% {mpd5}

из ядра FLOWTABLE нах!

 

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites
мне кажется у вас 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}
но что с этим делать - пока ума не приложу...

Share this post


Link to post
Share on other sites

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

Share this post


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

 

 

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

Share this post


Link to post
Share on other sites
на 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>

 

 

Share this post


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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Edited by Hawk128

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

gorec2005

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

Share this post


Link to post
Share on other sites

поставил 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" - почему у него такая загрузка?

Edited by gorec2005

Share this post


Link to post
Share on other sites
на 8.1 были постоянные watchdog
На каких нагрузках?

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

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

500+400

 

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

вообщем рано

Share this post


Link to post
Share on other sites
поставил 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

Share this post


Link to post
Share on other sites
поставил 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-е ядро...

Share this post


Link to post
Share on other sites

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

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 несколько.

Edited by gorec2005

Share this post


Link to post
Share on other sites
поставил 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, вот и прикинул - зачем метаться по ядрам херя при этом кеш, когда можно крутится на одном ядре, помогло.

Share this post


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

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

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

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

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