[Dyr]

Вы будете смеятся, но картина почему-то не меняется %) Какое значение rx-usecs не выставляю, по itop всё равно порядка 16000 прерываний в секунду:

 

root@bastinda:~# itop -a

INT                NAME          RATE             MAX


 0 [   0  362496591   ]     0 Ints/s     (max:     0)
 1 [   0          8   ]     0 Ints/s     (max:     0)
 8 [   0          1   ]     0 Ints/s     (max:     0)
 9 [   0          0   ]     0 Ints/s     (max:     0)
16 [   0          0   ]     0 Ints/s     (max:     0)
18 [2698          0   ]     0 Ints/s     (max:     6)
19 [   3          0   ]     0 Ints/s     (max:     0)
21 [   0          0   ]     0 Ints/s     (max:     0)
23 [   0          0   ]     0 Ints/s     (max:     0)
40 [   0          0   ] 15961 Ints/s     (max: 16373)
41 [   0          0   ]     0 Ints/s     (max:     0)
42 [   0          0   ]     0 Ints/s     (max:     0)
43 [9105          0   ]     0 Ints/s     (max:     0)
44 [  41 1973891401   ]     0 Ints/s     (max:     0)
45 [   0    1291773   ]     0 Ints/s     (max:     0)
46 [   0          0   ]     0 Ints/s     (max:     0)
^C

 

 

И кстати, rx-usecs выставляется максимум в 10 000, на цифру 10 001 уже ругается:

 

root@bastinda:~# ethtool -C eth1 rx-usecs 10000

root@bastinda:~# ethtool -C eth1 rx-usecs 10001

Cannot set device coalesce parameters: Invalid argument

root@bastinda:~# ethtool -C eth1 rx-usecs 10000

rx-usecs unmodified, ignoring

no coalesce parameters changed, aborting

 

Изменено 10 ноября, 2011 пользователем Dyr

[seagull]

Помогите разобратся.

Ситуация такая:

При возростании нагрузки резко взлетает ksoftirq в топе, и траффик падает. Дропов что интересно нет...

Причем трафик падает очень оригинально - по аплинку входящий растет, исходящий уменьшается совершенно симметрично, на графике хорошо видно.

Архитектура такая:

ядро: Linux giant 2.6.35.9-smp #1 SMP Mon Oct 24 18:53:32 MSD 2011 i686 Intel® Xeon® CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux

сетевка 4-портовая Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) (Intel PT quad port)

все 4 порта собраны в бонд, пакеты равномерно распределяются по линкам по layer3+4, на бонде висят вланы и аплинки, и даунлинки.

Драйвер родной ядерный:

driver: e1000e

version: 1.0.2-k4

firmware-version: 5.10-2

bus-info: 0000:19:00.1

Все 4 прерывания от 4 линков прибиты на 4 ядра второго процессора. Раньше affinity стояло FF - прерывания распределялись автоматом по всем ядрам, но тогда система нагружалась гораздо сильнее, что странно... (?)

 

На системе висят шейперы хешированные HTB, iptables пускающие клиентов в нет, и NAT.

В iptables около 800 правил линейно идут в FORWARD, на данный момент.

Канитель с взлетом нагрузки и падением исходящего трафика начинается около 1Gb входящего и 1Gb исходящего через bond0, соответственно с аплинка льется примерно 500мбит, по пакетам это что-то вроде 160Kpps через bond0.

 

Система вроде не самая дохлая, расчитывали получить от нее больше, хотя бы раза в 2. Что тут можно соптимизировать? Могут ли давать большой загруз 800 правил iptables? и поможет ли, если правила не линейными, а с ветвлением в разные пользовательские цепочки по адресу сетки например?

Поможет ли другая сетевка, с бОльшим количеством векторов прерываний? Уже думаю насчет закупки http://ark.intel.com/products/39776/Intel-Ethernet-Server-Adapter-X520-DA2, но если узкое место не там, то обидно будет выкинуть тысяч 40 на все это дело...

[Dark_Angel]

2Dyr: Потому что Вы не внимательно читаете. Чем меньше значение, тем больше прерываний, а не наоборот. Если у Вас при изменении этого параметра ничего не меняется, вероятно ваш драйвер не поддерживает динамическую смену параметров. Тогда меняйте через ITR в параметрах драйвера. Или меняйте драйвер.

 

