Max P Опубликовано 1 ноября, 2011 · Жалоба Rate: 787817060 bits/sec, 121045 packets/sec; Avg 1 min: 798614394 bps, 122878 pps; 5 min: 802165019 bps, 123166 pps почти максимум того, что мы обычно выбираем, нагрузка по ядрам 20-25%, раньше уже в районе 45-50 болталось, всем спасибо за помощь :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 1 ноября, 2011 · Жалоба ну вот, удалось теперь +100мбит сверху выжать, нагрузка те же 22-25% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 1 ноября, 2011 · Жалоба кстати его дофига да, у нас очень любят торренты Резать значит. Бордюру еще больше полегчает, в коннтраке кол-во "сессий" от него поубавится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 2 ноября, 2011 · Жалоба Только не догадайтесь резать на бордюре. Вообще выносите фаеры оттуда на брасы. Шейперы желательно тоже. Если все настроите правильно, то вы загрузите двухпортовую 82576 полностью и еще на такую же останется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 2 ноября, 2011 · Жалоба Резать.... попробовать бы порезать на телесине 9924SP, оно вроде тоже умеет по содержимому пакета резать. NiTr0 а у вас есть актуальные правила для зарезки utp? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 2 ноября, 2011 · Жалоба да кстати, это я не бордер тюнил) а типа браса - нат+шейпер железка, бордер у меня отдельный Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 2 ноября, 2011 · Жалоба Только не догадайтесь резать на бордюре. Вообще выносите фаеры оттуда на брасы. Ничего страшного бордюру не будет, если там не тысячи правил в цепочке. NiTr0 а у вас есть актуальные правила для зарезки utp? В топике, посвященном ютп, отписал. 3 штуки их. Режется вроде все. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 3 ноября, 2011 (изменено) · Жалоба 2 NiTr0: Немного оффтопика. Я за чистоту бордюров, то есть чем меньше правил, тем лучше. В идеале вообще нет. Чтобы не было ситуаций, когда одно из правил начинает выносить машину, и чтобы это выяснить надо тратить время и терпение клиентов. Ведь всё можно резать на брасах и им уж точно плохо не будет, т.к. их, если что, можно отключать не нарушая сервис. Поэтому, когда я вижу рекомендации "та нормально", я немного негодую. Понятно, что 2-10 правил на бордере погоды не сделают, но зачем плодить бардак? Можешь зарезать на брасе - реж там. На бордере всегда удобнее резать, т.к. их один-два, а брасов может быть много и везде надо реплицировать. Только это, мне кажется, оправдание. Тот же торрент, надо резать на брасе или даже на аггрегации, если есть возможность. Или еще круче, прямо на доступе. Чем ближе тем лучше. Я вообще не вижу таких правил, которые надо поставить на брас и которые нельзя применить ближе к клиенту. Изменено 3 ноября, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 8 ноября, 2011 (изменено) · Жалоба Коллеги, а подскажите и мне, раз уж пошла речь о брасах. Имеем сервер на Xeon E5504 с двумя онбордными 82574L, выполняет чисто NAT'ирующую функцию. Пропускает в час пик порядка 600Мбит/сек, загрузка процессоров 0,30,0,30% по каждому ядру, соответственно. Проблема: по счётчикам "ethtool -S" и по atop наблюдаю дропы на внешнем интерфейсе, конкретно rx_missed_errors. Например: root@bastinda:~# ethtool -S eth0|grep -Evw '0 NIC statistics: rx_packets: 43533795698 tx_packets: 40682635325 rx_bytes: 36303019460784 tx_bytes: 30007943506604 rx_broadcast: 46807 tx_broadcast: 456439 rx_multicast: 23 tx_multicast: 6 rx_errors: 6 multicast: 23 rx_crc_errors: 3 rx_no_buffer_count: 4878 rx_missed_errors: 398884271 tx_restart_queue: 183 tx_tcp_seg_good: 8404 rx_long_byte_count: 36303019460784 rx_csum_offload_good: 37211251049 rx_csum_offload_errors: 781413 tx_smbus: 456037 rx_smbus: 46900 PRC | sys 0.07s | user 0.01s | | #proc 92 | #trun 1 | #tslpi 94 | | #tslpu 0 | #zombie 0 | clones 0/s | | #exit 0/s | CPU | sys 0% | user 0% | irq 61% | | idle 339% | wait 0% | | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 0% | user 0% | irq 31% | | idle 69% | cpu002 w 0% | | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 0% | user 0% | irq 28% | | idle 72% | cpu000 w 0% | | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | cpu | sys 0% | user 0% | irq 0% | | idle 100% | cpu001 w 0% | | | steal 0% | guest 0% | curf 2.00GHz | curscal ?% | CPL | avg1 0.00 | | avg5 0.01 | avg15 0.05 | | | csw 352/s | | intr 65435/s | | | numcpu 4 | MEM | tot 5.7G | free 4.3G | cache 467.8M | | dirty 0.0M | buff 188.5M | slab 575.3M | | | | | | SWP | tot 6.0G | free 6.0G | | | | | | | | | vmcom 85.3M | vmlim 8.8G | NET | transport | tcpi 2/s | tcpo 2/s | udpi 1/s | udpo 214/s | tcpao 0/s | tcppo 0/s | tcprs 0/s | tcpie 0/s | tcpor 0/s | udpnp 0/s | udpip 0/s | NET | network | ipi 154305/s | ipo 145947/s | | ipfrw 15e4/s | deliv 5/s | | | | | icmpi 0/s | icmpo 1/s | NET | eth0 54% | pcki 80028/s | pcko 74122/s | si 544 Mbps | so 397 Mbps | coll 0/s | | mlti 0/s | erri 0/s | erro 0/s | drpi 2082/s | drpo 0/s | NET | eth1 54% | pcki 74292/s | pcko 71828/s | si 398 Mbps | so 542 Mbps | coll 0/s | | mlti 2/s | erri 0/s | erro 0/s | drpi 9/s | drpo 0/s | NET | eth1.30 53% | pcki 74281/s | pcko 71614/s | si 390 Mbps | so 539 Mbps | coll 0/s | | mlti 2/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | NET | eth1.40 0% | pcki 0/s | pcko 213/s | si 0 Kbps | so 2566 Kbps | coll 0/s | | mlti 0/s | erri 0/s | erro 0/s | drpi 0/s | drpo 0/s | PID RUID EUID THR SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPUNR CPU CMD 1/1 12 root root 1 0.03s 0.00s 0K 0K 0K 0K -- - S 2 1% kworker/2:0 3 root root 1 0.02s 0.00s 0K 0K 0K 0K -- - S 0 0% ksoftirqd/0 30118 root root 1 0.01s 0.00s 0K 0K 0K 0K -- - R 1 0% atop 5054 dyr dyr 1 0.00s 0.01s 0K 0K 0K 0K -- - S 1 0% sshd 13 root root 1 0.01s 0.00s 0K 0K 0K 0K -- - S 2 0% ksoftirqd/2 6242 snmp snmp 1 0.00s 0.00s 0K 0K 0K 0K -- - S 0 0% snmpd Ринги на сетевухах увеличены до 4К, остальной sysctl-тюнинг: net.ipv4.netfilter.ip_conntrack_max=655360 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=3600 net.core.wmem_max=16777216 net.ipv4.tcp_rmem="4096 8388608 16777216" net.ipv4.tcp_wmem="4096 4194394 16777216" net.core.wmem_default=4194394 net.core.rmem_default=8388608 net.core.netdev_max_backlog=2000 net.ipv4.tcp_max_syn_backlog=1024 net.core.somaxconn=262144 Клиенты не жалуются, вроде нормально работают, но мне не нравятся неконтролируемые дропы. Драйвер в ядре, так что с InterruptRate и прочими параметрами подгрузки модуля поиграться, увы, не могу. Изменено 8 ноября, 2011 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 8 ноября, 2011 (изменено) · Жалоба Сетевки слабые, наблюдал такие же дропы на NASах с такими бортовыми сетевками, замена на PT на одном сервере и на ET на втором проблемы полностью устранила. Можно попробовать net.core.netdev_max_backlog увеличить, потерь станет меньше. Изменено 8 ноября, 2011 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 9 ноября, 2011 · Жалоба Присоединяюсь к kayot, кроме того можно из средств реанимации попробовать увеличить количество прерываний, чтобы рагребался буфер быстрее. Да, прийдется дергать драйвер. Все эти меры, включая backlog дадут больше нагрузки, естессно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 9 ноября, 2011 · Жалоба ОК, попробую другие сетёвки. Ну а пока - как увеличивать количество прерываний? :) И не поможет ли отключение GSO,TSO и прочих сетевушных "разгружателей процессора"? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 9 ноября, 2011 · Жалоба Проблема: по счётчикам "ethtool -S" и по atop наблюдаю дропы на внешнем интерфейсе, конкретно rx_missed_errors. Дело явно не в картах: # lspci | grep -i eth 01:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 01:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection Настройка: # cat /etc/modprobe.d/e1000e options e1000e IntMode=1,1,1,1 InterruptThrottleRate=1,1,1,1 Результат: # grep -i eth /proc/interrupts 33: 2576662878 120 134 128 PCI-MSI-edge eth2 34: 8 103709084 4 7 PCI-MSI-edge eth3 35: 3 3 1220635003 5 PCI-MSI-edge eth0 36: 3 3 6 1834568772 PCI-MSI-edge eth1 # ethtool -S eth0|grep -Evw '0' NIC statistics: rx_packets: 28930332871 tx_packets: 17328725769 rx_bytes: 14025179602651 tx_bytes: 16844180841233 rx_broadcast: 9736 tx_broadcast: 2 rx_multicast: 15494 tx_multicast: 15645 rx_errors: 124 multicast: 15494 rx_length_errors: 31 rx_crc_errors: 70 rx_no_buffer_count: 81676 rx_missed_errors: 14613 rx_short_length_errors: 31 tx_tcp_seg_good: 1 tx_flow_control_xon: 30585 tx_flow_control_xoff: 40482 rx_long_byte_count: 14025179602651 rx_csum_offload_good: 25871861414 rx_csum_offload_errors: 35721 # uname -a Linux border.oblnet.ru 2.6.32-std-ng-alt13 #1 SMP PREEMPT Thu May 13 23:07:39 UTC 2010 x86_64 GNU/Linux На портах коммутатора ошибки есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 9 ноября, 2011 (изменено) · Жалоба Это Вы отписываетесь уже по своей проблеме или Вы вместе с Dur? В любом случае у вас rx_no_buffer_count: 81676, что говорит о маленьком кольце или о недостаточном количестве прерываний на карту. На коммутаторе будет видно ошибки CRC ну и про буфер тоже, если включен flow control, который обычно для бордеров отключают. Всё остальное не видно. А если патчкорд битый, то проблемы видно и невооруженным глазом. Но вообще, сумма ваших всех ошибок по приему пакетов - это 0.000003333% от общего числа принятых пакетов. Овчинка выделки не стоит. А вот у Dur ошибок достаточно много. Изменено 9 ноября, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 9 ноября, 2011 · Жалоба Это Вы отписываетесь уже по своей проблеме У меня конфигурация очень похожая, но проблемы нет, хотя нагрузка выше. или Вы вместе с Dur? Пока(?) нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 9 ноября, 2011 (изменено) · Жалоба Всё очень условно. Ни версии драйверов, ни ядра Dur не указал. Процессор не указали Вы, при этом у вас обоих автоматическая модерация прерываний. Но и это не все отличия. У вас 4 сетевые, у него 2. То есть формально всё похоже, а на практике куча различий, которые могут давать такой еффект. Кроме того, важно понять: пока у карты буфер не начал переполняться, ошибок вообще не будет. А потом они резко полезут, хотя трафика стало не на много больше. Ведь не ясно, как у вас выходящий трафик распределяется между указанными сетевыми. Вообщем я бы не брался сравнивать. 82571L - это бюджетная сетевая за 10$, соответственно чтобы она проглотила 1 гиг - её надо пилить. Именно отсюда пожелание поменять сетевую. После смены ничего делать нужно не будет. Изменено 9 ноября, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 9 ноября, 2011 · Жалоба Процессор не указали Вы Intel Core i3-530. На 650+250mbps и 80+70kpps загружен на 45+5+50+15%. 82571L - это бюджетная сетевая за 10$ Почти угадали :) Это внешняя двухпортовая Intel/PT, купленная пару лет назад за $200. Бюджетная за $10 - это скорее встроенная 82579V. соответственно чтобы она проглотила 1 гиг - её надо пилить. Единственное, чего в 571 нет по сравнению с 574 - MSI-X. Всё остальное - MSI, Throttling, Interrupt moderation - есть и работает. Гигабит реального трафика пропускает без малейших проблем. Именно отсюда пожелание поменять сетевую. Смотрите внимательнее - Dyr уже использует 82574, не должно с ними быть никаких проблем. У меня нормально работают и набортные 574, и внешние 571. В любом случае у вас rx_no_buffer_count: 81676, что говорит о маленьком кольце или о недостаточном количестве прерываний на карту. Буфер на всех картах установлен в максимум = 4096. Прерываниями занимаются throttling и interrupt moderation. 80k потерь на 28 миллиардов пакетов - в пределах статпогрешности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 9 ноября, 2011 (изменено) · Жалоба Илья, ошибок со стороны коммутатора нет: home-rs# show interfaces Gi1/0/14 controller GigabitEthernet1/0/14 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 0014.f286.530e (bia 0014.f286.530e) Description: Bastinda/em0 MTU 9198 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 120/255, rxload 90/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output never, output hang never Last clearing of "show interface" counters 46w5d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 354639000 bits/sec, 58880 packets/sec 5 minute output rate 473946000 bits/sec, 68522 packets/sec 1508406710 packets input, 2653600802 bytes, 0 no buffer Received 26799590 broadcasts (0 multicast) 0 runts, 0 giants, 0 throttles 1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 26313614 multicast, 0 pause input 0 input packets with dribble condition detected 829579646 packets output, 2307809862 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out Transmit GigabitEthernet1/0/14 Receive 1426515275 Bytes 3394905282 Bytes 535880314 Unicast frames 3649659606 Unicast frames 4219122 Multicast frames 36352055 Multicast frames 32162924 Broadcast frames 486123 Broadcast frames 0 Too old frames 673728227 Unicast bytes 0 Deferred frames 2690065866 Multicast bytes 0 MTU exceeded frames 31112411 Broadcast bytes 0 1 collision frames 0 Alignment errors 0 2 collision frames 0 FCS errors 0 3 collision frames 0 Oversize frames 0 4 collision frames 0 Undersize frames 0 5 collision frames 0 Collision fragments 0 6 collision frames 0 7 collision frames 1986087741 Minimum size frames 0 8 collision frames 1627407153 65 to 127 byte frames 0 9 collision frames 1120935096 128 to 255 byte frames 0 10 collision frames 3494211064 256 to 511 byte frames 0 11 collision frames 1712178364 512 to 1023 byte frames 0 12 collision frames 2335611945 1024 to 1518 byte frames 0 13 collision frames 0 Overrun frames 0 14 collision frames 0 Pause frames 0 15 collision frames 0 Excessive collisions 1 Symbol error frames 0 Late collisions 0 Invalid frames, too large 0 VLAN discard frames 1019 Valid frames, too large 0 Excess defer frames 0 Invalid frames, too small 2562741856 64 byte frames 0 Valid frames, too small 1901216238 127 byte frames 3088125248 255 byte frames 0 Too old frames 914523457 511 byte frames 0 Valid oversize frames 1145411520 1023 byte frames 0 System FCS error frames 3845145929 1518 byte frames 0 RxPortFifoFull drop frame 0 Too large frames 0 Good (1 coll) frames 0 Good (>1 coll) frames home-rs# show interfaces Gi1/0/14 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize Gi1/0/14 0 0 0 1 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Gi1/0/14 0 0 0 0 0 0 0 Потом, у тебя драйвер подгружен модулем с передачей параметров - у меня драйвер вкомпилен в ядро. Мне не знаком способ, с помощью которого можно было бы также передавать параметры. Dark_Angel, "сетевые" прерывания привязаны вручную к каждому из ядер. root@bastinda:~# cat /proc/interrupts |grep -Ew '4[0-5]' 40: 3647383392 7784534 0 0 PCI-MSI-edge ▒▒▒▒ 41: 59293525 3107213716 0 0 PCI-MSI-edge ▒▒▒▒ 42: 126967677 24689 0 0 PCI-MSI-edge eth0 43: 57560231 0 3924334140 0 PCI-MSI-edge ▒▒▒▒ 44: 74575469 0 41 1132824369 PCI-MSI-edge ▒▒▒▒ 45: 493012 0 0 6607 PCI-MSI-edge eth1 root@bastinda:~# cat /proc/irq/4[0-5]/smp_affinity 01 02 02 04 08 08 Не равномерно, поскольку привязал не сначала, успела накопиться статистика. Да, и ещё мелочь, но странная - имя девайса в статистике по прерываниям показывается почему-то псевдосимволами. Версии ядра и драйверов: root@bastinda:~#uname -a Linux bastinda 2.6.38.8-nat #2 SMP Fri Oct 21 19:15:27 MSK 2011 x86_64 x86_64 x86_64 GNU/Linux root@bastinda:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 11.04 Release: 11.04 Codename: natty root@bastinda:~# ethtool -i eth0 driver: e1000e version: 1.2.20-k2 firmware-version: 1.8-0 bus-info: 0000:01:00.0 Конфиг ядра на pastie. Изменено 9 ноября, 2011 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 9 ноября, 2011 · Жалоба Dyr, Попробуйте ethtool -C eth0 rx-usecs 33 и менять этот параметр 1,2,3 и т.д. Тлько осторожно, при неудачном совпадении обстоятельств может перегрузить тазик или повесить, включите какой-нить ватчдог и авторебут. У меня правда не падало :-) Но думаю дело не в этом. Сколько у вас суммарно правил в iptables? (nat+mangle+filter) Кстати смущает, что у вас по статистике очень много 64байт пакетов (если конечно счетчики не переполняются). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 9 ноября, 2011 (изменено) · Жалоба Количество правил: root@bastinda:~# cat /etc/iptables/config | grep -c NAT 494 root@bastinda:~# cat /etc/iptables/config | grep -vc NAT 37 Используется ipset. Большое количество NAT правил обусловлено выдачей 256 внешних ip-адресов на сетки /23 и ещё часть на binat. Большое количество мелких пакетов в статистике, думаю, обусловлено моим же собственным тестирование с помощью совершенно аццкой Mausezahn ;) Впрочем, я обнулю статистику и посмотрю. Выставление rx-usecs в 1 (что, насколько я понимаю, означает выставление InterruptThrottleRate в dynamic) дропы не убирает (хотя вроде их уменьшает). Изменено 9 ноября, 2011 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 ноября, 2011 · Жалоба Dyr rx-usecs это interrupt_rate в минус первой Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 9 ноября, 2011 · Жалоба Ну вот большое количество правил думаю и причина. Попробуйте сократить для теста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 10 ноября, 2011 · Жалоба Процессор не указали Вы Intel Core i3-530. На 650+250mbps и 80+70kpps загружен на 45+5+50+15%. Круто, но у человека Ксеон. Я не против что Ваш проц похож, прожевывает такой же трафик, но он другой. Как можно так сравнивать? Мать другая соответственно. Я абслютно уверен, что переполнение буфера и ошибки возникают из-за малого количества прерываний. Плавал уже. У вас система позволяет их делать больше - потерь нет и всё круто. Там не позволяет делать сколько надо - будут ошибки. 82571L - это бюджетная сетевая за 10$ Почти угадали :) Это внешняя двухпортовая Intel/PT, купленная пару лет назад за $200. Бюджетная за $10 - это скорее встроенная 82579V. Да, прошу прощения, я ошибся в цифре и неверно написал. Имелась ввиду 82574L, 82751 - EB же. соответственно чтобы она проглотила 1 гиг - её надо пилить. Единственное, чего в 571 нет по сравнению с 574 - MSI-X. Всё остальное - MSI, Throttling, Interrupt moderation - есть и работает. Гигабит реального трафика пропускает без малейших проблем. 82566DM - тоже имеет все эти фичи и стоит 10 баксов. Начинает ронять пакеты при 500-600 Мбит трафика на дефолтных настройках. На не дефолтных можно прогнать гигабит дуплексом. Вот только скажите, сколько стоит то время, чтобы так настроить систему и сколько стоит нормальная сетевая, скажем тот же 82575EB который на дефолте всё это сделает? Так что MSI, Throttling, Interrupt moderation - не залог успеха. Именно отсюда пожелание поменять сетевую. Смотрите внимательнее - Dyr уже использует 82574, не должно с ними быть никаких проблем. У меня нормально работают и набортные 574, и внешние 571. Я не против, что на 82754 можно прокачать гигабит, но нужно поработать напильником. Кроме того, возможна ситуация, когда система не сможет выгребать буфер карты настолько часто, насколько это нужно, чтобы он не переполнялся, т.к. с этим связаны накладные расходы. В вашем случае система мощная или настроена так, что успевает. У Dur, видимо, драйвер решает, что больше прерываний не надо. Поэтому я и говорил избавиться от дефолтовой модерации. В любом случае у вас rx_no_buffer_count: 81676, что говорит о маленьком кольце или о недостаточном количестве прерываний на карту. Буфер на всех картах установлен в максимум = 4096. Прерываниями занимаются throttling и interrupt moderation. 80k потерь на 28 миллиардов пакетов - в пределах статпогрешности. Я по поводу ваших характеристик сказал, что у вас всё ок. Насчет прерываний автоматом я уже говорил: бывает, что на дефолте драйвер правильно видит паттерн трафика, и подбирает количество прерываний. А бывает, что не правильно. Вам повезло, а Dur - нет. Версии ядра и драйверов: Вы используете относительно новое ядро. Данная версия драйвера уже есть 1.6.х. Стоит обратить на неё внимание. Ну и по-моему вкомпиливание драйвера в ядро - это лишнее. Никакого выиграша это не дает, зато чтобы обновить драйвер надо пересобирать ядро и перегружать машину. Не фонтан. Ну вот большое количество правил думаю и причина. Попробуйте сократить для теста. Если бы упиралось в iptables - ядро бы сидело в топе, нашим любимым ksoftirqd. На сколько я понял - это не наблюдается, соответственно пакеты теряются еще до ядра. rx-usecs это interrupt_rate в минус первой Верно, но, Dur, обратите внимание, что 1,2,3 - это те же режимы модерации, что и параметры для драйвера ITR, остальные значения - это статическое количество прерываний на очередь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 10 ноября, 2011 · Жалоба Dark_Angel, про ITR да, понял. 1 не помогает (или помогает, но слабо), 2 просто не выставить, а 3 ("dynamic conservative") - не пробовал, но сомневаюсь в необходимости. Сейчас трафик минимален (30 kpps), rx-usecs выставлен в 1, потери всё равно есть (за минуту набежало 4 445 rx_missed_errors, то есть 74 ошибки в секунду, или примерно каждый 400-ый пакет). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 10 ноября, 2011 · Жалоба Поэтому я и говорю: прибивайте прерывания статикой и смотрите, успевает ли система. Чтобы начать, расчитайте количество прерываний так, чтобы размер пакетов в буфере на момент прерывания было в 2 раза меньше размера буфера. Ну и дальше танцуйте - больше/меньше. Максимум 100К прерываний в секунду на очередь. Желаю Вам приятно провести время. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
