gorec2005 Опубликовано 31 октября, 2010 (изменено) · Жалоба Кто использует 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:07785 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} ... подскажите в каком направлении копать? Изменено 31 октября, 2010 пользователем gorec2005 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chubais Опубликовано 31 октября, 2010 · Жалоба поп поводу тюнинга, у нас пока так. Пока хаватает. net.graph.recvspace=256000 net.graph.maxdgram=256000 kern.ipc.maxsockbuf=1024000 мне кажется у вас mpd многовато памяти жрет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Zohan Опубликовано 31 октября, 2010 · Жалоба 3731 root 44 0 300M 196M flowcl 1 104:49 0.00% {mpd5} из ядра FLOWTABLE нах! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bitbucket Опубликовано 31 октября, 2010 · Жалоба 8.0 уже не актуально. В 8.1 работает без проблем, драйвер от Яндекса для igb не нужен. Но желательно все же обработчики прерываний igb и ее процессы пригвоздить к ядрам жестко. netstat -I em0 -h -w 1А где igb то ? em это простая однопоточная плата. По идее, netgraph сам раскидывает нагрузку по ядрам (начиная с 7.2 он создает процессы по кол-ву ядер). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 31 октября, 2010 · Жалоба мне кажется у вас 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}но что с этим делать - пока ума не приложу... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chubais Опубликовано 31 октября, 2010 · Жалоба А что за железо? У нас с такими потоками справляется E8500, так еще и работает на 20 процентов. Был баг с netgraph c pptp, то же жрало один процессор, но это еще на 7.2. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 31 октября, 2010 · Жалоба В 8.1 работает без проблемэто радует!желательно все же обработчики прерываний igb и ее процессы пригвоздить к ядрам жесткоа каким образом это делается? sysctl ? - можно пример?А где igb то ? em это простая однопоточная плата.да! Вы абсолютно правы - просто возникла проблема - подумал о наиболее вероятном пути ее решения - написал, а потом решил и про проблему написать :-) - вдруг есть другие решения... А что за железо?CPU: Intel® Core2 Quad CPU Q9400 @ 2.66GHz (2666.38-MHz 686-class CPU) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chubais Опубликовано 31 октября, 2010 · Жалоба на em0 подымаете vlan? каково количество? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 31 октября, 2010 · Жалоба на 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> Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bitbucket Опубликовано 31 октября, 2010 · Жалоба желательно все же обработчики прерываний igb и ее процессы пригвоздить к ядрам жесткоа каким образом это делается? sysctl ? - можно пример? Поправить /sys/dev/e1000/if_(em|igb).c . Более никак. Там не сильно сложно :) Или искать как узнать td_tid, и через cpuset -l.. -t.. прибивать. сет. карта pci-e 1x 82574lПоставьте пару: карточки дешевые. Или igb. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Slad Опубликовано 1 ноября, 2010 · Жалоба 4 igb на 8.1 при большом трафике давали ватчдоги, не победил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 1 ноября, 2010 · Жалоба 4 igb на 8.1 при большом трафике давали ватчдоги какой в Вашем понимании трафик большой? и , самое главное сколько pps? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 1 ноября, 2010 (изменено) · Жалоба FreeBSD 8.1. SR1600UR igb 2-х портовая на борту. Один внутрь, второй наружу, сервер все в одном через pptp (mpd5). Трафик более 300 мбит с и-нета, kpps до 50 в одну сторону на одно интерфейсе. Итого в понятиях циски 300 kpps и 600 мбит. Полет прекрасный... Изменено 1 ноября, 2010 пользователем Hawk128 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Slad Опубликовано 2 ноября, 2010 · Жалоба gorec2005 1,8-19Gbit/s, pps порядка 1,2-1,3Mpps. Попробовал ставить 6 карт,в режиме бриджа все это, трафик был 2,4-2,7Ж и 1,7Mpps. Сейчас откатился на 7.3 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 4 ноября, 2010 · Жалоба Сейчас откатился на 7.3 а почему? - 8.1 - не стабильна или работает хуже 7.3 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Slad Опубликовано 6 ноября, 2010 · Жалоба gorec2005 на 8.1 были постоянные watchdog, на 7.3 их нету. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 7 ноября, 2010 · Жалоба на 8.1 были постоянные watchdog На каких нагрузках? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Slad Опубликовано 8 ноября, 2010 · Жалоба 1,8-19Gbit/s, pps порядка 1,2-1,3Mpps Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 12 ноября, 2010 (изменено) · Жалоба поставил 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" - почему у него такая загрузка? Изменено 12 ноября, 2010 пользователем gorec2005 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AntonS Опубликовано 12 ноября, 2010 · Жалоба на 8.1 были постоянные watchdogНа каких нагрузках? IGB Нормально не работает у меня в кору вывалилась система где то на 900 суммарных мегабитах 500+400 сколько pps не смотрел вообщем рано Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 12 ноября, 2010 · Жалоба поставил 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 15 декабря, 2010 · Жалоба поставил 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-е ядро... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gorec2005 Опубликовано 15 декабря, 2010 (изменено) · Жалоба и еще - наблюдаю не совсем понятную картину - может кто объяснит? 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 несколько. Изменено 15 декабря, 2010 пользователем gorec2005 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 15 декабря, 2010 · Жалоба поставил 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, вот и прикинул - зачем метаться по ядрам херя при этом кеш, когда можно крутится на одном ядре, помогло. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 15 декабря, 2010 · Жалоба из ядра FLOWTABLE нах!а какой в этом смысл? ( одно время flowtable процесс действительно создавал сложности, но на текущем CVS-STABLE он почти ничего не расходует ) Уверены, что сейчас с этим все тип-топ? Причем конкретно в связке с mpd.Несколько дней назад помогал коллегам победить регулярное падение NAS-ов (4 штуки) с FreeBSD 8.1-STABLE-201011. Машинки вставали в полный ступор без кернел паник, ни на что не реагируя и без предсмертных записей в логах. Трафик и ппс-ы перед падением были невысокие (не более 100М/20к) и каждый раз по-разному. Пересобрали ядра, отключив flowtable и.. Пятый день полёт нормальный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...