2seagull: 800 правил в iptables? Так у вас еще всё круто работает - гигабит жует. Курите ipset или убирайте оттуда правила. Это основная причина.

 

Все 4 прерывания от 4 линков прибиты на 4 ядра второго процессора. Раньше affinity стояло FF - прерывания распределялись автоматом по всем ядрам, но тогда система нагружалась гораздо сильнее, что странно... (?)

 

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

 

Поможет ли другая сетевка, с бОльшим количеством векторов прерываний?

 

Не поможет.

Изменено 10 ноября, 2011 пользователем Dark_Angel

[Dyr]

Dark_Angel, спасибо, похоже драйвер не поддерживает изменение на лету, обидно. Что ж, буду пересобирать его отдельным модулем.

[nuclearcat]

Круто, но у человека Ксеон. Я не против что Ваш проц похож, прожевывает такой же трафик, но он другой. Как можно так сравнивать? Мать другая соответственно. Я абслютно уверен, что переполнение буфера и ошибки возникают из-за малого количества прерываний. Плавал уже. У вас система позволяет их делать больше - потерь нет и всё круто. Там не позволяет делать сколько надо - будут ошибки.

Ксеон Ксеону рознь.

model name : Intel® Xeon™ CPU 3.00GHz

model name : Intel® Xeon® CPU E5410 @ 2.33GHz

model name : Intel® Xeon® CPU L5520 @ 2.27GHz

 

Как не странно, но самый "быстрый" - последний.

Причем прибивка к ядрам в последних ксеонах с гипертридингом еще тот нюанс.

Ибо:

processor : 0

core id : 0

и

processor : 1

core id : 0

 

Одно ядро, и если на него прибить два разных процесса(но формально на два разных процессора), которым надо не менее половины реального физического ядра, тормозить будет нещадно и непредсказуемо (плюс гипертридинг вымывает кеш)

 

Да, прошу прощения, я ошибся в цифре и неверно написал. Имелась ввиду 82574L, 82751 - EB же.

