[Dark_Angel]

Ну говорите Вы все красиво и таймеры правильные, но откуда в контраке 100К соединений при 46Кpps? Вы поройтесь в эту сторону. Так однозначно быть не должно.

 

Далее по шейперам. Тоже все хорошо рассказываете, но откуда тогда в топе ts_kmp и sch_hfsc? Я допускаю, что ts_kmp может дергаться не из шейпера, а из iptables скажем или еще отуда-то, может даже из НАТА, но в топе ему не место, однозначно. Кстати, было бы не плохо выкупить, кто его просит. 1е место всетаки.

 

Если пакет на шейпере пролетает 5-6 правил, то нагрузка от фильтров просто смешная, у вас же классификатор висит достаточно высоко. Если уверены, что все пакеты проходят именно так, то пока шейпер не трогайте, покопайтесь в НАТе.

 

Кстати buckets лучше поставить CONNTRACK_MAX / 8 = 32K для вашего случая. Это на суть вопроса влияет мало, но всё же так согласно оф доке должно быть.

 

У вас в профайлере написано "CPU: Intel Core/i7, speed 1994.99 MHz (estimated)" так и должно быть, разве ксеон не определяется как ксеон?

 

А где tcp_keepalive_time, tcp_keepalive_probes, tcp_fin_timeout?

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

[Max P]

ts_kmp это не шейпер :) я его грохнул уже, выше отписался что сняло примерно 5% с каждого ядра (это два правила на выпил utp болталось в форвардинге иптаблеса)

[Dark_Angel]

Ну это функция матчинга строк, поэтому могла быть где угодно. Даже если нагрузка у вас сейчас низкая, то при росте pps будет расти нелинейно, потому что каждый пакет будет просматриваться через НАТ размером в 100К записей, а при увеличении pps того и глядиш вырастет.

[Max P]

да вот кстате раньше в районе 40к крутилось, откуда 100к ща берется - непонятно, буду рыть ща

 

да кстати,

 

> У вас в профайлере написано "CPU: Intel Core/i7, speed 1994.99 MHz (estimated)" так и должно быть, разве ксеон не определяется как ксеон?

 

Xeon 5504 это ядро i7, а oprofile берет описалово из ядра:

 

Performance Events: PEBS fmt1+, Nehalem events, Intel PMU driver.

 

Вот видимо из за nehalem и вылезает i7

[Dark_Angel]

40К для 44К пакетов тоже многовато. Просмотрите флов отсортированый по flows, прошу прощения за каламбур. Наверняка кто-то генерит кучу сессий и тем самым портит вам всю малину.

 

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

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

[Max P]

nat0 etc # conntrack -L conntrack|awk 'BEGIN {count=0} $4 ~ "TIME_WAIT" {count=count+1} END {print count}'

conntrack v0.9.14 (conntrack-tools): 109922 flow entries have been shown.

33092

nat0 etc # conntrack -L conntrack|awk 'BEGIN {count=0} $4 ~ "FIN_WAIT" {count=count+1} END {print count}'

conntrack v0.9.14 (conntrack-tools): 109783 flow entries have been shown.

30

nat0 etc # conntrack -L conntrack|awk 'BEGIN {count=0} $4 ~ "SYN_SENT" {count=count+1} END {print count}'

conntrack v0.9.14 (conntrack-tools): 109912 flow entries have been shown.

31874

 

вот еще пара показателей, ща еще ресетну oprofile и еще раз стату соберу

 

сортировать по flow - это conntrack -L отсортированный по src-адресам?

[Max P]

мда, щаз ____nf_conntrack_find висит вторым в топе примерно так же как и sch_hfsc жрет

[Dark_Angel]

Conntrack - это значение таблицы в текущий момент времени. Это интересно, но статистика интереснее. Поэтому я рекомендую посмотреть именно netflow. Ну там за 5-10-30-60 минут. У вас же он как раз собирается на роутере.

[Max P]

да судя по oprofile он далеко не в топе, вот его стата:

