nuclearcat Опубликовано 29 марта, 2013 · Жалоба По моему опыту - да. Сервера жуют траффик хуже, чем на интелевских сетевках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 29 марта, 2013 (изменено) · Жалоба По моему опыту - да. Сервера жуют траффик хуже, чем на интелевских сетевках. Да рад бы интелами жевать, только HP в свои лезвия воткнул встроенные бродкомы, так что имеем, что имеем - два бродкома и четыре интела, исторически с не самыми лучшими под задачу чипами. :( Изменено 29 марта, 2013 пользователем heap Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 29 марта, 2013 · Жалоба только HP в свои лезвия воткнул встроенные бродкомы, так что имеем, что имеем - два бродкома и четыре интела, исторически с не самыми лучшими под задачу чипами. :( Вот за что так не люблю HP (местами просто ненавижу), так за подобные выкрутасы. Вообще лезвия для перемалывания трафика дело дорогое и неблагодарное (хотя это может быть только мое мнение). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 29 марта, 2013 · Жалоба Вот за что так не люблю HP (местами просто ненавижу), так за подобные выкрутасы. Вообще лезвия для перемалывания трафика дело дорогое и неблагодарное (хотя это может быть только мое мнение). Солидарен. Но есть исторический момент - так уж сложилось. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RaD Опубликовано 3 апреля, 2013 · Жалоба Кто сталкивался с проблемой таймера Hpet на процессорах intel E5405 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel® Xeon® CPU E5405 at /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm На данный момент perf top показывает 28,17% [kernel] [k] read_hpet Хочу перейти на TSC, реально ? clocksource=tsc не помогает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 3 апреля, 2013 · Жалоба отключите всякие энергосбережения. в т.ч. в BIOS, и cpufrequtils (там часто ondemand ставят) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaktak Опубликовано 11 апреля, 2013 (изменено) · Жалоба Читал про сетевые Intel. Пытаюсь собрать все в кучу... Очень прошу поправить меня, если я ошибаюсь! Итак: 1) Современные чипы поддерживают Multiple Queues 2) Чтобы определить в какую очередь помещать тот или иной пакет используется механизм RSS (вычисление hash на основе хэдеров пакета) 3) Чтобы обрабатывать каждую очередь независимо используется механизм MSI-X (в чем отличие от MSI?),который создаёт векторы прерываний (по сути номера прерываний?) по кол-ву процессоров в системе. 4) Прерывания необходимо вручную привязать к определенным процессорам, используя механизм smp_affinity, либо сделать это автоматически используя RPS (вычисление hash). 5) Контроль кол-ва прерываний осуществляется параметром драйвера - interruptthrottlerate. Если сетевая карта не поддерживает отложенные прерывания, необходимо использовать поллинг (NAPI в Linux) UPD: переосмыслил пункт 2: 2) PCI имеет 4 пина на всю шину для передачи прерываний. Механизм MSI-X позволяет передавать сообщения о прерывания в потоке данных, что позволяет использовать до 64-ех прерываний на устройство и как следствие эффективно использовать имеющиеся очереди пакетов. ну и некоторые вопросы, на которые я не нашел ответов: 1) Как узнать с какими параметрами сейчас загружен драйвер (e1000e), если дополнительных options в modprobe.conf описано не было? 2) Как узнать, что используется - NAPI или отложенные прерывания? 3) Можно ли задать в параметрах драйвера кол-во прерываний? 4) У меня 2 карты 82571EB (двух-головые) и 4 ядра. В системе по одному прерыванию на порт карты. Если бы у меня было 8 ядер, автоматически создалось бы 8 прерываний по 2 на порт? Изменено 11 апреля, 2013 пользователем kaktak Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 11 апреля, 2013 · Жалоба kaktak Есть одно НО. Ваш 82571EB не имеет отношения к современным чипам :) Никаких очередей там нет, остальные мысли смысла не имеют. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaktak Опубликовано 11 апреля, 2013 · Жалоба Есть одно НО. Ваш 82571EB не имеет отношения к современным чипам :) Никаких очередей там нет, остальные мысли смысла не имеют. по чипу понятно ) ну даже если очередей нет, NAPI и smp_affinity имеют смысл ) по остальным мыслям все же прокомментируйте, верно ли понимаю общую ситуацию? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 11 апреля, 2013 · Жалоба Как узнать с какими параметрами сейчас загружен драйвер (e1000e), если дополнительных options в modprobe.conf описано не было? С дефолтными. Читайте мануал к драйверу. Можно ли задать в параметрах драйвера кол-во прерываний? Можно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
powerthrash Опубликовано 12 апреля, 2013 · Жалоба Актуально ли использование TSO и других offload-ов на последней версии igb, для iSCSI траффика ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 апреля, 2013 (изменено) · Жалоба Актуально ли использование TSO и других offload-ов на последней версии igb, для iSCSI траффика ? Это актуально только для транзитного трафика, на который надо накладывать шейперы и/или полисеры. Данная опция требует выключения на машинах, которые обрабатывают pptp-туннели и шейпят их, а также на других подобных серверах. Некоторые алгоритмы лимитирования полосы пропускания просто глючат с разными offload и скорость нарезается как придется, а не как надо. Для приземления трафика на конкретной машине и/или простого форварда разницы не увидите. Изменено 13 апреля, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaktak Опубликовано 17 апреля, 2013 · Жалоба Если отключить irqbalance, раскидать прерывания сетевых вручную по ядрам, то каким ядром будет отрабатываться шейпер и iptables? Всегда 0-ым или как то по другому? Можно ли на это повлиять? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 17 апреля, 2013 · Жалоба Актуально ли использование TSO и других offload-ов на последней версии igb, для iSCSI траффика ? Это актуально только для транзитного трафика, на который надо накладывать шейперы и/или полисеры. с фига ли? шейперы/полисеры работают per packet. Для приземления трафика на конкретной машине и/или простого форварда разницы не увидите. если эта машина передает данные по tcp, то включение tso желательно. The driver will then receive super-sized skb's. These are indicated to the driver by skb_shinfo(skb)->gso_size being non-zero. The gso_size is the size the hardware should fragment the TCP data. TSO may change how and when TCP decides to send data. http://www.linuxfoundation.org/collaborate/workgroups/networking/tso т.е. не ядро будет заниматься фрагментацией, а сама nic. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Safronov Опубликовано 12 мая, 2013 · Жалоба В продолжение моей ситуации pps дорос до ~200к (по 100к на вход и на выход). la вырос до 4-5. perf top выводит в топ _spin_lock. сделал perf record/perf report. Выглядит так: Что можно сделать? Насколько нынче устаревшие для таких задач процессоры Xeon E5606. Имеет ли смысл ставить что-то "более лучшее"? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 12 мая, 2013 · Жалоба И по прежнему CentOS? Какое там хоть ядро? Имхо эта система мало куда годиться, ее даже в онлайн стремно ставить с ее тормознутостью по критическим апдейтам. Не говоря о самой политике использования архаичных ядер, которая годится только для баз данных, но очень плоха для роутеров. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
j@x Опубликовано 13 мая, 2013 · Жалоба Хотел спросить, как у вас нагрузка с новыми ядрами ? У нас на пограничных роутерах, после перехода на 3.9 нагрузка на cpu в 25% до 3% упала. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 13 мая, 2013 (изменено) · Жалоба И по прежнему CentOS? Какое там хоть ядро? Имхо эта система мало куда годиться, ее даже в онлайн стремно ставить с ее тормознутостью по критическим апдейтам. Не говоря о самой политике использования архаичных ядер, которая годится только для баз данных, но очень плоха для роутеров. ELRepo - вполне полноценнный выход из данной ситуации. Счас например там есть ядро 3.9.2 Изменено 13 мая, 2013 пользователем BETEPAH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 13 мая, 2013 · Жалоба Хотел спросить, как у вас нагрузка с новыми ядрами ? У нас на пограничных роутерах, после перехода на 3.9 нагрузка на cpu в 25% до 3% упала. Какие сетевухи у Вас стоят? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 мая, 2013 · Жалоба У нас на пограничных роутерах, после перехода на 3.9 нагрузка на cpu в 25% до 3% упала. Скорее интересует не само 3.9.х ядро, а с какого именно на него перешли? Не думаю что при переходе с 3.2.44 или 3.4.45 будет подобный прирост и будет ли вообще. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
j@x Опубликовано 13 мая, 2013 · Жалоба Хотел спросить, как у вас нагрузка с новыми ядрами ? У нас на пограничных роутерах, после перехода на 3.9 нагрузка на cpu в 25% до 3% упала. Какие сетевухи у Вас стоят? Intel 82571EB Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
j@x Опубликовано 13 мая, 2013 · Жалоба У нас на пограничных роутерах, после перехода на 3.9 нагрузка на cpu в 25% до 3% упала. Скорее интересует не само 3.9.х ядро, а с какого именно на него перешли? Не думаю что при переходе с 3.2.44 или 3.4.45 будет подобный прирост и будет ли вообще. Таки важное замечание. С debian 3.2.0-4 на ванильное 3.9.0 перескочили, думаю это из-за route cache. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 13 мая, 2013 · Жалоба С debian 3.2.0-4 на ванильное 3.9.0 перескочили, думаю это из-за route cache. поясните, в 3.2.0 есть проблемы с route cache? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
j@x Опубликовано 13 мая, 2013 · Жалоба С debian 3.2.0-4 на ванильное 3.9.0 перескочили, думаю это из-за route cache. поясните, в 3.2.0 есть проблемы с route cache? не думаю что с ним проблемы, просто в 3.2 он есть, а после 3.6 нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
anito23 Опубликовано 28 июня, 2013 (изменено) · Жалоба Доброй ночи!!!! Есть проблемка с софт роутером. Сегодня провели следующее тестирование Стенд При тестировании использовались Dell роутер: Server: Dell PowerEdge R720 Motherboard: 0C4Y3R CPU: 1 * Intel(R) Xeon(R) CPU E5-2620 2.00GHz RAM: 64Gb 1333 MHz Disk: RAID1 SAS 100Гб. Network interface: Intel Ethernet X540 DP 10Gb BT + I350 1Gb BT DP Network Daughter Card тестовый сервер Motherboard: Intel® DB65AL CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz RAM: 8Gb 1333 MHz Disk: SSD 120Гб. Network interface: Intel Ethernet I350 DP 1Gb Server Adapter На обоих серверах установлена одна и таже чистая (только установленная) версия ОС Debian 6 и драйверов igb 4.3.0. # uname -a Linux Debian-60-squeeze-64-minimal 2.6.32-5-amd64 #1 SMP Sat May 5 01:12:59 UTC 2012 x86_64 GNU/Linux # modinfo igb | grep "^version" version: 4.3.0 # uname -a Linux rescue 2.6.32-5-amd64 #1 SMP Mon Feb 25 00:26:11 UTC 2013 x86_64 GNU/Linux # modinfo igb | grep "^version" version: 4.3.0 Сервера между собой объединены кроссовым патч-кордом. До начала тестирования на обоих машинах был загружен драйвер igb с параметрами и разбросаны очереди по ядрам следующим скриптом: #!/bin/bash rmmod igb modprobe igb InterruptThrottleRate=1,1 IntMode=2,2 RSS=6,6 QueuePairs=1,1 LRO=1,1 DMAC=0,0 /etc/init.d/networking restart /usr/bin/irq_balance_manually.sh # скрипт разброса очередей по ядрам http://habrahabr.ru/post/108240/ Тестирование Часть первая Тестируем пропускную способность Dell сервера: Запустили скрипт генерации пакетов на тестовом сервере: # vi /root/pkgeneth.sh #!/bin/bash modprobe pktgen # модуль ядра для генерации пакетов echo "rem_device_all" > /proc/net/pktgen/kpktgend_0 echo "add_device eth2" > /proc/net/pktgen/kpktgend_0 echo "max_before_softirq 10000" > /proc/net/pktgen/kpktgend_0 echo "count 0" > /proc/net/pktgen/eth2 echo "dst 10.55.0.50" > /proc/net/pktgen/eth2 # IP адрес DEll роутера echo "dst_mac bc:30:5b:f7:01:94" > /proc/net/pktgen/eth2 # MAC DELL роутера echo "pkt_size 60" > /proc/net/pktgen/eth2 echo "delay 0" > /proc/net/pktgen/eth2 echo "start" > /proc/net/pktgen/pgctrl Снимаем статистику по пакетам на тестовом сервере # vnstat -tr -i eth2 6293257 packets sampled in 5 seconds Traffic average for eth2 rx 65.56 Mbit/s 139851 packets/s tx 524.44 Mbit/s 1118800 packets/s Снимаем статистику по пакетам на Dell роутере # vnstat -tr -i eth2 5590469 packets sampled in 5 seconds Traffic average for eth2 rx 524.11 Mbit/s 1118092 packets/s tx 0.00 kbit/s 1 packets/s в это время нагрузка на Dell сервере # mpstat -P ALL 1 Linux 2.6.32-5-amd64 (Debian-60-squeeze-64-minimal) 06/27/2013 _x86_64_ (6 CPU) 11:34:24 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 11:34:25 PM all 0.00 0.00 0.17 0.00 0.00 17.04 0.00 0.00 82.79 11:34:25 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 11:34:25 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 11:34:25 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 11:34:25 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 11:34:25 PM 4 0.00 0.00 0.00 0.00 0.00 100.00 0.00 0.00 0.00 11:34:25 PM 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 Одно 4 ядро на Dell сервере постоянно занято на 100%. При этом в perf top следующее ------------------------------------------------------------------------------ PerfTop: 24534 irqs/sec kernel:99.7% [100000 cycles], (all, 6 CPUs) ------------------------------------------------------------------------------ samples pcnt kernel function _______ _____ _______________ 12224.00 - 5.7% : igb_poll [igb] 10130.00 - 4.7% : __alloc_skb 9424.00 - 4.4% : __inet_dev_addr_type 9375.00 - 4.4% : __ip_route_output_key 8866.00 - 4.1% : _local_bh_enable_ip 8732.00 - 4.1% : dst_release 8366.00 - 3.9% : icmp_send 6895.00 - 3.2% : fn_hash_lookup 6283.00 - 2.9% : netif_receive_skb 5856.00 - 2.7% : rt_hash 5325.00 - 2.5% : _read_lock 5218.00 - 2.4% : _decode_session4 5155.00 - 2.4% : ip_rcv 5082.00 - 2.4% : ip_route_input 4918.00 - 2.3% : kfree Очереди от двух сетевых равно мерно разбросаны по ядрам # cat /proc/interrupts | grep eth 68: 1 0 0 0 0 0 PCI-MSI-edge eth2 69: 2 0 0 0 0 45235878 PCI-MSI-edge eth2-TxRx-0 71: 2 0 0 0 11390253 0 PCI-MSI-edge eth2-TxRx-1 72: 2 0 0 1485 0 0 PCI-MSI-edge eth2-TxRx-2 101: 2 0 1485 0 0 0 PCI-MSI-edge eth2-TxRx-3 102: 2 1485 0 0 0 0 PCI-MSI-edge eth2-TxRx-4 103: 1493 0 0 0 0 0 PCI-MSI-edge eth2-TxRx-5 104: 1 0 0 0 0 0 PCI-MSI-edge eth3 105: 2 0 0 0 0 3182 PCI-MSI-edge eth3-TxRx-0 106: 2 0 0 0 1490 0 PCI-MSI-edge eth3-TxRx-1 107: 2 0 0 3155 0 0 PCI-MSI-edge eth3-TxRx-2 108: 2 0 1521 0 0 0 PCI-MSI-edge eth3-TxRx-3 109: 2 1492 0 0 0 0 PCI-MSI-edge eth3-TxRx-4 110: 1492 0 0 0 0 0 PCI-MSI-edge eth3-TxRx-5 На обоих серверах потерь пакетов нет. Часть вторая Тестируем пропускную способность тестового сервера: Запустим скрипт генерации пакетов на Dell сервере: # vi /root/pkgeneth.sh #!/bin/bash modprobe pktgen echo "rem_device_all" > /proc/net/pktgen/kpktgend_0 echo "add_device eth2" > /proc/net/pktgen/kpktgend_0 echo "max_before_softirq 10000" > /proc/net/pktgen/kpktgend_0 echo "count 0" > /proc/net/pktgen/eth2 echo "dst 10.55.0.10" > /proc/net/pktgen/eth2 echo "dst_mac a0:36:9f:10:86:60" > /proc/net/pktgen/eth2 echo "pkt_size 60" > /proc/net/pktgen/eth2 echo "delay 0" > /proc/net/pktgen/eth2 echo "start" > /proc/net/pktgen/pgctrl Снимаем статистику по пакетам на Dell роутере # vnstat -tr -i eth2 7441550 packets sampled in 5 seconds Traffic average for eth2 rx 0.00 kbit/s 1 packets/s tx 697.64 Mbit/s 1488309 packets/s Из приведенной статистике по Dell серверу видно, что генерируется максимальное количество пакетов для гигабитной сети. Снимаем статистику по пакетам на тестовом сервере # vnstat -tr -i eth2 7441342 packets sampled in 5 seconds Traffic average for eth2 rx 697.63 Mbit/s 1488267 packets/s tx 0.00 kbit/s 1 packets/s в это время нагрузка на тестовом сервере # mpstat -P ALL 1 Linux 2.6.32-5-amd64 (rescue.fastvps.ee) 06/27/2013 _x86_64_ (8 CPU) 12:01:22 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 12:01:23 AM all 0.00 0.00 0.00 0.00 0.00 0.50 0.00 0.00 99.50 12:01:23 AM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 12:01:23 AM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 12:01:23 AM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 12:01:23 AM 3 0.00 0.00 0.00 0.00 0.00 4.00 0.00 0.00 96.00 12:01:23 AM 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 12:01:23 AM 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 12:01:23 AM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 12:01:23 AM 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 При этом в perf top следующее ------------------------------------------------------------------------------ PerfTop: 23509 irqs/sec kernel:97.8% [100000 cycles], (all, 8 CPUs) ------------------------------------------------------------------------------ samples pcnt kernel function _______ _____ _______________ 32187.00 - 8.3% : igb_poll [igb] 16488.00 - 4.2% : __alloc_skb 14518.00 - 3.7% : __ip_route_output_key 13833.00 - 3.6% : __inet_dev_addr_type 13515.00 - 3.5% : icmp_send 13168.00 - 3.4% : _local_bh_enable_ip 12219.00 - 3.1% : dst_release 11509.00 - 3.0% : netif_receive_skb 10785.00 - 2.8% : ip_route_input 9865.00 - 2.5% : rt_hash 9300.00 - 2.4% : fn_hash_lookup 8375.00 - 2.2% : _decode_session4 8312.00 - 2.1% : ip_rcv 7992.00 - 2.1% : __kmalloc_node_track_caller 7896.00 - 2.0% : memcpy_c Очереди от двух сетевых равно мерно разбросаны по ядрам # cat /proc/interrupts | grep eth 26: 6096 0 0 0 0 0 0 0 PCI-MSI-edge eth0 27: 1 0 0 0 0 0 0 0 PCI-MSI-edge eth2 28: 2 0 0 0 0 0 0 114 PCI-MSI-edge eth2-TxRx-0 29: 2 0 0 0 0 0 293 0 PCI-MSI-edge eth2-TxRx-1 30: 2 0 0 0 0 106 0 0 PCI-MSI-edge eth2-TxRx-2 34: 2 0 0 0 106 0 0 0 PCI-MSI-edge eth2-TxRx-3 35: 2 0 0 6665681 0 0 0 0 PCI-MSI-edge eth2-TxRx-4 36: 2 0 106 0 0 0 0 0 PCI-MSI-edge eth2-TxRx-5 На обоих серверах, так же, потерь пакетов нет Вывод Десктопная материнка с Intel Core i7 без проблем вытягивает максимальное количество пакетов пришедших на сетевой интерфейс, а серверная платформа и процессор вытягивает меньшее количество пакетов. Данное тестирование было проведено по причине того, что при тестировании Dell сервера в качестве только маршрутизатора (то есть чистая ОС + net.ipv4.ip_forward=1 в sysctl.conf) он держал 1.10Млн 64 байтных пакетов при включенном форвардинге, а далее все упиралось в 100% на одном ядре (как и в данном тесте) и _spin_lock в perf top. Подскажите, пожалуйста, куда копать и что смотреть. Сервер такой конфигурации должен справляться с более чем 1Млн 64 байтных пакетов без значительного повышения нагрузки. Изменено 28 июня, 2013 пользователем anito23 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