struct e1000_info e1000_82574_info = {

..

FLAG_HAS_MSIX, pba = 32

 

Неплохо

 

82566DM - тоже имеет все эти фичи и стоит 10 баксов. Начинает ронять пакеты при 500-600 Мбит трафика на дефолтных настройках. На не дефолтных можно прогнать гигабит дуплексом. Вот только скажите, сколько стоит то время, чтобы так настроить систему и сколько стоит нормальная сетевая, скажем тот же 82575EB который на дефолте всё это сделает?

 

Так что MSI, Throttling, Interrupt moderation - не залог успеха.

ich8lan.c
* 82566DM Gigabit Network Connection
...
struct e1000_info e1000_ich8_info = { (если не ошибаюсь это именно ich8)
<------>.pba<--><------><------>= 8,

PBA 8k, что мало. В этом и соль, почему десктоп адаптеры сливают.

 

Буфер на всех картах установлен в максимум = 4096.

Прерываниями занимаются throttling и interrupt moderation.

80k потерь на 28 миллиардов пакетов - в пределах статпогрешности.

Кроме ring-буфера есть еще внутренний буфер карты.

 

Если бы упиралось в iptables - ядро бы сидело в топе, нашим любимым ksoftirqd. На сколько я понял - это не наблюдается, соответственно пакеты теряются еще до ядра.

Не всегда. Если прерывания отработали слишком медленно и карта ждала слишком долго, маленький PBA сыграет свою роль.

[seagull]

 

2seagull: 800 правил в iptables? Так у вас еще всё круто работает - гигабит жует. Курите ipset или убирайте оттуда правила. Это основная причина.

Что интересно, делал iptables -I FORWARD 2 -j ACCEPT - нагрузка softirq в top не особо снижалась.

Надо попробовать в период загрузки максимальной, когда ksoftirqd вылезает...

Кстати, второе правило вставляю потому как первым идет -j NETFLOW - забыл написать, там еще ipt_NETFLOW висит.

 

Насчет iptables - так что насчет ветвления? Если для каждой сети будет создаватся цепочка:

iptables -N fw-clients-10_0_0_x

iptables -N fw-clients-10_0_1_x

iptables -N fw-clients-10_0_2_x

и в них будут писатся правила, в а FORWARD соответственно

iptables -A FORWARD -s 10.0.0.0/24 -j fw-clients-10_0_0_x

iptables -A FORWARD -s 10.0.1.0/24 -j fw-clients-10_0_1_x

iptables -A FORWARD -s 10.0.2.0/24 -j fw-clients-10_0_2_x

Поможет так?

[nuclearcat]

Dark_Angel, спасибо, похоже драйвер не поддерживает изменение на лету, обидно. Что ж, буду пересобирать его отдельным модулем.

Мне еще иногда помогало после изменения прерываний сделать небольшое изменение ring buffer size

ethtool -G eth0 rx 1023

ethtool -G eth0 rx 1024

тогда карта "ресетилась" и иногда изменения применялись.

 

Теоретически раньше можно было указать что-то типа:

e1000e.InterruptThrottleRate=20

при загрузке, но не факт, что получится, такой фокус проходил с e1000 (без e в конце)

[Max P]

seagull, возьмите oprofile + perf top и всё станет ясно, какой модуль сколько жрет, я так у себя одного виновника отловил, шибко полегчало с того момента)

[Justas]

При возростании нагрузки резко взлетает ksoftirq в топе, и траффик падает. Дропов что интересно нет...

Причем трафик падает очень оригинально - по аплинку входящий растет, исходящий уменьшается совершенно симметрично, на графике хорошо видно.

 

На системе висят шейперы

 

Если изменения входящего/исходящего трафика симметричны, то как правило не хватает либо пропускной способности шины (я столкнулся с этим, когда много лет назад пытался пророутить гигабит на картах PCI-32bit, но это не ваш случай), либо в шейпере в зависимости от применяемого интерфейса зажата скорость дефолтного класса на 1000mbit (а должна стоять 4 гбита).

[Dark_Angel]

Да, прошу прощения, я ошибся в цифре и неверно написал. Имелась ввиду 82574L, 82751 - EB же.

struct e1000_info e1000_82574_info = {

..

FLAG_HAS_MSIX, pba = 32

 

Неплохо

 

Даташит даже врет, что 40.

 

82566DM - тоже имеет все эти фичи и стоит 10 баксов. Начинает ронять пакеты при 500-600 Мбит трафика на дефолтных настройках. На не дефолтных можно прогнать гигабит дуплексом. Вот только скажите, сколько стоит то время, чтобы так настроить систему и сколько стоит нормальная сетевая, скажем тот же 82575EB который на дефолте всё это сделает?

 

Так что MSI, Throttling, Interrupt moderation - не залог успеха.

ich8lan.c
* 82566DM Gigabit Network Connection
...
struct e1000_info e1000_ich8_info = { (если не ошибаюсь это именно ich8)
<------>.pba<--><------><------>= 8,

PBA 8k, что мало. В этом и соль, почему десктоп адаптеры сливают.

 

Мы с Вами уже это обсужали, наверное даже в этой же теме. Я привел пример с 82566 специально, чтобы показать, что фичи драйвера и железа - это не есть залог успеха.

 

Если бы упиралось в iptables - ядро бы сидело в топе, нашим любимым ksoftirqd. На сколько я понял - это не наблюдается, соответственно пакеты теряются еще до ядра.

Не всегда. Если прерывания отработали слишком медленно и карта ждала слишком долго, маленький PBA сыграет свою роль.

 

Я считаю, что это очень редкий случай, на скоростях выше гигабита, наверное, встречается. Обычно всё упирается в то, что система не может генерировать столько прерываний, чтобы выгребать буфер своевременно.

 

Кстати, как можно проверить, что бефер переполняется именно за счет медленных прерываний?

 

Если изменения входящего/исходящего трафика симметричны, то как правило не хватает либо пропускной способности шины (я столкнулся с этим, когда много лет назад пытался пророутить гигабит на картах PCI-32bit, но это не ваш случай), либо в шейпере в зависимости от применяемого интерфейса зажата скорость дефолтного класса на 1000mbit (а должна стоять 4 гбита).

 

А разве в случае узкого класса и дропа пакетов лезет в топ ksoftirq? Не верю.

 

Что интересно, делал iptables -I FORWARD 2 -j ACCEPT - нагрузка softirq в top не особо снижалась.

Надо попробовать в период загрузки максимальной, когда ksoftirqd вылезает...

 

Не верю, что 800 (!!!) правил iptables не влияют на загрузку ядра. Не исключается, конечно, вариант, что ложит что-то другое, но тогда Вам правильно советуют профайлер.

 

Кстати, второе правило вставляю потому как первым идет -j NETFLOW - забыл написать, там еще ipt_NETFLOW висит.

 

Для ядерного netflow - это семечки. Кроме того, его статистика доступна через обращение к драйверу. Посмотрите загрузку там. Мало ли, может не правильно настроен.

 

Насчет iptables - так что насчет ветвления? Если для каждой сети будет создаватся цепочка:

iptables -N fw-clients-10_0_0_x

iptables -N fw-clients-10_0_1_x

iptables -N fw-clients-10_0_2_x

и в них будут писатся правила, в а FORWARD соответственно

iptables -A FORWARD -s 10.0.0.0/24 -j fw-clients-10_0_0_x

iptables -A FORWARD -s 10.0.1.0/24 -j fw-clients-10_0_1_x

iptables -A FORWARD -s 10.0.2.0/24 -j fw-clients-10_0_2_x

Поможет так?

 

Поможет, просто Вы будете изобретать свой велосипед, вместо уже существующего.

Изменено 10 ноября, 2011 пользователем Dark_Angel

[seagull]

seagull, возьмите oprofile + perf top и всё станет ясно, какой модуль сколько жрет, я так у себя одного виновника отловил, шибко полегчало с того момента)

Блин, бьюсь, не могу собрать perf!

 

root@giant:/usr/src/linux-2.6.35.9/tools/perf# make
Makefile:512: No libdw.h found or old libdw.h found or elfutils is older than 0.138, disables dwarf support. Please install new elfutils-devel/libdw-dev
Makefile:565: newt not found, disables TUI support. Please install newt-devel or libnewt-dev
   CC util/symbol.o
util/symbol.c: In function 'filename__read_build_id':
util/symbol.c:1202: error: 'GElf_Nhdr' undeclared (first use in this function)
util/symbol.c:1202: error: (Each undeclared identifier is reported only once
util/symbol.c:1202: error: for each function it appears in.)
util/symbol.c:1202: error: 'nhdr' undeclared (first use in this function)
cc1: warnings being treated as errors
util/symbol.c:1203: warning: ISO C90 forbids mixed declarations and code
util/symbol.c: In function 'sysfs__read_build_id':
util/symbol.c:1241: error: 'GElf_Nhdr' undeclared (first use in this function)
util/symbol.c:1241: error: expected ';' before 'nhdr'
util/symbol.c:1242: warning: ISO C90 forbids mixed declarations and code
util/symbol.c:1244: error: 'nhdr' undeclared (first use in this function)
make: *** [util/symbol.o] Error 1

 

Где бы взять мне этих elfutils-devel/libdw-dev? Там слака стоит, я с ней не особо знаком...

slackpkg search elfutils и libdw ничего не находят....

Помогите, гуру!

[bos9]

Не могу понять - работает NAPI или нет. В данный момент кол-во прерываний примерно равно суммарному pps на интерфейсах:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
1  0      0 861032 209352 1175644    0    0     0     3    1    0  1  6 94  0  0	
0  0      0 863004 209352 1175644    0    0     0     0 21118 2942  1  5 94  0  0	
0  0      0 863016 209352 1175648    0    0     0     0 21043 2980  4  9 88  0  0	
0  0      0 863032 209352 1175648    0    0     0     0 22581 3192  1  3 96  0  0	
1  0      0 863032 209352 1175648    0    0     0     0 22349 3045  0  3 97  0  0

С другой стороны, вроде как пока система справляется, так и должно быть для уменьшения задержек. Непонятно тогда как узнать работает таки поллинг или нет?

И еще не понятно почему perf top показывает совсем другое значение intr/s:

 

------------------------------------------------------------------------------
  PerfTop:    5364 irqs/sec  kernel:96.4% [100000 cycles],  (all, 2 CPUs)
------------------------------------------------------------------------------