at0 etc # cat /proc/net/stat/ipt_netflow
Flows: active 116200 (peak 142110 reached 0d22h42m ago), mem 9985K
Hash: size 65535 (mem 511K), metric 2.4, 1.8, 1.0, 1.0. MemTraf: 4938350 pkt, 4317937 K (pdu 20, 1238).
Timeout: active 120, inactive 15. Maxflows 2000000
Rate: 651015210 bits/sec, 99045 packets/sec; Avg 1 min: 661741075 bps, 100055 pps; 5 min: 638055253 bps, 97281 pps
cpu#  stat: <search found new, trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes>
Total stat: 576143028774 653136257270 42122413491,    0    0    0    0, sock: 1404076576 0 123, 2007390729 K, traffic: 695258670761, 548551217 MB, drop: 0, 0 K
cpu0  stat: 38948119733 42310407071 3379367557,    0    0    0    0, sock:      0 0 123, 0 K, traffic: 45689774628, 40635257 MB, drop: 0, 0 K
cpu1  stat: 8383372740 8027998477 463943110,    0    0    0    0, sock:      0 0 0, 0 K, traffic: 8491941587, 6745511 MB, drop: 0, 0 K
cpu2  stat: 40388794018 46024874431 2308853908,    0    0    0    0, sock:      0 0 0, 0 K, traffic: 48333728339, 34089225 MB, drop: 0, 0 K
cpu3  stat: 38949471234 44849572757 2222163785,    0    0    0    0, sock:      0 0 0, 0 K, traffic: 47071736542, 33057254 MB, drop: 0, 0 K
cpu4  stat: 105507401634 120996800346 7275524894,    0    0    0    0, sock: 1404076576 0 0, 2007390729 K, traffic: 128272325240, 97384926 MB, drop: 0, 0 K
cpu5  stat: 135095365483 154874397618 10046211032,    0    0    0    0, sock:      0 0 0, 0 K, traffic: 164920608650, 130281811 MB, drop: 0, 0 K
cpu6  stat: 139534879722 158854424146 10168370693,    0    0    0    0, sock:      0 0 0, 0 K, traffic: 169022794839, 132542176 MB, drop: 0, 0 K
cpu7  stat: 69335624216 77197782427 6257978512,    0    0    0    0, sock:      0 0 0, 0 K, traffic: 83455760939, 73815053 MB, drop: 0, 0 K
sock0: 10.0.16.10:4444, sndbuf 16777216, filled 1, peak 5281; err: sndbuf reached 0, other 0
aggr#0 port: ports 1024-65535 replace 65535

 

а всё, понял насчет netflow :) да мне для него фильтры дольше городить чем conntrack -L обработать :) ибо он далеко и слишком жирный

[Dark_Angel]

Вы меня не поняли. Я говорил о том, чтобы просмотреть netflow который вы собираете, а не об активности процесса сборки. В netflow ( собраных файлах ) есть поле отвечающее за количество потоков в том или инном направлении. Ценность информации в агрегации, потому как можно легко увидеть, что клиент генерит 1К потоков в час, а другой генерит 1М потоков в час, соответственно количество потоков в минуту или даже секунду Вы сами посчитаете. Найдя таких активных можно посмотреть что они делают. Обычно это вирусня.

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

[Max P]

понял, щаз вот пока накидал на коленке скрипт, дергает число tcp-потоков из conntrack -L для src, топ 5:

 

src=10.19.32.87 - 1374

src=10.18.48.2 - 1070

src=10.19.33.152 - 924

src=10.19.17.155 - 763

src=10.19.33.219 - 703

 

1374 для одного абона это нормально? :)

Изменено 31 октября, 2011 пользователем Max P

[Max P]

вместе с udp там вообще за 1600 на абона вылезает

[Dark_Angel]

Скажем так, я считаю, что абон без торрентов больше 20-30 соединений держать не может. С торрентами, ну пусть будет 100-200. Всё, что дальше можно резать, если прижимает. 1К - это явно либо торрент, либо вирус, что в принципе одно и тоже.

[Max P]

да посмотрел траф одного из топа - очень похоже на торрент - коннекты на всякие там динамические домашние хосты с пакетами по 1460 байт - явно похоже раздачи идут

 

возникает вопрос - а как резать? в sfq насколько я помню дефолтом 1024, как же они больше то забирают?

 

