Dark_Angel Опубликовано 13 апреля, 2012 (изменено) · Жалоба Ваш вопрос изначально не имеет ответа, потому что не понятно что вы собираетесь на нем роутить. И вообще, только роутить ли. Поэтому уточняйте что вы хотите делать и, возможно, будет возможность ответить на ваш вопрос. На тупом роутинге, с размером пакета 500-600 байт, вы забьете двухпортовую 82576 без проблем. За broadcom не скажу. Это примерно 800 Кpps во все стороны ( 4 Гбита ). Вот только это конь в вакууме. Изменено 13 апреля, 2012 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 13 апреля, 2012 · Жалоба Ваш вопрос изначально не имеет ответа, потому что не понятно что вы собираетесь на нем роутить. И вообще, только роутить ли. Сервер будет только роутить - BIRD c FV + ipt_netflow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 18 апреля, 2012 · Жалоба За АМД и Броадком не скажу, но на Интеле и 82576 должны пропихнуть до 800Кpps. Тут еще зависит от настроек ipt_netflow. На таком трафике ipt_netflow может скушать 10-15% от процессора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spectrum Опубликовано 27 апреля, 2012 · Жалоба Собираемся взять на сервер BRAS pppoe вторую сетевую карту 4-х головую Гигабит. Задачи - bonding + vlan + pppoe терминация + шейпинг. На выбор есть карта E1G44HT (I340-T4), как я понял она на чипе Intel 82580, и вторая E1G44ET2 Gigabit ET2 на чипе Intel 82576. Первая 10 т.р., вторая 13 т.р. Для работы в указанных задачах разницы между ними не увидел. Спрашивается - нужно ли платить больше, у кого-нибудь стоят в указанных задачах карты на чипе 82580? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SoulDivider Опубликовано 12 мая, 2012 (изменено) · Жалоба Здравствуйте, коллеги. Прошу помощи в следующей проблеме. Имеется сервер с 82576 и 2 Xeon 5650: # uname -r 2.6.36.3 # ethtool -i eth0 driver: igb version: 3.4.7 firmware-version: 1.8-2 bus-info: 0000:05:00.0 прерывания разбросаны по ядрам 64: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0 65: 91 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-0 66: 28 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-1 67: 36 0 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-2 68: 34 0 0 14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-3 69: 38 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-4 70: 41 0 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-5 71: 44 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-6 72: 47 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-7 Проблема в следующем. Не распределяются исходящие пакеты по всем очередям, а льются все в одну # ethtool -S eth0 | grep tx_queue | grep packets tx_queue_0_packets: 0 tx_queue_1_packets: 0 tx_queue_2_packets: 3 tx_queue_3_packets: 0 tx_queue_4_packets: 0 tx_queue_5_packets: 1210115 tx_queue_6_packets: 0 tx_queue_7_packets: 0 Уж не знаю куда копать, ставил для теста Debian 2.6.32, драйвер менял (проблема как на ядерном igb, так и на новых версиях), разносил tx и rx по разным векторам. Прошу помощи. UPD. tc qdisc add dev eth0 root handle 1: multiq так же ничего не меняет. Изменено 12 мая, 2012 пользователем SoulDivider Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 12 мая, 2012 · Жалоба Не распределяются исходящие пакеты по всем очередям, а льются все в одну Ну и фиг с ним, нагрузка-то мизерная от tx... у нас на одной машине все ок: # ethtool -S eth0 | grep tx_queue | grep packets tx_queue_0_packets: 5534731940 tx_queue_1_packets: 5694937962 # ethtool -i eth0 driver: igb version: 2.4.12 firmware-version: 1.2-1 bus-info: 0000:04:00.0 # uname -r 2.6.35.13-i686 на другой - хуже: # ethtool -S eth0 | grep tx_queue | grep packets tx_queue_0_packets: 20027799858 tx_queue_1_packets: 146477329759 tx_queue_2_packets: 889867321 tx_queue_3_packets: 16547517 # ethtool -i eth0 driver: igb version: 2.4.12 firmware-version: 1.2-1 bus-info: 0000:03:00.0 # uname -r 2.6.35.13-i686 на третьей - еще хуже: # uname -r 2.6.35.8-i686 # ethtool -i eth0 driver: igb version: 2.1.0-k2 firmware-version: 1.2-1 bus-info: 0000:01:00.0 border# # ethtool -S eth0 | grep tx_queue | grep packets # ethtool -S eth0 | grep tx_queue | grep packets tx_queue_0_packets: 269544 tx_queue_1_packets: 186479 tx_queue_2_packets: 19650 tx_queue_3_packets: 2615 tx_queue_4_packets: 16029371831 tx_queue_5_packets: 3144 С чем связано - неведомо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 13 мая, 2012 · Жалоба SoulDivider, что это за трафик? Транзит или порожден самой машиной? Много соединений? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SoulDivider Опубликовано 13 мая, 2012 · Жалоба Умник, порожден. Соединений не много, грубо говоря в качестве теста генерировал спуфленый icmp echo request. На rx все распределялось равномерно, а вот reply лился в одну очередь. Ну и фиг с ним, нагрузка-то мизерная от tx... Не уверен на 100%, но мне кажется что 1 ядро(core5 в моем случае), к которому привязана единственная задействованная очередь может быть тонким местом. Плюс, как мне кажется, будут частые копирования данных с ядер в ядро(core5). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 16 мая, 2012 (изменено) · Жалоба собрал сервер на http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8.cfm + Intel EXPI9402PT (на шине PCIe) чип Intel 82576, решаемые задачи BGP fv + ipt_netflow + будут VLANы планирую поставить CentOS6.2 (2.6.32) x86_64 + ipt_netflow под эту систему (на наг есть ссылка на репозиторий) + igb последний драйвер 3.4.7 1. Насколько лучше с точки зрения производительности системы (маршрутизация, прерывания CPU), остаться на этой версии ядра или обновить его то до какой? Или перейти на другой дистр linux если лучше менять версию ядра? 2. Насколько будет эффективнее поднять bonding (eth0+eth1) с точки зрения раходования прерываний CPU и маршрутизации? Есть ли в нем необходимость? 3. В системе 8 ядер, как лучше распределить прерывания и сколько сделать очередей RX,TX от каждого интерфейса? Изменено 16 мая, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 16 мая, 2012 · Жалоба Делаете по 8 комбо очередей, бондинг - думаю не обязателен, дистр - я бы ставил какой-то embedded. LEAF к примеру. Не нужно винт держать (дорогой и ненадежный), нет отказов при внезапном ребуте (если только в конфигах сами не накосячили ессно), ФС в рид-онли. И, думается, железка гораздо больше 1 гбита пережует. Хотя все же эта платформа более подходит для каких-то вычислительных задач, в качестве молотилки траффика ИМХО лучше будет себя показывать какой-то десктопный i5... При меньшем энергопотреблении. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 16 мая, 2012 (изменено) · Жалоба Делаете по 8 комбо очередей так ? eth0-txrx-0 cpu0-0 eth0-txrx-1 cpu0-1 eth0-txrx-2 cpu0-2 eth0-txrx-3 cpu0-3 eth0-txrx-4 cpu1-0 eth0-txrx-5 cpu1-1 eth0-txrx-6 cpu1-2 eth0-txrx-7 cpu1-3 eth1-txrx-0 cpu0-0 eth1-txrx-1 cpu0-1 eth1-txrx-2 cpu0-2 eth1-txrx-3 cpu0-3 eth1-txrx-4 cpu1-0 eth1-txrx-5 cpu1-1 eth1-txrx-6 cpu1-2 eth1-txrx-7 cpu1-3 а вместо Zebra bird установить можно на LEAF? Изменено 16 мая, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 16 мая, 2012 · Жалоба так ? да а вместо Zebra bird установить можно на LEAF? в комплекте есть, в боевых условиях не испытывал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 18 мая, 2012 · Жалоба а кто чем мониторит/собирает статистику на бордере? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Shrim Опубликовано 22 мая, 2012 · Жалоба Ситуация: HP DL360G7 и HP DL180G6, на первом установлен ESXi 5.0, второй под завязку набит дисками и на нём установлен debian 6.0.5. В обеих серверах установлены 10Gb сетевухи HP NC552SFP , соединены DAC SFP+ , DL180G6 выступает в роли СХД (на NetApp денег не хватило) раздавая массив дисков по iSCSI. Хорошая новость - всё работает. Вот только производительность оставляет желать лучшего - в виртуальной машине CrystalDiskMark выдаёт 550-600MB/s на чтение/запись, а ожидалось примерно 800 (локально блочное устройство выдаёт больше 1000 и на чтение и на запись). Логично, первым делом, включил Jumbo Frames, ожидая прироста производительности, но не тут то было - на чтение производительность увеличилась, а на запись просела до 50MB/s. Начал разбираться в чём дело и пока пришёл только к одному выводу. В debian драйвер сетевухи be2net и как оказалось он не поддерживает lro (по умолчанию выключена и включить не удаётся). Любые манипуляци с ethtool и sysctl не дают ни какого результата. Драйвер предоставляет всего две очереди обработки прерываний, на rx и на tx, распределение прерываний на разные ядра так же не дало результатов. Вот некоторая статистика: # ifconfig eth0 eth0 Link encap:Ethernet HWaddr b4:99:ba:26:37:90 inet addr:192.168.7.7 Bcast:192.168.7.255 Mask:255.255.255.0 inet6 addr: fe80::b699:baff:fe26:3790/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:324222045 errors:3822419471 dropped:0 overruns:267385334 frame:3439909610 TX packets:319982020 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10000 RX bytes:393782237788 (366.7 GiB) TX bytes:446418780688 (415.7 GiB) # ethtool -S eth0 NIC statistics: rx_packets: 324222596 tx_packets: 319982219 rx_bytes: 393782844718 tx_bytes: 446418859994 rx_errors: 3823113432 tx_errors: 0 rx_dropped: 0 tx_dropped: 0 be_tx_reqs: 144824470 be_tx_stops: 0 be_fwd_reqs: 0 be_tx_wrbs: 582718462 be_polls: 0 be_tx_events: 104726012 be_rx_events: 0 be_tx_compl: 144824470 be_rx_compl: 324222598 be_ethrx_post_fail: 0 be_802_3_dropped_frames: 0 be_802_3_malformed_frames: 0 be_tx_rate: 0 be_rx_rate: 0 rx_unicast_frames: 0 rx_multicast_frames: 0 rx_broadcast_frames: 0 rx_crc_errors: 1292011755 rx_alignment_symbol_errors: 95 rx_pause_frames: 3593254895 rx_control_frames: 93 rx_in_range_errors: 0 rx_out_range_errors: 0 rx_frame_too_long: 2148591072 rx_address_match_errors: 111 rx_vlan_mismatch: 334413890 rx_dropped_too_small: 334411119 rx_dropped_too_short: 2612 rx_dropped_header_too_small: 159 rx_dropped_tcp_length: 0 rx_dropped_runt: 0 rx_fifo_overflow: 374126 rx_input_fifo_overflow: 19576043 rx_ip_checksum_errs: 0 rx_tcp_checksum_errs: 0 rx_udp_checksum_errs: 48096620 rx_non_rss_packets: 19651525 rx_ipv4_packets: 983659 rx_ipv6_packets: 1182224 tx_unicastframes: 0 tx_multicastframes: 0 tx_broadcastframes: 0 tx_pauseframes: 0 tx_controlframes: 0 rx_drops_no_pbuf: 247435211 rx_drops_no_txpb: 1663 rx_drops_no_erx_descr: 20244 rx_drops_no_tpre_descr: 1077187 rx_drops_too_many_frags: 0 rx_drops_invalid_ring: 0 forwarded_packets: 0 rx_drops_mtu: 0 rx_drops_no_fragments: 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 мая, 2012 · Жалоба Собрать свежий драйвер религия не позволяет, коли в репозиториях нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 14 июня, 2012 (изменено) · Жалоба Настроил таки сервер Ядро вот отсюда http://alex-at.ru/linux/centos-6-2-rps [root@testrouter ~]# uname -a Linux testrouter.mservice 2.6.32-220.7.1.el6.alex.rps.2.x86_64 #1 SMP Sat Mar 24 11:36:12 MSK 2012 x86_64 x86_64 x86_64 GNU/Linux [root@testrouter ~]# Сетевая 06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 06:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) Драйвер по умолчанию который шел с ядром [root@testrouter ~]# ethtool -i eth0 driver: igb version: 3.0.6-k firmware-version: 1.2-1 bus-info: 0000:06:00.0 [root@testrouter ~]# Драйвер грузится по умолчанию, хотя поиграться можно всего только одним параметром [root@testrouter src]# modinfo igb | grep parm parm: max_vfs:Maximum number of virtual functions to allocate per physical function (uint) [root@testrouter src]# хотя в исходниках более нового драйвера параметров для тюнинга очень много. Очереди создаются как надо. но во время тестов картина по рерываниям такая 58: 0 0 0 1 0 0 0 0 PCI-MSI-edge eth1 59: 4388 4368 4462 4469 4449 4370 4394 4409 PCI-MSI-edge eth1-TxRx-0 60: 4434 4353 4377 4393 4449 4457 4355 4374 PCI-MSI-edge eth1-TxRx-1 61: 4568 4573 4481 4502 4507 4513 4465 4560 PCI-MSI-edge eth1-TxRx-2 62: 4377 4393 4352 4434 4356 4374 4457 4449 PCI-MSI-edge eth1-TxRx-3 63: 4354 4379 4456 4449 4353 4430 4393 4378 PCI-MSI-edge eth1-TxRx-4 64: 4354 4430 4395 4378 4456 4450 4379 4355 PCI-MSI-edge eth1-TxRx-5 65: 2062948 2066143 2076223 2075504 2049662 2053214 2060639 2057563 PCI-MSI-edge eth1-TxRx-6 66: 4384 4396 4445 4351 4363 4350 4439 4464 PCI-MSI-edge eth1-TxRx-7 Все пакеты обрабатываются одной очередью eth1-TxRx-6 но равномерно размазываются по всем ядрам. Какой смысл тогда в таком количестве очередей или както по особенному грузить модуль сетевой карты? Или это глюки? Во время тестов в одну сторону 465k PPS на интерфейсе появились overruns:1002943 [root@testrouter ~]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 90:E2:BA:06:FF:50 inet6 addr: fe80::92e2:baff:fe06:ff50/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:332723284 errors:0 dropped:0 overruns:1002943 frame:0 TX packets:1306 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:80117618310 (74.6 GiB) TX bytes:429633 (419.5 KiB) Memory:d8520000-d8540000 [root@testrouter ~]# [root@testrouter ~]# ethtool -S eth0 | grep rx_queue_6 rx_queue_6_packets: 332723161 rx_queue_6_bytes: 80117611254 rx_queue_6_drops: 1002943 совпадает с overruns:1002943 rx_queue_6_csum_err: 0 rx_queue_6_alloc_failed: 0 [root@testrouter ~]# [root@testrouter ~]# ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 256 RX Mini: 0 RX Jumbo: 0 TX: 256 [root@testrouter ~]# [root@testrouter ~]# ethtool -c eth0 Coalesce parameters for eth0: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 3 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 Нагрузка ядер по top во время тестов показывала нагрузку на SI 0,3-0,7% процы были совсем не нагружены. При нагрузке в 300к PPS на каждое ядро высыпалось по 700-800 прерываний в секунду т.е. 6000 (Но мог и ошибиться, по доке драйвер по умолчанию генерит 8000) прерываний при 300к PPS. Чем лечить? Изменено 14 июня, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 15 июня, 2012 · Жалоба Драйвер по умолчанию который шел с ядром Соберите дрова с http://sourceforge.net/projects/e1000/files/igb%20stable/3.4.7/ потом поговорим))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 16 июня, 2012 (изменено) · Жалоба ок, установил модуль [root@testrouter src]# modinfo igb | grep -E "version|parm" version: 3.4.7 srcversion: 84D0F70C7DF9FC65710D5E8 vermagic: 2.6.32-220.7.1.el6.alex.rps.2.x86_64 SMP mod_unload modversions parm: InterruptThrottleRate:Maximum interrupts per second, per vector, (max 100000), default 3=adaptive (array of int) parm: IntMode:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-X), default 2 (array of int) parm: Node:set the starting node to allocate memory on, default -1 (array of int) parm: LLIPort:Low Latency Interrupt TCP Port (0-65535), default 0=off (array of int) parm: LLIPush:Low Latency Interrupt on TCP Push flag (0,1), default 0=off (array of int) parm: LLISize:Low Latency Interrupt on Packet Size (0-1500), default 0=off (array of int) parm: RSS:Number of Receive-Side Scaling Descriptor Queues (0-8), default 1=number of cpus (array of int) parm: VMDQ:Number of Virtual Machine Device Queues: 0-1 = disable, 2-8 enable, default 0 (array of int) parm: max_vfs:Number of Virtual Functions: 0 = disable, 1-7 enable, default 0 (array of int) parm: MDD:Malicious Driver Detection (0/1), default 1 = enabled. Only available when max_vfs is greater than 0 (array of int) parm: QueuePairs:Enable TX/RX queue pairs for interrupt handling (0,1), default 1=on (array of int) parm: EEE:Enable/disable on parts that support the feature (array of int) parm: DMAC:Disable or set latency for DMA Coalescing ((0=off, 1000-10000(msec), 250, 500 (usec)) (array of int) parm: LRO:Large Receive Offload (0,1), default 0=off (array of int) parm: debug:Debug level (0=none, ..., 16=all) (int) [root@testrouter src]# гружу с одним параметром modprobe igb RSS=8,8 сдвоенных очередей на каждый интерфейс получилось по 8 overruns ошибки исчезли. Проблема с тем что драйвер разгребает пакеты одной очередью остается тестирую программой iperf сервер клиент включен в интерфейс eth0 тестируемого сервера iperf -c 192.168.20.1 -i 5 --format k -u -l64 -b6200k -p 5002 -P 40 -t 1800 сервер - сервер включен в интерфейс eth1 тестируемого сервера iperf -B 192.168.20.1 -u -s -i5 -p 5002 при этом на eth0 тестируемого сервера влетает 483к пакетов в секунду далее идут непонятные мне цифры очередь (через которую пакеты прилетают) eth0-TxRx-6 генерит на каждое ядро 130/1с прерываний, а очередь (через которую пакеты улетают) eth1-TxRx-3 2200/1с на каждое ядро. На отправку прерываний больше почему то чем на прием!!! top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13 root 20 0 0 0 0 R 12.3 0.0 3:49.33 ksoftirqd/2 21 root 20 0 0 0 0 S 3.7 0.0 0:43.14 ksoftirqd/4 25 root 20 0 0 0 0 S 3.7 0.0 1:15.39 ksoftirqd/5 29 root 20 0 0 0 0 S 3.3 0.0 1:26.70 ksoftirqd/6 33 root 20 0 0 0 0 S 3.0 0.0 0:57.72 ksoftirqd/7 17 root 20 0 0 0 0 S 2.7 0.0 2:37.13 ksoftirqd/3 9 root 20 0 0 0 0 S 1.7 0.0 1:13.25 ksoftirqd/1 4 root 20 0 0 0 0 S 0.3 0.0 0:53.82 ksoftirqd/0 стоит увеличить полосу с -b6200k до -b6500k как в топе залипает 100% загрузка одного ядра, т.е. 483к PPS предел для 8 ядерной системы с супер интеловыми сетевухами ((( это с модулем ipt_NETFLOW но без FV единственный положительный момент как уже писал - на интерфейсах отсутствуют какие либо ошибки че делать то? и еще заметил в отчете iperf много вот таких пакетов 49011 datagrams received out-of-order [ 31] Server Report: [ 31] 0.0-1344.0 sec 1012975 KBytes 6174 Kbits/sec 0.062 ms 96974/16304569 (0.59%) [ 31] 0.0-1344.0 sec 49011 datagrams received out-of-order выгрузил ipt_NETFLOW система стала прокачивать 575к PPS количество прерываний не увеличилось где то 20000/сек если добавить еще пакетов опять вылезает ksoftirqd perf top 701.00 6.8% _spin_lock /usr/lib/debug/lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/vmlinux 605.00 5.9% __alloc_skb /usr/lib/debug/lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/vmlinux 568.00 5.5% igb_poll /lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/kernel/drivers/net/igb/igb.ko 529.00 5.1% igb_xmit_frame_ring /lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/kernel/drivers/net/igb/igb.ko 417.00 4.0% igb_tx_ctxtdesc /lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/kernel/drivers/net/igb/igb.ko 342.00 3.3% ipt_do_table /lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/kernel/net/ipv4/netfilter/ip_tables.ko и при 575к PPS как то стали только 4 ядра процессоров выделяться по загрузке Изменено 17 июня, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
purecopper Опубликовано 23 октября, 2012 (изменено) · Жалоба Помогите пожалуйста с ситуацией: Linux-маршрутизатор, на котором терминируются пользовательские vlan`ы (порядка 1000 штук), настроен шейпер исходящего от пользователя трафика. Проблема в следующем - в топе постоянно [k] read_hpet и [k] acpi_idle_enter_simple, что, кмк, не совсем правильно. uname -a: Linux 2.6.34-gentoo-r6 #1 SMP Fri Oct 19 20:33:29 MSK 2012 x86_64 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz stepping : 10 cpu MHz : 1994.834 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority bogomips : 3989.66 clflush size : 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz stepping : 10 cpu MHz : 1994.834 cache size : 6144 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority bogomips : 3990.04 clflush size : 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz stepping : 10 cpu MHz : 1994.834 cache size : 6144 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority bogomips : 3990.05 clflush size : 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz stepping : 10 cpu MHz : 1994.834 cache size : 6144 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority bogomips : 3990.00 clflush size : 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: perf-top: PerfTop: 3212 irqs/sec kernel:99.5% exact: 0.0% [1000Hz cycles], (all, 4 CPUs) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- 26.34% [kernel] [k] read_hpet 18.65% [processor] [k] acpi_idle_enter_simple 4.98% [kernel] [k] _raw_spin_lock_irqsave 2.29% [igb] [k] igb_poll 2.29% [ip_tables] [k] ipt_do_table 1.80% [kernel] [k] skb_copy_bits 1.74% [kernel] [k] _raw_spin_lock 1.11% [kernel] [k] tick_broadcast_oneshot_control 1.04% [kernel] [k] pskb_expand_head 0.96% [cls_u32] [k] u32_classify 0.86% [kernel] [k] _raw_spin_unlock_irqrestore 0.84% [kernel] [k] nf_iterate 0.82% [kernel] [k] netif_receive_skb 0.75% [kernel] [k] native_sched_clock 0.70% [kernel] [k] kfree 0.63% [kernel] [k] dev_queue_xmit 0.63% [kernel] [k] skb_release_data 0.63% [kernel] [k] dev_hard_start_xmit 0.61% [kernel] [k] sk_run_filter 0.61% [processor] [k] acpi_idle_enter_c1 0.59% [kernel] [k] sched_clock_local 0.55% [kernel] [k] csum_partial 0.51% [igb] [k] igb_xmit_frame_ring 0.50% [kernel] [k] menu_select 0.49% [kernel] [k] __copy_skb_header 0.49% [kernel] [k] skb_release_head_state 0.49% [kernel] [k] ip_route_input 0.46% [kernel] [k] __alloc_skb 0.46% [kernel] [k] hpet_next_event 0.45% [kernel] [k] ktime_get 0.45% [nf_conntrack] [k] __nf_conntrack_find 0.40% [kernel] [k] local_bh_enable 0.39% [kernel] [k] _raw_spin_lock_bh 0.39% [sch_htb] [k] htb_dequeue 0.39% [nf_conntrack] [k] nf_conntrack_find_get 0.38% [kernel] [k] ip_rcv 0.38% [kernel] [k] irq_entries_start 0.38% [unknown] [.] 0x00007f9e2db243b6 0.37% [kernel] [k] kmem_cache_alloc 0.37% [nf_conntrack] [k] 0x00000000000000a1 Изменено 23 октября, 2012 пользователем purecopper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 24 октября, 2012 · Жалоба Укажите/смените clocksourse на tsc в параметрах загрузки ядра kernel /boot/vmlinuz root=/dev/sda2 ro clocksource=tsc Перезагрузитесь и убедитесь, что изменение имеет место быть $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 12 декабря, 2012 (изменено) · Жалоба Коллеги, поставил машину самосбор под софтроутер на серверной маме Supermicro (чипсет Intel C202) + 4-ядерный процессор Intel i5 (без гипертрединга). # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz stepping : 9 microcode : 0x12 cpu MHz : 3399.965 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 6799.93 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Операционная система Генту 64 разряда - 3.5.7-gentoo #9 SMP Wed Dec 12 01:11:12 MSK 2012 x86_64 Intel® Core i5-3570K CPU @ 3.40GHz GenuineIntel GNU/Linux После пары часов работы в dmesg появляется Clocksource tsc unstable (delta = 299966086829 ns) Switching to clocksource hpet и нагрузка на процессор возрастает в два раза. Что, понятно, не приемлемо. С чем может быть связано такое поведение оперсистемы? Стоит ли отказаться от ACPI для решения вопроса? Может, какие-то опции ядра поправить? Что еще можно предпринять? TSC нужен как воздух. Сервер делает NAT, немного шейпит + поднят BGP. Изменено 12 декабря, 2012 пользователем Justas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 12 декабря, 2012 · Жалоба Justas, Вот такое нашёл: The TSC is supposed to tick at the CPU rate (unless it's a constant_tsc, see /proc/cpuinfo flags, so on frequency change, this ought to happen. The kernel will automatically switch to something else. Попробуйте Turbo Boost отключить. Насчет нагрузки процессора после переключения clocksource: Попробуйте после переключения clocksource сделать ntpdate, помогает? Ну и ntpd, естественно, должен быть запущен. А вообще, чем HPET плох? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 12 декабря, 2012 · Жалоба А вообще, чем HPET плох? Для таймстампинга пакетов - тем, что время доступа к абсолютному показателю HPET по меркам машины достаточно приличное. Именно поэтому read_hpet и вываливается в топ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 12 декабря, 2012 · Жалоба Попробуйте Turbo Boost отключить. А вообще, чем HPET плох? TurboBoost в биосе отключил - не помогает. hpet медленнее tsc, намного медленнее. Тут в аналогичной теме http://forum.nag.ru/forum/index.php?showtopic=38982&st=80&p=370335entry370335 товарищи писали. ntpd запущен, часы исправно синхронизируются и еще клиентов даже обслуживают - уровень ntp-сервера стратум 2. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 12 декабря, 2012 · Жалоба Вдогонку график загрузки процессора. До 01:00 - hpet. С 02:15 до 08:20 - tsc. Видно, что около 08:20 нагрузка возрастает в 2 раза. Это момент смены оперсистемой clocksource с tsc на hpet. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...