            samples    pcnt         RIP          kernel function
 ______     _______   _____   ________________   _______________

            4711.00 - 12.9% - ffffffffa00df93d : e1000_intr	[e1000]
            3319.00 -  9.1% - ffffffffa00e1caa : e1000_clean	[e1000]
             937.00 -  2.6% - ffffffff813e1ba3 : ipt_do_table
             822.00 -  2.3% - ffffffff8131cefe : uhci_irq
             787.00 -  2.2% - ffffffff8141aaa4 : _spin_lock
             675.00 -  1.9% - ffffffff81374004 : pskb_expand_head
             668.00 -  1.8% - ffffffff810122c0 : irq_entries_start
             640.00 -  1.8% - ffffffff81399ac8 : nf_ct_tuple_equal
             522.00 -  1.4% - ffffffffa00e29d8 : e1000_clean_rx_irq	[e1000]
             509.00 -  1.4% - ffffffff810183a1 : native_read_tsc
             503.00 -  1.4% - ffffffff8139879c : nf_iterate
             483.00 -  1.3% - ffffffffa004d14f : iphash_id	[ip_set_iphash]
             414.00 -  1.1% - ffffffff813a5b93 : ip_route_input
             394.00 -  1.1% - ffffffff8141a9ab : _spin_lock_irqsave
             375.00 -  1.0% - ffffffff81069fbe : enqueue_hrtimer

 

Забыл изложить собственно проблему:

Даже при очень не большом трафике (на входе 100-150мбит 10-20K pps) наблюдается небольшой, но постоянный рост rx_missed_errors на внешнем интерфейсе. При этом ksoftirqd проц не жрет, да и вообще никаких затыков не ощущается. Ринг буфер стоит 2048 (до этого стояло 4096 без особой разницы). Прерывания с двух сетевых раскиданы вручную по обоим процам, в iptables около 40 правил, сервер терминирует pptp плюс шейпит (tbf на каждый виртуальный интерфейс).

Изменено 15 ноября, 2011 пользователем bos9

[telecom]

Прочел. Понял, что я знаю, что ни чего не знаю))))