посмотрел еще раз внимательно на conntrack -L - много SYN_SENT и TIME_WAIT, может имеет смысл еще укоротить net.netfilter.nf_conntrack_tcp_timeout_syn_sent и net.netfilter.nf_conntrack_tcp_timeout_time_wait ?

[Max P]

вот кстате без ts_kmp сильно полегчало похоже, сейчас было 750мбит суммарно, 113кппс, загрузка по ядрам 22-25% максимум, обычно было уже далеко за 30%

[Dark_Angel]

Да, можно порезать. Таймауты на ожидание можно не больше 30 сек. выставлять. Это кардинально ситуацию не поменяет, но будет легче.

 

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

[Max P]

да вот резать то как раз и не хотелось бы

 

ЗЫ. а это нормально что перф топ мне показывает 300000 irq? загрузка по ядрам при этом в районе 20% на каждом

 

PerfTop: 302087 irqs/sec kernel:99.2% exact: 0.0% [1000Hz cpu-clock-msecs], (all, 8 CPUs)

[Dark_Angel]

А что показывает vmstat 1?

 

Вообще, для большого количества ядер лучше прибивать количество прерываний руками. Скажем в сумме должно быть 8К прерываний. Соответственно если у вас 8 ядер и все с очередями, сделайте ITR = 1000. А то их дрвайвер по умолчанию наделает вам кучу переключений контекста.

[Max P]

хех, поставил на time_wait и syn_sent таймаут 30:

 

nat0 etc # conntrack -C

70702

 

упало почти в два раза) значит таки торренты тупо забивали таблицу, ибо частенько на раздачах пиры мертвые

 

nat0 etc # vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
1  0      0 758672 337464 1958264    0    0     0     0    0    0  0 11 89  0
0  0      0 758788 337464 1958264    0    0     0    16 113775 3840  0 20 80  0
0  0      0 758788 337464 1958264    0    0     0     8 116173 4055  0 20 80  0
0  0      0 758788 337464 1958264    0    0     0     0 115043 3958  0 19 81  0
0  0      0 758788 337464 1958264    0    0     0     0 113100 3788  0 20 80  0
0  0      0 758788 337464 1958264    0    0     0    76 113168 3782  0 20 80  0
0  0      0 758788 337464 1958264    0    0     0    24 114366 3874  0 20 80  0

 

да вот с ITR собсна пока не могу определиться, кто чего советует, оставил дефолтное драйверное, кстати а можно как то глянуть текущее значение?

Изменено 31 октября, 2011 пользователем Max P

[Dark_Angel]

Если поставили дефолтное, то там динамическая система определения прерываний. Обычно дравер пытается сделать их как можно больше, чтобы пакеты улетали как можно быстрее. Тогда количество прерываний = количеству пакетов. NAPI начинается, когда система начинает захлебываться от прерываний, или драйвер решает, что трафика много и надо его включить. Я значение по умолчанию использую на обычных серверах и десктопах. На роутерах выставляю руками. Моя рекомендация в данной ситуации, поставить статически 1К на очередь, если очередей 8. Будет у вас в 12 раз меньше прерываний в вашем случае. Я считаю, что это будет еффективнее. Дальше уж сами смотрите как хотите.

 

Мне кажется последние версии драйвера умеют менять этот параметр налету через ethtool. Я думаю, что там же его можно и прочитать.

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

[Max P]

угу, скорее всего как то через это:

 

nat0 perf # ethtool -c eth2

Coalesce parameters for eth2:

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

[Dark_Angel]

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

[Max P]

у меня ядерный igb

 

driver: igb

version: 2.1.0-k2

 

ридми ядерный к нему шибко куцый в котором инфы ноль

[Max P]

Ну собственно да, в одной пдфке наткнулся что именно rx-usecs за это и отвечает, у меня стоит 3 это dynamic conservative, не совсем только понятно можно ли туда запихать например 1000 или нет. Dark_Angle, можете посмотреть у себя что покажет ethtool -c на сетевуху?

[Max P]

хех, нашел тут же в теме:

 

ethtool -C eth2 rx-usecs XXX

где XXX=1000000/кол-во прерываний.

 

Если мне нужно ITR ставить 1000, то делить на 1000 или все таки суммарно на 8000 (ибо 8 ядер)?