nashvill Опубликовано 16 декабря, 2011 · Жалоба У кого есть опыт тюнинга двухголовых 10Г карточек (520-SR2) под фрю 8.2 ? Столкнулся с тем, что при относительно небольшом трафике зашкаливают прерывания. На машинке ipfw nat + dummynet. Трафика пока залил в нее в пиках по 800Mbps IN и OUT, получил 60-70% interrupts на каждое ядро. Дрова сетевухи 2.4.4 Фря amd64. Кручение hw.ixgbe.rxd, dev.ix.0.rx_processing_limit и т.п вообще не дает никаких отличий. Запустить polling банально не удалось - есть подозрение, что он тупо не поддерживается на 10Г карточках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tunny Опубликовано 16 декабря, 2011 · Жалоба sysctl бы показать. loader.conf, ядро дефолт? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 16 декабря, 2011 · Жалоба для начала убрать все упоминания о поллинге из ядра Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nashvill Опубликовано 16 декабря, 2011 · Жалоба loader.conf vm.kmem_size=1G net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 net.inet.tcp.tcbhashsize=4096 kern.ipc.maxsockbuf=16777216 # kernel socket buffer space kern.ipc.nmbclusters=262144 # kernel mbuf space raised 275MB of kernel dedicated ram kern.ipc.somaxconn=32768 # size of the listen queue for accepting new TCP connections kern.ipc.maxsockets=204800 # increase the limit of the open sockets kern.randompid=348 # randomized processes id's net.inet.icmp.icmplim=50 # reply to no more than 50 ICMP packets per sec net.inet.ip.process_options=0 # do not processes any TCP options in the TCP headers net.inet.ip.redirect=0 # do not allow ip header redirects net.inet.ip.rtexpire=2 # route cache expire in two seconds net.inet.ip.rtminexpire=2 # " net.inet.ip.rtmaxcache=256 # route cache entries increased net.inet.icmp.drop_redirect=1 # drop icmp redirects net.inet.tcp.blackhole=2 # drop any TCP packets to closed ports net.inet.tcp.delayed_ack=0 # no need to delay ACK's net.inet.tcp.drop_synfin=1 # drop TCP packets which have SYN and FIN set net.inet.tcp.msl=7500 # close lost tcp connections in 7.5 seconds (default 30) net.inet.tcp.nolocaltimewait=1 # do not create TIME_WAIT state for localhost net.inet.tcp.path_mtu_discovery=0 # disable MTU path discovery net.inet.tcp.recvbuf_max=16777216 # TCP receive buffer space net.inet.tcp.recvspace=8192 # decrease buffers for incoming data net.inet.tcp.sendbuf_max=16777216 # TCP send buffer space net.inet.tcp.sendspace=16384 # decrease buffers for outgoing data net.inet.udp.blackhole=1 # drop any UDP packets to closed ports hw.ixgbe.rxd=4096 hw.ixgbe.txd=4096 hw.ixgbe.rx_process_limit=4096 hw.ixgbe.max_interrupt_rate=10240 sysctl.conf net.inet.ip.fw.one_pass=0 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=32768 net.inet.ip.dummynet.pipe_slot_limit=2048 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.ipc.maxsockbuf=2097152 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=16384 net.inet.ip.dummynet.pipe_slot_limit=2048 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.inet.udp.maxdgram=57344 net.inet.tcp.sendspace=65535 net.inet.udp.recvspace=65535 net.inet.ip.intr_queue_maxlen=5000 kern.ipc.shmmax=67108864 kern.ipc.maxsockbuf=83886080 net.route.netisr_maxqlen=4096 Ядро перекомпилено с добавлением следующих опций: options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_NAT options LIBALIAS options DUMMYNET options DEVICE_POLLING options PANIC_REBOOT_WAIT_TIME=1 options HZ="1000" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 16 декабря, 2011 · Жалоба Сказали же options DEVICE_POLLING Убрать к Лешему.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nashvill Опубликовано 16 декабря, 2011 · Жалоба для начала убрать все упоминания о поллинге из ядра Без polling'а как раз и начинал. После уже от безысходности перекомпилил ядро с поллингом, однако включить поллинг не удалось (ifconfig ix0 polling) не дает никакого эффекта, по ifconfig среди опций POLLING не появляется. В догонку при старте системы выполняю еще вот что: ifconfig ix0 -rxcsum -tso -txcsum lro ifconfig ix1 -rxcsum -tso -txcsum lro Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lllsergeyv Опубликовано 16 декабря, 2011 · Жалоба для начала убрать все упоминания о поллинге из ядра Без polling'а как раз и начинал. После уже от безысходности перекомпилил ядро с поллингом, однако включить поллинг не удалось (ifconfig ix0 polling) не дает никакого эффекта, по ifconfig среди опций POLLING не появляется. В догонку при старте системы выполняю еще вот что: ifconfig ix0 -rxcsum -tso -txcsum lro ifconfig ix1 -rxcsum -tso -txcsum lro В линуксовой версии по поводу LRO написано следуюеще: IMPORTANT NOTE ============== WARNING: The ixgbe driver compiles by default with the LRO (Large Receive Offload) feature enabled. This option offers the lowest CPU utilization for receives, but is completely incompatible with *routing/ip forwarding* and *bridging*. If enabling ip forwarding or bridging is a requirement, it is necessary to disable LRO using compile time options as noted in the LRO section later in this document. The result of not disabling LRO when combined with ip forwarding or bridging can be low throughput or even a kernel panic. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 16 декабря, 2011 · Жалоба net.inet.tcp.* net.inet.udp.* Вообще к роутингу отношения не имеют, и полностью тюнятся из сисцтл, в лоадере тюнится только то, что не тюнится из сисцтл. kern.ipc.* вроде только из лоадера, и то возможно не всё. Узнать просто - устанавливаем через сисцтл во время работы, если применилось значит это в сисцтл.конф пишем, если выругалось - то в лоадер и ребутаемся чтобы применилось. Ещё, проверьте, всё что вы в лоадере прописали на самом деле применилось или вам только кажется. Насчёт поллинга - не факт что его из драйверов не выкинули как депрекейтед. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 17 декабря, 2011 · Жалоба В любом случае, нагрузку дают не сами аппаратные прерывания, а обработка пакетов фаерволом/шейпером и NAT. Я бы вместо бесполезного тюнинга сетевого стека тюнинговал как раз 'ipfw nat + dummynet'. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nashvill Опубликовано 18 декабря, 2011 · Жалоба Перекомпилил ядро без POLLING, проверил что по факту тюнится и не тюнится указанное в loader.conf и sysctl.conf - все нормально. Без вкомпиленного polling ситуация не изменилась, вот что имеем: 10gx2# netstat -I ix0 1 input (ix0) output packets errs idrops bytes packets errs bytes colls 39161 0 0 34748048 31454 0 24910825 0 38159 0 0 31683360 33062 0 27845440 0 last pid: 21019; load averages: 0.00, 0.04, 0.06 up 0+00:14:55 14:01:07 104 processes: 5 running, 68 sleeping, 31 waiting CPU 0: 0.0% user, 0.0% nice, 1.1% system, 23.3% interrupt, 75.6% idle CPU 1: 0.0% user, 0.0% nice, 0.4% system, 27.8% interrupt, 71.8% idle CPU 2: 0.0% user, 0.0% nice, 0.4% system, 26.3% interrupt, 73.3% idle CPU 3: 0.0% user, 0.0% nice, 0.8% system, 25.9% interrupt, 73.3% idle Mem: 16M Active, 12M Inact, 234M Wired, 292K Cache, 11M Buf, 3552M Free Swap: 10G Total, 10G Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 171 ki31 0K 64K RUN 0 11:20 79.79% {idle: cpu0} 11 root 171 ki31 0K 64K CPU1 1 12:18 78.47% {idle: cpu1} 11 root 171 ki31 0K 64K RUN 2 12:18 77.98% {idle: cpu2} 11 root 171 ki31 0K 64K CPU3 3 12:27 73.78% {idle: cpu3} 12 root -68 - 0K 496K WAIT 1 1:22 15.77% {irq262: ix1:que } 12 root -68 - 0K 496K WAIT 3 1:17 15.19% {irq264: ix1:que } 12 root -68 - 0K 496K WAIT 2 1:16 15.09% {irq263: ix1:que } 12 root -68 - 0K 496K WAIT 0 1:15 12.89% {irq261: ix1:que } 12 root -68 - 0K 496K WAIT 1 1:07 12.35% {irq257: ix0:que } 12 root -68 - 0K 496K WAIT 0 1:04 11.18% {irq256: ix0:que } 12 root -68 - 0K 496K WAIT 2 1:02 10.35% {irq258: ix0:que } 12 root -68 - 0K 496K WAIT 3 1:03 9.47% {irq259: ix0:que } 10gx2# ipfw show 00005 804 60731 allow ip from any to me 00005 1212 256223 allow ip from me to any 00010 225 15474 deny ip from any to any dst-port 135,137,139,445 in recv ix0 00015 0 0 skipto 20 ip from table(4) to any dst-port 25 out xmit ix1 00016 268 15776 deny ip from any to any dst-port 25 out xmit ix1 00050 103722 23160900 skipto 150 ip from table(1) to table(3) in recv ix0 00100 22127152 16616245814 pipe tablearg ip from table(1) to any in recv ix0 00120 30 1200 skipto 150 ip from any to table(5) in recv ix0 00130 1336 86530 fwd 127.0.0.1,49850 ip from not table(1) to any dst-port 80 in recv ix0 00140 3609 236281 deny ip from not table(1) to any in recv ix0 00200 22225977 16632525619 nat tablearg ip from table(20) to any out xmit ix1 00201 22228364 16633902478 allow ip from any to any out xmit ix1 00300 19723527 15485774039 nat tablearg ip from any to table(21) in recv ix1 00350 110672 84866702 skipto 1000 ip from table(3) to table(1) out xmit ix0 00401 19150332 15367589943 pipe tablearg ip from any to table(2) out xmit ix0 65535 60720126 47454877202 allow ip from any to any Подправлены исходники, чтобы можно было сделать более 16 instances ната (сейчас их сделано 255), реально правда используется около 50. Натится путем нарезки /15 серых IP кусками по /26 и назначением по /26 на отдельный IP из пула НАТа (пул ната /24). Собственно сделано по кругу (т.е. a.b.c.0/26 -> .1, a.b.c.64/26 -> .2 после дохода до .255 опять переходим к .1) сделано было с той целью чтобы максимально равномерно распределить серые ипы по пабликам. Какие есть мысли - что тут можно потюнить чтобы не получать по 25% прерываний при трафике в 20-25Мбайт/с ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 18 декабря, 2011 · Жалоба Я не уверен в необходимости выставления hw.ixgbe.max_interrupt_rate=10240. Чем не понравился дефолтный Dynamic? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nashvill Опубликовано 19 декабря, 2011 · Жалоба Я не уверен в необходимости выставления hw.ixgbe.max_interrupt_rate=10240. Чем не понравился дефолтный Dynamic? Это один из экспериментов - изменение этого параметра опять же не дает никакого эффекта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t00r Опубликовано 19 декабря, 2011 (изменено) · Жалоба Я не уверен в необходимости выставления hw.ixgbe.max_interrupt_rate=10240. Чем не понравился дефолтный Dynamic? нет смысла. стардартные параметры от яндекса великолепно лопатят до 920 мегабит. http://forum.nag.ru/forum/index.php?showtopic=71822&view=findpost&p=666608 Изменено 19 декабря, 2011 пользователем t00r Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nashvill Опубликовано 19 декабря, 2011 · Жалоба Я не уверен в необходимости выставления hw.ixgbe.max_interrupt_rate=10240. Чем не понравился дефолтный Dynamic? нет смысла. стардартные параметры от яндекса великолепно лопатят до 920 мегабит. http://forum.nag.ru/forum/index.php?showtopic=71822&view=findpost&p=666608 Отличие вашей истории от моей в том, что у вас гигабитные сетевухи, а у меня 10Г. На гигабитных я отлично в полку прогружаю натом с шейпингом гиг, а вот с этими карточками сплошная беда. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 19 декабря, 2011 · Жалоба Покажите sysctl dev.ixgbe.0 | grep -v ": 0" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nashvill Опубликовано 29 декабря, 2011 · Жалоба Покажите sysctl dev.ixgbe.0 | grep -v ": 0" Оно не ixgbe, а просто ix значится в dev. Сейчас откатился на 2.3.8 - ничего опять же не изменилось, что 2.4.4 что эти - результат идентичный - прерывания зашкаливают. Сейчас даже отказался от ipfw nat в пользу PFNAT, результат опять же такой же. При трафике в 40Мбайт/с в каждую сторону я имею по 33-35% загрузку прерываниями каждого из ядер. === 10gx2# sysctl dev.ix.0 | grep -v ": 0" dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.3.8 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PEG1.S6F0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0003 class=0x020000 dev.ix.0.%parent: pci2 dev.ix.0.flow_control: 0 dev.ix.0.enable_aim: 1 dev.ix.0.rx_processing_limit: 4096 dev.ix.0.link_irq: 2 dev.ix.0.queue0.interrupt_rate: 1000000 dev.ix.0.queue0.txd_head: 854 dev.ix.0.queue0.txd_tail: 856 dev.ix.0.queue0.tx_packets: 6660945 dev.ix.0.queue0.rxd_head: 3754 dev.ix.0.queue0.rxd_tail: 3753 dev.ix.0.queue0.rx_packets: 6471341 dev.ix.0.queue0.rx_bytes: 3128748031 dev.ix.0.queue1.interrupt_rate: 10638 dev.ix.0.queue1.txd_head: 1736 dev.ix.0.queue1.txd_tail: 1736 dev.ix.0.queue1.tx_packets: 6995827 dev.ix.0.queue1.rxd_head: 1119 dev.ix.0.queue1.rxd_tail: 1118 dev.ix.0.queue1.rx_packets: 6718559 dev.ix.0.queue1.rx_bytes: 3938881610 dev.ix.0.queue2.interrupt_rate: 10638 dev.ix.0.queue2.txd_head: 2871 dev.ix.0.queue2.txd_tail: 2871 dev.ix.0.queue2.tx_packets: 6775157 dev.ix.0.queue2.rxd_head: 275 dev.ix.0.queue2.rxd_tail: 272 dev.ix.0.queue2.rx_packets: 6119703 dev.ix.0.queue2.rx_bytes: 3500565337 dev.ix.0.queue3.interrupt_rate: 1000000 dev.ix.0.queue3.txd_head: 1501 dev.ix.0.queue3.txd_tail: 1501 dev.ix.0.queue3.tx_packets: 6362589 dev.ix.0.queue3.rxd_head: 3893 dev.ix.0.queue3.rxd_tail: 3891 dev.ix.0.queue3.rx_packets: 6844212 dev.ix.0.queue3.rx_bytes: 4386162945 dev.ix.0.mac_stats.local_faults: 6 dev.ix.0.mac_stats.remote_faults: 1 dev.ix.0.mac_stats.total_octets_rcvd: 15057984332 dev.ix.0.mac_stats.good_octets_rcvd: 15057984332 dev.ix.0.mac_stats.total_pkts_rcvd: 26152161 dev.ix.0.mac_stats.good_pkts_rcvd: 26152160 dev.ix.0.mac_stats.bcast_pkts_rcvd: 14 dev.ix.0.mac_stats.rx_frames_64: 7772428 dev.ix.0.mac_stats.rx_frames_65_127: 6873175 dev.ix.0.mac_stats.rx_frames_128_255: 1307100 dev.ix.0.mac_stats.rx_frames_256_511: 357380 dev.ix.0.mac_stats.rx_frames_512_1023: 864763 dev.ix.0.mac_stats.rx_frames_1024_1522: 8977315 dev.ix.0.mac_stats.checksum_errs: 2102613 dev.ix.0.mac_stats.good_octets_txd: 26087412809 dev.ix.0.mac_stats.total_pkts_txd: 26792651 dev.ix.0.mac_stats.good_pkts_txd: 26792651 dev.ix.0.mac_stats.bcast_pkts_txd: 1 dev.ix.0.mac_stats.tx_frames_64: 2599916 dev.ix.0.mac_stats.tx_frames_65_127: 5841901 dev.ix.0.mac_stats.tx_frames_128_255: 819713 dev.ix.0.mac_stats.tx_frames_256_511: 616563 dev.ix.0.mac_stats.tx_frames_512_1023: 375796 dev.ix.0.mac_stats.tx_frames_1024_1522: 16538762 === Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 11 января, 2012 · Жалоба .checksum_errs: 2102613 Это 8% от общего числа принятых пакетов, много. Без NAT'a та же ситуация? Больше не знаю, что подсказать - у меня на стенде Xeon E3-1270 с Intel 82599 влёгкую генерировал 1.6 Mpps (через сервер, увы, не пропускал из-за отсутствия возможности). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 11 января, 2012 · Жалоба Попробуйте в несколько потоков. У меня на 82598 7.5-8 выжимал между серверами iperf ом в несколько потоков. В один похоже проц не может столько сгенерировать... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 11 января, 2012 · Жалоба Я генерировал через ng_source. Iperf тоже гонял, вот только результатов не помню :) А десятки уже ушли в сервера виртуализации, так что не потестить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nashvill Опубликовано 11 января, 2012 · Жалоба .checksum_errs: 2102613 Это 8% от общего числа принятых пакетов, много. Без NAT'a та же ситуация? с натом, без ната, с dummynet, без dummynet - CRC ошибки все равно есть, точнее просто счетчик есть, так как пакетлоса нет вообще. Проверил уже с двумя сетевухами на базе 82599 - с двухголовой и одноголовой (в обоих случаях они с SFP+ SR). checksum_errs тикает в обоих случаях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...