В общем на суд знатаков, прошу критиковать:

[root@router ~]# ethtool -S eth0

NIC statistics:

rx_packets: 304662191062

tx_packets: 298952018911

rx_bytes: 249892216109158

tx_bytes: 249491050219840

rx_errors: 42

tx_errors: 0

rx_dropped: 0

tx_dropped: 0

multicast: 41316

collisions: 0

rx_over_errors: 0

rx_crc_errors: 42

rx_frame_errors: 0

rx_fifo_errors: 0

rx_missed_errors: 0

tx_aborted_errors: 0

tx_carrier_errors: 0

tx_fifo_errors: 0

tx_heartbeat_errors: 0

rx_pkts_nic: 304662190094

tx_pkts_nic: 298952018890

rx_bytes_nic: 252329513536453

tx_bytes_nic: 251964328135799

lsc_int: 6

tx_busy: 0

non_eop_descs: 0

broadcast: 423728

rx_no_buffer_count: 0

tx_timeout_count: 0

tx_restart_queue: 3526

rx_long_length_errors: 0

rx_short_length_errors: 0

tx_flow_control_xon: 200

rx_flow_control_xon: 0

tx_flow_control_xoff: 1302

rx_flow_control_xoff: 0

rx_csum_offload_errors: 5502693

low_latency_interrupt: 0

alloc_rx_page_failed: 0

alloc_rx_buff_failed: 0

lro_aggregated: 0

lro_flushed: 0

lro_recycled: 0

rx_no_dma_resources: 0

hw_rsc_aggregated: 0

hw_rsc_flushed: 0

rx_flm: 0

fdir_match: 9374988

fdir_miss: 295330433750

fdir_overflow: 360297

fcoe_bad_fccrc: 0

fcoe_last_errors: 0

rx_fcoe_dropped: 0

rx_fcoe_packets: 0

rx_fcoe_dwords: 0

tx_fcoe_packets: 0

tx_fcoe_dwords: 0

os2bmc_rx_by_bmc: 0

os2bmc_tx_by_bmc: 0

os2bmc_tx_by_host: 0

os2bmc_rx_by_host: 0

tx_queue_0_packets: 102346468364

tx_queue_0_bytes: 85253167191057

tx_queue_1_packets: 49014845221

