[muchacho]

Тогда берите ядро 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 млрд. пакетов.

А как тут переделать? Я итак оставил самое нужное и если что-то переделывать, то получу только лишние правила.

[taf_321]

Первое что бросается в глаза, это явно прописать 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 должны будут упасть пакеты, которые ранее отлавливались по прежнему первому правилу.

 

Ничего не упустил, дырок в логике нет?

[taf_321]

В продолжении предыдущего поста по сокращению цепочек правил.

 

Я совершенно упустил из виду цепочки в таблице nat. А у нас тут вообще красота. Цепочка POSTROUTING, все пакеты, уходящие в локальную сеть через bond1 у нас пробегают по всем 62 правилам (61 явные + 1 дефолтное). Там стоит правило с фильтрацией по 192.168.1.0/24, но его явно недостаточно.

 

Есть еще возможность "ужать" правила для SNAT, но там еще придется играться с порядком расположения, чтобы правила для отдельных адресов срабатывали раньше общих правил для подсетей. Тогда можно будет всех загнать в ipset'ы типа nethash и все расположить в одной линейной последовательности.

[Dark_Angel]

Всё хорошо, вот только обработка правил в таблице NAT делается не per packet, а per flow. Поэтому запихните туда хоть 10К правил - ничего не изменится, если количество новых потоков не будет очень большим ( дестки и сотни тысяч в секунду ).

 

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

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

[muchacho]

Разобрался с большим кол-вом перрываний. Запущеный 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, если что-то изменится отпишусь.

[Alex/AT]

muchacho - попробуйте для начала переехать на x86-64 ядро. Судя по oprofile, есть какие-то затруднения с доступом ядра к памяти - dev_queue_xmit, skb_copy_bits, и (!!!) - __slab_alloc вылезают на первое место. Т.е. по первым двум явно что-то не клеится с memory-mapping'ом у сетевых плат, похоже. А третье - это, вероятно, наследие PAE + SMP. Сколько памяти на машине?

Изменено 12 января, 2012 пользователем Alex/AT

[Dark_Angel]

Смену ядра рекомендовали еще на прошлой странице. Очевидно, что на роутере виртуальные ядра должны быть отключены и не должно быть PAE. Аргументом тоже было то, что в топе профайлера только функции ядра. Человек вместо этого оптимизировал iptables.

[Alex/AT]

Рекомендовать-то рекомендовали, но направление указано не то. Тут можно пока не трогать версию ядра, надо сначала именно на x86-64 перейти. Явно видно, что загибает лапки управление памятью и доступ к памяти устройств. Скорее всего, из-за x86 / PAE. Может быть, конечно, и кривое железо, но вероятность этого меньше на порядок.

Изменено 13 января, 2012 пользователем Alex/AT

[Dark_Angel]

Соглашусь, про PAE и память никто ничего не говорил. Похоже таки дело в PAE, т.к. vmlinux-2.6.32-5-686-bigmem. Суфикс bigmem кагбэ намекает.

 

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

Изменено 13 января, 2012 пользователем Dark_Angel

[Alex/AT]

Смотря какой 2.6.32, и чего в него напихано. В RHEL 2.6.32 - это уже далеко не 2.6.32. В данном случае имеем не RHEL, но надо смотреть предметно.

[zevgen]

Коллеги, подскажите карточку PCIe с очередями, для шейпера с трафиком до 1Gbit.

Изменено 30 января, 2012 пользователем zevgen

[NiTr0]

Любая на i82576

[Dark_Angel]

82575 тоже сгодится, если найдете.

[Ilya Evseev]

82574 не поддерживает msi-x, зато стоит копейки (только что проверил - подешевела до 950р).

The best choice for the cheap gateway, imho.

[Dark_Angel]

Там же не просто гейт, а шейпер и фаервол наверное будет не в одно правило. Поэтому на гиг лучше крутить на нескольких процессорах. 4 гибридных очереди на порт с головой.

[=-Sky-=]

Помогите, пожалуйста, обновил сервер с 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

[Alex/AT]

Федорка на боевом сервере? Я бы не рискнул.

 

Что же до того, что нагрузка подросла и дропы - покажите

cat /proc/sys/net/core/netdev_max_backlog

cat /proc/sys/net/core/netdev_budget

cat /proc/sys/net/core/dev_weight

[=-Sky-=]

Федорка на боевом сервере? Я бы не рискнул.

 

Что же до того, что нагрузка подросла и дропы - покажите

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

[Alex/AT]

Попробуйте, только аккуратно:

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

[=-Sky-=]

Не помогло. Вот ТОП:

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

[telecom]

Попробуйте, только аккуратно:

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

У меня с вышеуказанных переход на эти то же не дал видимых результатов

[=-Sky-=]

Помогите, пожалуйста, обновил сервер с 15й до 16й Федоры, конфиги все перенес, но загрузка процессора выросла раза в полтора, появились дропы на eth0:

 

Решил убиранием правил 2000 правил iptables из -t mangle (ногами не бейте, так надо было, чтоб они были). Получается, что на 15й федоре айпитейблс работало лучше...

[tawer]

доброго дня,

оцените сбалансированность системы, есть подозерния что перфоманс маловат.

имеем 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

[Dark_Angel]

Я бы начал только с ITR. Увеличение ринга, если нет потерь делать не нужно. Может получиться бОльшая нагрузка из-за cache misses. 200К прерываний, то есть по 10К на очередь - многовато, а в топе у вас всеравно ядро да драйвер. Тут много не натюниш. Разве что пробовать ядро тянуть до 3.1. Но на продакшене ссыкотно же.

[tawer]

Dark_Angel

были бы очень интересны конкретные практические значения ITR, применительно к моим масштабам.

кстати, а веточка ядра 3.0 как себя показыает?

спасибо за ответы.