muchacho Опубликовано 19 декабря, 2011 · Жалоба Тогда берите ядро 3.1. Ребята в соседних темах пишут, что там всё ок. Таймауты порежте. Особенно те которые на ожидания пакетов на разрыв - макс 30 сек. Timeout established - поставьте меньше. Но я думаю, что максимальный еффект будет именно от смены ядра. 2.6.32 имеет пачку проблем именно с производительностью и стабильностью. Не знаю как сейчас, но раньше с него стремительно бежали. Профайлер тоже тыкает пальцем на функцию ядра. И обратите внимание на классификатор u32 в профайлере. Он не должен быть на 3ем месте если фильтры построены на хешах. Спасибо большое, попробую. Может попробовать ужать цепочку mailusers до 3 правил? Как-то: ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set mail_dst dst ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 match-set mail_src src DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Я могу попробовать вобще убрать эти правила, но имеет ли смысл? 271K 62M mailusers tcp -- bond1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 сматчилось всего 270к пакетов за 3 дня, думаю погоды это не сделает. RETURN в mailusers лечше сменить на ACCEPT, в противном случае получается +1 правило при прохождении пакета. Еще как вариент переделать цепочку FORWARD так, чтобы самые массовые пакеты проходили проверку максимум в одном правиле, а не обходили, как сейчас, 4 правила (3 явно заданых + дефолтный). А то у вас ради выявления несчастных 2.3 млн. пакетов впстую по всем правилам гоняется 23 млрд. пакетов. А как тут переделать? Я итак оставил самое нужное и если что-то переделывать, то получу только лишние правила. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 19 декабря, 2011 · Жалоба Первое что бросается в глаза, это явно прописать ACCEPT для пакетов, пришедших с bond0, я не вижу правил, фильтрующих входящий трафик. Не совсем понимаю смысл в 2162K 238M DROP all -- bond1 * 0.0.0.0/0 192.168.0.0/16 у вас за NAT'ом есть сети 192.168/16 за NAT'ом? Может лучше этот момент обойти через "ip route 192.168.0.0/16 Null0 255" (кусок конфига квагги) Теперь по третьему оставшемуся (точнее уже второму), пропишем ACCEPT для пакетов, которые не ломятся на 25-й порт. Промежуточный результат: 1 правило - пропускаются все пакеты из интернета (львиная доля трафика) 2 правило - пропускаются исходящие пакеты, которые не на 25-й порт (бОшльшая честь пакетов, оставшихся после 1-го правила) 3 и 4 правилом можно задать обработку ситуации с 25-м портом. И в policy ACCEPT должны будут упасть пакеты, которые ранее отлавливались по прежнему первому правилу. Ничего не упустил, дырок в логике нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 20 декабря, 2011 · Жалоба В продолжении предыдущего поста по сокращению цепочек правил. Я совершенно упустил из виду цепочки в таблице nat. А у нас тут вообще красота. Цепочка POSTROUTING, все пакеты, уходящие в локальную сеть через bond1 у нас пробегают по всем 62 правилам (61 явные + 1 дефолтное). Там стоит правило с фильтрацией по 192.168.1.0/24, но его явно недостаточно. Есть еще возможность "ужать" правила для SNAT, но там еще придется играться с порядком расположения, чтобы правила для отдельных адресов срабатывали раньше общих правил для подсетей. Тогда можно будет всех загнать в ipset'ы типа nethash и все расположить в одной линейной последовательности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 20 декабря, 2011 (изменено) · Жалоба Всё хорошо, вот только обработка правил в таблице NAT делается не per packet, а per flow. Поэтому запихните туда хоть 10К правил - ничего не изменится, если количество новых потоков не будет очень большим ( дестки и сотни тысяч в секунду ). По поводу оптимизации iptables - это всё мимо кассы. Профайлер про iptables вообще ничего не говорит, поэтому оптимизировать можно всегда, но в данной ситуации - это будет потраченное время, т.к. проблемы не решит. Изменено 20 декабря, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
muchacho Опубликовано 20 декабря, 2011 · Жалоба Разобрался с большим кол-вом перрываний. Запущеный perf top и oprofile даёт такой эффект. Попробовал посмотреть oprofile, вот что получилось: root@router:/usr/lib/debug/boot# opreport Overflow stats not available CPU: Core 2, speed 2494.2 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000 CPU_CLK_UNHALT...| samples| %| ------------------ 3688718 71.8508 vmlinux-2.6.32-5-686-bigmem 383939 7.4786 igb 284001 5.5319 nf_conntrack 231999 4.5190 cls_u32 187539 3.6530 sch_htb 72640 1.4149 ip_tables 46089 0.8977 nf_nat 41489 0.8081 bonding 41002 0.7987 ifb 33392 0.6504 ip_set_nethash 23144 0.4508 oprofiled root@router:/usr/lib/debug/boot# opreport -l vmlinux-2.6.32-5-686-bigmem CPU: Core 2, speed 2494.2 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000 samples % symbol name 381248 10.3355 dev_queue_xmit 330145 8.9501 skb_copy_bits 243404 6.5986 __slab_alloc 164481 4.4590 sch_direct_xmit 143361 3.8865 mwait_idle 133106 3.6085 __slab_free 129585 3.5130 ip_route_input 110956 3.0080 pskb_expand_head 102707 2.7844 __copy_skb_header 92208 2.4997 netif_receive_skb 86645 2.3489 __alloc_skb 83237 2.2565 skb_release_head_state 74389 2.0167 skb_release_data 71011 1.9251 add_partial 68307 1.8518 kmem_cache_free 62780 1.7019 kmem_cache_alloc 57310 1.5537 ip_rcv 49509 1.3422 dev_get_by_index 43471 1.1785 kfree 43301 1.1739 nf_iterate 39861 1.0806 ktime_get 38992 1.0571 __kmalloc_track_caller Может это чем-то поможет. По поводу iptables - сегодня попробую совсем убрать правила из filter, если что-то изменится отпишусь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 12 января, 2012 (изменено) · Жалоба muchacho - попробуйте для начала переехать на x86-64 ядро. Судя по oprofile, есть какие-то затруднения с доступом ядра к памяти - dev_queue_xmit, skb_copy_bits, и (!!!) - __slab_alloc вылезают на первое место. Т.е. по первым двум явно что-то не клеится с memory-mapping'ом у сетевых плат, похоже. А третье - это, вероятно, наследие PAE + SMP. Сколько памяти на машине? Изменено 12 января, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 13 января, 2012 · Жалоба Смену ядра рекомендовали еще на прошлой странице. Очевидно, что на роутере виртуальные ядра должны быть отключены и не должно быть PAE. Аргументом тоже было то, что в топе профайлера только функции ядра. Человек вместо этого оптимизировал iptables. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 13 января, 2012 (изменено) · Жалоба Рекомендовать-то рекомендовали, но направление указано не то. Тут можно пока не трогать версию ядра, надо сначала именно на x86-64 перейти. Явно видно, что загибает лапки управление памятью и доступ к памяти устройств. Скорее всего, из-за x86 / PAE. Может быть, конечно, и кривое железо, но вероятность этого меньше на порядок. Изменено 13 января, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 13 января, 2012 (изменено) · Жалоба Соглашусь, про PAE и память никто ничего не говорил. Похоже таки дело в PAE, т.к. vmlinux-2.6.32-5-686-bigmem. Суфикс bigmem кагбэ намекает. Но от себя дополню: поменял бы и версию ядра сразу же заодно, раз прийдется перезагружаться. 2.6.32 все же имеет ряд проблем устраненных в более поздных ветках. Согласны? Изменено 13 января, 2012 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 13 января, 2012 · Жалоба Смотря какой 2.6.32, и чего в него напихано. В RHEL 2.6.32 - это уже далеко не 2.6.32. В данном случае имеем не RHEL, но надо смотреть предметно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zevgen Опубликовано 30 января, 2012 (изменено) · Жалоба Коллеги, подскажите карточку PCIe с очередями, для шейпера с трафиком до 1Gbit. Изменено 30 января, 2012 пользователем zevgen Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 30 января, 2012 · Жалоба Любая на i82576 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 1 февраля, 2012 · Жалоба 82575 тоже сгодится, если найдете. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 2 февраля, 2012 · Жалоба 82574 не поддерживает msi-x, зато стоит копейки (только что проверил - подешевела до 950р). The best choice for the cheap gateway, imho. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 2 февраля, 2012 · Жалоба Там же не просто гейт, а шейпер и фаервол наверное будет не в одно правило. Поэтому на гиг лучше крутить на нескольких процессорах. 4 гибридных очереди на порт с головой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
=-Sky-= Опубликовано 3 марта, 2012 · Жалоба Помогите, пожалуйста, обновил сервер с 15й до 16й Федоры, конфиги все перенес, но загрузка процессора выросла раза в полтора, появились дропы на eth0: Сетевуха Intel Pro 1000 PT Server RX packets:22928136413 errors:6 dropped:175943852 ethtool -S eth0: rx_no_buffer_count: 343343490 rx_missed_errors: 173933073 tx_restart_queue: 472902 sysctl -a | grep conntrack net.netfilter.nf_conntrack_generic_timeout = 300 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120 net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60 net.netfilter.nf_conntrack_tcp_timeout_established = 14400 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close = 10 net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300 net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300 net.netfilter.nf_conntrack_tcp_loose = 1 net.netfilter.nf_conntrack_tcp_be_liberal = 0 net.netfilter.nf_conntrack_tcp_max_retrans = 3 net.netfilter.nf_conntrack_udp_timeout = 30 net.netfilter.nf_conntrack_udp_timeout_stream = 180 net.netfilter.nf_conntrack_icmp_timeout = 30 net.netfilter.nf_conntrack_frag6_timeout = 60 net.netfilter.nf_conntrack_frag6_low_thresh = 196608 net.netfilter.nf_conntrack_frag6_high_thresh = 262144 net.netfilter.nf_conntrack_icmpv6_timeout = 30 net.netfilter.nf_conntrack_acct = 0 net.netfilter.nf_conntrack_timestamp = 0 net.netfilter.nf_conntrack_events = 1 net.netfilter.nf_conntrack_events_retry_timeout = 15 net.netfilter.nf_conntrack_max = 1548576 net.netfilter.nf_conntrack_count = 97981 net.netfilter.nf_conntrack_buckets = 1548800 net.netfilter.nf_conntrack_checksum = 1 net.netfilter.nf_conntrack_log_invalid = 0 net.netfilter.nf_conntrack_expect_max = 256 С этими параметрами игрался, ничего не помогло, стояло по умолчанию 256 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 3 марта, 2012 · Жалоба Федорка на боевом сервере? Я бы не рискнул. Что же до того, что нагрузка подросла и дропы - покажите cat /proc/sys/net/core/netdev_max_backlog cat /proc/sys/net/core/netdev_budget cat /proc/sys/net/core/dev_weight Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
=-Sky-= Опубликовано 3 марта, 2012 · Жалоба Федорка на боевом сервере? Я бы не рискнул. Что же до того, что нагрузка подросла и дропы - покажите cat /proc/sys/net/core/netdev_max_backlog cat /proc/sys/net/core/netdev_budget cat /proc/sys/net/core/dev_weight # cat /proc/sys/net/core/netdev_max_backlog 1000 # cat /proc/sys/net/core/netdev_budget 300 # cat /proc/sys/net/core/dev_weight 64 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 3 марта, 2012 · Жалоба Попробуйте, только аккуратно: echo 16 > /proc/sys/net/core/dev_weight echo 256 > /proc/sys/net/core/netdev_budget echo 16000 > /proc/sys/net/core/netdev_max_backlog Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
=-Sky-= Опубликовано 3 марта, 2012 · Жалоба Не помогло. Вот ТОП: Tasks: 206 total, 14 running, 192 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 35.6%sy, 0.0%ni, 0.3%id, 0.0%wa, 1.7%hi, 62.4%si, 0.0%st Cpu1 : 0.4%us, 13.6%sy, 0.4%ni, 7.1%id, 0.0%wa, 1.1%hi, 77.5%si, 0.0%st Cpu2 : 0.4%us, 20.7%sy, 0.0%ni, 5.8%id, 0.0%wa, 1.1%hi, 72.0%si, 0.0%st Cpu3 : 0.3%us, 12.9%sy, 0.0%ni, 5.2%id, 0.3%wa, 2.4%hi, 78.7%si, 0.0%st Cpu4 : 0.4%us, 10.7%sy, 0.4%ni, 6.2%id, 0.0%wa, 1.8%hi, 80.5%si, 0.0%st Cpu5 : 0.3%us, 10.3%sy, 4.3%ni, 5.3%id, 0.0%wa, 0.7%hi, 79.0%si, 0.0%st Mem: 3917332k total, 3539792k used, 377540k free, 127824k buffers Swap: 6160380k total, 67456k used, 6092924k free, 2264496k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3 root 20 0 0 0 0 R 25.9 0.0 371:09.69 ksoftirqd/0 15 root 20 0 0 0 0 R 17.5 0.0 293:56.76 ksoftirqd/2 27550 root 20 0 0 0 0 R 17.2 0.0 1:03.50 kworker/0:0 10 root 20 0 0 0 0 R 11.0 0.0 461:17.83 ksoftirqd/1 23 root 20 0 0 0 0 R 10.0 0.0 273:55.94 ksoftirqd/4 14862 root 20 0 0 0 0 R 9.7 0.0 0:06.57 kworker/2:1 19 root 20 0 0 0 0 S 7.1 0.0 391:13.93 ksoftirqd/3 18573 root 20 0 0 0 0 R 7.1 0.0 0:05.16 kworker/4:0 22995 root 20 0 0 0 0 R 5.8 0.0 0:35.77 kworker/1:2 25172 root 20 0 0 0 0 R 4.9 0.0 7:03.61 kworker/3:1 12711 named 20 0 619m 127m 2636 S 4.2 3.3 2:39.39 named 27 root 20 0 0 0 0 S 2.3 0.0 359:25.27 ksoftirqd/5 22164 root 20 0 590m 22m 1192 S 1.6 0.6 63:07.50 accel-pppd 24012 root 30 10 345m 10m 6712 R 1.6 0.3 0:00.05 php 23421 root 30 10 60392 10m 4500 S 1.0 0.3 0:00.21 nmap 7 root RT 0 0 0 0 S 0.6 0.0 2:49.58 watchdog/0 4559 apache 20 0 479m 15m 4976 S 0.6 0.4 0:00.35 httpd 13006 apache 20 0 480m 14m 5204 S 0.6 0.4 0:00.82 httpd 16648 root 20 0 0 0 0 S 0.6 0.0 7:21.65 kworker/3:2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 4 марта, 2012 · Жалоба Попробуйте, только аккуратно: echo 16 > /proc/sys/net/core/dev_weight echo 256 > /proc/sys/net/core/netdev_budget echo 16000 > /proc/sys/net/core/netdev_max_backlog У меня с вышеуказанных переход на эти то же не дал видимых результатов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
=-Sky-= Опубликовано 15 марта, 2012 · Жалоба Помогите, пожалуйста, обновил сервер с 15й до 16й Федоры, конфиги все перенес, но загрузка процессора выросла раза в полтора, появились дропы на eth0: Решил убиранием правил 2000 правил iptables из -t mangle (ногами не бейте, так надо было, чтоб они были). Получается, что на 15й федоре айпитейблс работало лучше... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tawer Опубликовано 20 марта, 2012 (изменено) · Жалоба доброго дня, оцените сбалансированность системы, есть подозерния что перфоманс маловат. имеем 4 x AMD Opteron Processor 6180 SE, машина чисто бордер с bgp, других задач пока нет lspci |grep Eth 03:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 03:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 04:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 04:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 41:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) (т.е. два двухпортовых 82599 и один однопортовый) uname -srmv Linux 2.6.39.4 #2 SMP Fri Dec 16 11:40:46 MSK 2011 x86_64 modinfo ixgbe |grep ver version: 3.7.17-NAPI драйвер загружаю в систему в данный момент с такими параметрами: /sbin/modprobe ixgbe RSS=12,12,12,12,12 (остальное, соответственно, по дефолту) очереди прибиты к ядрам (12 очередей каждой карты, соответственно, к 12 ядрам каждого физического процессора, работаю пока что только с двумя 10g интерфейсами) беспокоит вот что: при трафик порядка 500k pps имею достаточно высокую загрузку по ядрам, около 20% si по top. в данный момент трафик порядка 200pps, картина такая: vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 30292680 155464 1213816 0 0 0 0 1 1 0 3 97 0 0 0 0 30292696 155464 1213816 0 0 0 0 277730 70 0 21 79 0 0 0 0 30292696 155464 1213816 0 0 0 0 278285 75 0 8 92 0 0 0 0 30292696 155464 1213816 0 0 0 0 284329 89 0 8 92 0 0 0 0 30292780 155464 1213816 0 0 0 0 281916 86 0 8 92 0 0 0 0 30292780 155464 1213816 0 0 0 0 278091 99 0 8 92 0 0 0 0 30292748 155464 1213816 0 0 0 0 279591 75 0 8 92 0 0 0 0 30292748 155464 1213816 0 0 0 0 282492 71 0 12 88 0 mpstat -P ALL 5 Linux 2.6.39.4 () 20.03.2012 _x86_64_ (48 CPU) 11:50:16 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 11:50:21 all 0,11 0,00 0,00 0,00 0,00 22,97 0,00 0,00 76,92 11:50:21 0 0,00 0,00 0,00 0,00 0,00 22,36 0,00 0,00 77,64 11:50:21 1 0,00 0,00 0,00 0,00 0,00 22,00 0,00 0,00 78,00 11:50:21 2 0,00 0,00 0,00 0,00 0,00 17,20 0,00 0,00 82,80 11:50:21 3 0,00 0,00 0,00 0,00 0,00 19,64 0,00 0,00 80,36 11:50:21 4 0,00 0,00 0,00 0,00 0,00 20,00 0,00 0,00 80,00 11:50:21 5 0,00 0,00 0,00 0,00 0,00 20,40 0,00 0,00 79,60 11:50:21 6 0,00 0,00 0,00 0,00 0,00 22,00 0,00 0,00 78,00 11:50:21 7 0,00 0,00 0,00 0,00 0,00 21,60 0,00 0,00 78,40 11:50:21 8 0,00 0,00 0,00 0,00 0,00 18,00 0,00 0,00 82,00 11:50:21 9 0,00 0,00 0,00 0,00 0,00 22,40 0,00 0,00 77,60 11:50:21 10 0,00 0,00 0,00 0,00 0,00 23,20 0,00 0,00 76,80 11:50:21 11 0,00 0,00 0,00 0,00 0,00 22,85 0,00 0,00 77,15 11:50:21 12 0,00 0,00 0,00 0,00 0,00 28,60 0,00 0,00 71,40 11:50:21 13 0,00 0,00 0,00 0,00 0,00 27,60 0,00 0,00 72,40 11:50:21 14 0,00 0,00 0,00 0,00 0,00 24,40 0,00 0,00 75,60 11:50:21 15 0,00 0,00 0,00 0,00 0,00 29,60 0,00 0,00 70,40 11:50:21 16 0,00 0,00 0,00 0,00 0,00 27,40 0,00 0,00 72,60 11:50:21 17 0,00 0,00 0,00 0,00 0,00 26,60 0,00 0,00 73,40 11:50:21 18 0,00 0,00 0,00 0,00 0,00 24,60 0,00 0,00 75,40 11:50:21 19 0,00 0,00 0,00 0,00 0,00 29,74 0,00 0,00 70,26 11:50:21 20 2,79 0,00 0,00 0,00 0,00 24,35 0,00 0,00 72,85 11:50:21 21 0,00 0,00 0,00 0,00 0,00 25,75 0,00 0,00 74,25 11:50:21 22 0,00 0,00 0,00 0,00 0,00 25,80 0,00 0,00 74,20 11:50:21 23 0,00 0,00 0,00 0,00 0,00 27,20 0,00 0,00 72,80 11:50:21 24 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 25 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 26 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 27 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 28 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 29 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 30 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 31 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 32 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 33 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 34 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 35 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 36 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 37 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 38 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 39 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 41 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 42 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 43 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 100,00 11:50:21 44 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 45 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 46 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:50:21 47 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 PerfTop: 23486 irqs/sec kernel:100.0% exact: 0.0% [1000Hz cycles], (all, 48 CPUs) -------------------------------------------------------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ ___________________________ _______________________________________________________ 5505.00 8.5% ixgbe_poll /lib/modules/2.6.39.4/kernel/drivers/net/ixgbe/ixgbe.ko 3117.00 4.8% dev_queue_xmit /lib/modules/2.6.39.4/build/vmlinux 2527.00 3.9% __slab_free /lib/modules/2.6.39.4/build/vmlinux 2419.00 3.7% ixgbe_xmit_frame_ring /lib/modules/2.6.39.4/kernel/drivers/net/ixgbe/ixgbe.ko 1839.00 2.8% get_partial_node /lib/modules/2.6.39.4/build/vmlinux 1617.00 2.5% _raw_spin_lock /lib/modules/2.6.39.4/build/vmlinux 1582.00 2.4% native_read_tsc /lib/modules/2.6.39.4/build/vmlinux 1238.00 1.9% update_ts_time_stats /lib/modules/2.6.39.4/build/vmlinux 1073.00 1.7% __netif_receive_skb /lib/modules/2.6.39.4/build/vmlinux 1033.00 1.6% ktime_get /lib/modules/2.6.39.4/build/vmlinux 1027.00 1.6% tick_nohz_stop_sched_tick /lib/modules/2.6.39.4/build/vmlinux 998.00 1.5% __phys_addr /lib/modules/2.6.39.4/build/vmlinux 981.00 1.5% note_interrupt /lib/modules/2.6.39.4/build/vmlinux 971.00 1.5% timekeeping_get_ns /lib/modules/2.6.39.4/build/vmlinux 960.00 1.5% sch_direct_xmit /lib/modules/2.6.39.4/build/vmlinux 886.00 1.4% __kmalloc_node_track_caller /lib/modules/2.6.39.4/build/vmlinux 804.00 1.2% ixgbe_alloc_rx_buffers_ps /lib/modules/2.6.39.4/kernel/drivers/net/ixgbe/ixgbe.ko 796.00 1.2% irq_entries_start /lib/modules/2.6.39.4/build/vmlinux 766.00 1.2% __slab_alloc /lib/modules/2.6.39.4/build/vmlinux 738.00 1.1% __alloc_skb /lib/modules/2.6.39.4/build/vmlinux 717.00 1.1% virt_to_head_page /lib/modules/2.6.39.4/build/vmlinux 715.00 1.1% read_tsc /lib/modules/2.6.39.4/build/vmlinux 710.00 1.1% ip_route_input_common /lib/modules/2.6.39.4/build/vmlinux 708.00 1.1% native_sched_clock /lib/modules/2.6.39.4/build/vmlinux 665.00 1.0% gart_map_page /lib/modules/2.6.39.4/build/vmlinux 653.00 1.0% kfree /lib/modules/2.6.39.4/build/vmlinux на данный момент из очевидного, нужно прибавить ring size, который сейчас ethtool -g eth2 Ring parameters for eth2: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 512 RX Mini: 0 RX Jumbo: 0 TX: 512 и, видимо, поэксперементировать с параметром InterruptThrottleRate, ситуация осложняется тем что машинка в продакшене и я имею очень ограниченый интервал времени для манипуляций с ней. Изменено 20 марта, 2012 пользователем tawer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 20 марта, 2012 · Жалоба Я бы начал только с ITR. Увеличение ринга, если нет потерь делать не нужно. Может получиться бОльшая нагрузка из-за cache misses. 200К прерываний, то есть по 10К на очередь - многовато, а в топе у вас всеравно ядро да драйвер. Тут много не натюниш. Разве что пробовать ядро тянуть до 3.1. Но на продакшене ссыкотно же. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tawer Опубликовано 20 марта, 2012 · Жалоба Dark_Angel были бы очень интересны конкретные практические значения ITR, применительно к моим масштабам. кстати, а веточка ядра 3.0 как себя показыает? спасибо за ответы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...