tx_queue_1_bytes: 40744742068421

tx_queue_2_packets: 49260570693

tx_queue_2_bytes: 41242446121324

tx_queue_3_packets: 49376767754

tx_queue_3_bytes: 41200399875556

tx_queue_4_packets: 48953309596

tx_queue_4_bytes: 41050281639768

tx_queue_5_packets: 57289

tx_queue_5_bytes: 13328358

rx_queue_0_packets: 52215552334

rx_queue_0_bytes: 42726612402341

rx_queue_1_packets: 52085341253

rx_queue_1_bytes: 42670094837357

rx_queue_2_packets: 49916603832

rx_queue_2_bytes: 40805330152523

rx_queue_3_packets: 50200432945

rx_queue_3_bytes: 41308153584049

rx_queue_4_packets: 50344224432

rx_queue_4_bytes: 41266780542778

rx_queue_5_packets: 49900036272

rx_queue_5_bytes: 41115244594764

[Dark_Angel]

2bos9:

 

Ситуация странная, согласен. Посмотрите ошибки на порту свитча. И покажите что за машина и сетевая у вас.

Если количество пакетов = количеству прерываний, значит NAPI не работает, но это не значит, что он не включен в драйвере. Для современных машин всетаки 10К pps - это мало, вполне можно обходится и без NAPI. Проверить умеет ли драйвер NAPI можно по его инфе, как модулю. modinfo e1000. Сейчас современные драйвера все идут с NAPI. Чтобы его отключить - нужно специально это указывать при компиляции.

 

2telecom:

 

Покажите ring buffer и посмотрите ошибки на свитче. Ну и кстати у Вас количество ошибок = 0.0018062%. Уверены, что хотите тратить на это время?

Изменено 15 ноября, 2011 пользователем Dark_Angel

[bos9]

Посмотрите ошибки на порту свитча. И покажите что за машина и сетевая у вас.

 

Машинка:

model name	: Intel(R) Core(TM)2 CPU         E7600  @ 3.06GHz

top - 17:34:19 up 266 days,  6:37,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:  99 total,   2 running,  97 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.7%us,  1.3%sy,  0.0%ni, 92.4%id,  0.0%wa,  0.7%hi,  5.0%si,  0.0%st
Cpu1  :  1.0%us,  1.0%sy,  0.0%ni, 93.2%id,  0.0%wa,  1.0%hi,  3.7%si,  0.0%st
Mem:   3478596k total,  2634660k used,   843936k free,   209696k buffers
Swap:        0k total,        0k used,        0k free,  1185020k cached

lspci | grep -i ether
01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
01:01.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)

ethtool -i eth2
driver: e1000
version: 7.3.21-k3-NAPI
firmware-version: N/A
bus-info: 0000:01:01.0

 

По поводу ошибок, действительно наблюдается приличный рост ошибок, связанных со слишком маленьким размером кадров. Причем не только на интересующем меня порту.

#sh interfaces gigabitEthernet 0/11 counters errors 

Port        Align-Err    FCS-Err   Xmit-Err    Rcv-Err UnderSize
Gi0/11              0          0          0        75830602492235

Port      Single-Col Multi-Col  Late-Col Excess-Col Carri-Sen     Runts    Giants
Gi0/11             0         0         0          0         0       758         0

 

Как бы то ни было, счетчик UnderSize на свиче растет значительно быстрее, чем счетчик rx_missed_errors на сетевом интерфейсе.

[Dark_Angel]

Ну тут однозначно сначала надо избавится от любых ошибок, вне зависимости от того кто растет быстрее, а кто медленее.

 

А то такое ошибки "связанные со слишком маленьким размером кадров"?

[bos9]

А то такое ошибки "связанные со слишком маленьким размером кадров"?

 

Циско-сайт говорит, что:

Undersize

Description: CatOS sh port and Cisco IOS sh interfaces counters errors . The frames received that are smaller than the minimum IEEE 802.3 frame size of 64 bytes (which excludes framing bits, but includes FCS octets) that are otherwise well formed. Common Causes: Check the device that sends out these frames.

[Dark_Angel]

Короче говоря - это битые фреймы. Проверяйте железки. Возможно что-то кромсает кадры или, например, флудит в порт кошки. К роутеру здесь, увы, вопросов нет пока.

[nuclearcat]

Это не битые фреймы, это known case с Linux, почти уверен, что на линуксе есть тегированные вланы и иос не самый свежий(или в некоторых свитчах аппаратно ошибки считаются, и неправильно)

Ничего страшного.

 

Вот примерное описание:

Cisco Catalyst 3750 Series Switches In releases prior to Cisco IOS 12.1(19)EA1, when dot1q is used on the trunk interface on the Catalyst 3750, runts can be seen on show interfaces output because valid dot1q encapsulated packets, which are 61 to 64 bytes and include the q-tag, are counted by the Catalyst 3750 as undersized frames, even though these packets are forwarded correctly. In addition, these packets are not reported in the appropriate category (unicast, multicast, or broadcast) in receive statistics. This issue is resolved in Cisco IOS release 12.1(19)EA1 or 12.2(18)SE or later.

[bos9]

почти уверен, что на линуксе есть тегированные вланы и иос не самый свежий

 

В точку! Правда C2960-LANBASE-M Version 12.2(35)SE5, но все же... Спасиб! Сэкономили мне кучу времени. Продолжу искать причину дропов на маршрутизаторе.

Изменено 15 ноября, 2011 пользователем bos9

[telecom]

2telecom:

 

Покажите ring buffer и посмотрите ошибки на свитче. Ну и кстати у Вас количество ошибок = 0.0018062%. Уверены, что хотите тратить на это время?

Нет предела совершенству....

[root@router etc]# ethtool -k eth0

Offload parameters for eth0:

rx-checksumming: on

tx-checksumming: on

scatter-gather: on

tcp-segmentation-offload: on

udp-fragmentation-offload: off

generic-segmentation-offload: off

generic-receive-offload: off

large-receive-offload: off

 

 

ethtool -g eth0

Ring parameters for eth0:

Pre-set maximums:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

Current hardware settings:

RX: 1024

RX Mini: 0

RX Jumbo: 0

TX: 1024

[NiTr0]

tso отключить, на роутере нафиг не упало (вообще, на роутере из оффлоадов надо sg+tx/rx checksum, от остального - толку 0). Хотя ошибки не уберет, но все же лишнее.

[telecom]

и это все "бурное" обсуждение?)

[yannails]

Supermicro 2xIntel Xeon E5606 2.13GHz, Intel 82576 (4 порта по 1Gbit использую пока только 2)

Centos 5.6

 

igb-3.1.16

 

IntMode=2,2,2,2 RSS=4,4,4,4 InterruptThrottleRate=3000,3000,3000,3000

 

210:          2          0          0          0          0          0          0          0       PCI-MSI-X  eth2
218:      24443          0          0          0          0          0          0    7060595       PCI-MSI-X  eth2-TxRx-0
226:       5530          0          0          0          0          0    6942637          0       PCI-MSI-X  eth2-rx-1
234:       5389          0          0          0          0    6947488          0          0       PCI-MSI-X  eth2-rx-2
51:       5695          0          0          0    6974047          0          0          0       PCI-MSI-X  eth2-rx-3
59:          2          0          0          0          0          0          0          0       PCI-MSI-X  eth3
67:      16571          0          0    6401620          0          0          0          0       PCI-MSI-X  eth3-TxRx-0
75:       8048          0    6151391          0          0          0          0          0       PCI-MSI-X  eth3-rx-1
83:       7785    6196376          0          0          0          0          0          0       PCI-MSI-X  eth3-rx-2
91:    5746001          0          0          0          0          0          0          0       PCI-MSI-X  eth3-rx-3

 

Сервисы:

 

nat + ipset
shaper htb
named

 

трафик 400Mbit (40kpps)

проблема в том что система работает нормально какоето время, потом трафик падает в 2 раза, перезагрузка сервера и снова все нормально,

в чем может быть проблема?

 

 

перегрузился в 18:00 все стало ОК, потом через 2 часа загнулось, в 21:00 прегрузился и снова все ОК

смущает именно то что после перезагрузки все востанавливается

в логах чисто, счетчики без ошибок

Изменено 17 ноября, 2011 пользователем yannails

[nuclearcat]

Помониторьте /proc/sys/net/netfilter/nf_conntrack_count

Возможно дело где-то в этом направлении