[Bufera]

 

Всем доброго дня!

 

Имею PC шлюз на примерно 1700 абонентов, построен на FreeBSD 7.1-RELEASE-p2 на 2х 5410 Xeon.

Абоненты терминируются на L3 свичах, до шлюза бежит только трафик Интернет. Всё простой маршрутизацией без vlan'ов, em0 смотрит в инет, em1 - в локальную сеть. Сетевые em встроенные.

Помимо шейпа, работает ipfw nat и сбор статистики через ng_netflow.

 

В ЧНН почти всё время наблюдаю такую картину в top'е:

Код

last pid: 37420; load averages: 0.84, 0.79, 0.71 up 85+06:27:37 22:55:24

67 processes: 11 running, 45 sleeping, 11 waiting

CPU: 0.0% user, 0.0% nice, 21.9% system, 0.7% interrupt, 77.5% idle

Mem: 97M Active, 133M Inact, 161M Wired, 920K Cache, 199M Buf, 3118M Free

Swap:

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND

12 root 1 171 ki31 0K 8K CPU5 5 1980.5 97.17% idle: cpu5

15 root 1 171 ki31 0K 8K CPU2 2 1910.2 89.89% idle: cpu2

14 root 1 171 ki31 0K 8K RUN 3 1955.3 89.06% idle: cpu3

10 root 1 171 ki31 0K 8K CPU7 7 1981.3 87.89% idle: cpu7

17 root 1 171 ki31 0K 8K CPU0 0 1845.6 87.21% idle: cpu0

16 root 1 171 ki31 0K 8K CPU1 1 1847.4 84.18% idle: cpu1

13 root 1 171 ki31 0K 8K CPU4 4 1972.8 82.86% idle: cpu4

11 root 1 171 ki31 0K 8K RUN 6 1972.2 67.29% idle: cpu6

38 root 1 -68 - 0K 8K CPU6 6 301.8H 41.85% dummynet

29 root 1 43 - 0K 8K RUN 3 64.3H 12.16% em0_rx_kthrea

152 root 1 43 - 0K 8K WAIT 2 64.4H 11.47% em0_rx_kthrea

33 root 1 43 - 0K 8K WAIT 1 63.2H 10.89% em1_rx_kthrea

49273 root 1 43 - 0K 8K WAIT 5 713:21 10.89% em1_rx_kthrea

151 root 1 43 - 0K 8K WAIT 4 64.2H 10.84% em0_rx_kthrea

28 root 1 43 - 0K 8K WAIT 0 64.4H 10.69% em0_rx_kthrea

163 root 1 43 - 0K 8K WAIT 0 63.1H 10.55% em1_rx_kthrea

32 root 1 43 - 0K 8K WAIT 7 63.1H 10.35% em1_rx_kthrea

18 root 1 -32 - 0K 8K WAIT 0 43.4H 1.51% swi4: clock

но довольно часто на короткое время процесс dummynet выжирает до 85-90% проца.

 

Нагрузка на шлюз не очень велика:

Код

gw-228-0 22:58:55 ~ # netstat -w1d

input (Total) output

packets errs bytes packets errs bytes colls

46268 0 34363024 45307 0 33805885 0

45964 0 34642701 44742 0 34093655 0

46851 0 35027810 46254 0 34640772 0

45837 0 33805929 44721 0 33213205 0

46796 0 35255467 45791 0 34552068 0

45343 0 34140908 44396 0 33633273 0

46217 0 34563171 45345 0 34008366 0

 

В фаерволе вроде как всё оптимизированно по максимуму, если нет, подскажите что и где?

Код

00001 nat 1 ip from any to any in via em0

00002 skipto tablearg ip from any to table(1)

00003 skipto tablearg ip from table(2) to any

00004 deny ip from any to any

00100 allow tcp from table(5) to any dst-port 22

00101 allow tcp from table(6) to any dst-port 4567

00102 deny tcp from any to any dst-port 22,4567

00103 allow ip from any to any

00500 pipe tablearg ip from any to table(11) out via em1

00501 ngtee 65534 ip from any to any out via em1 # <- это заворот на ng_netflow

00502 allow ip from any to any

01000 pipe tablearg ip from table(12) to any in via em1

01001 ngtee 65534 ip from any to any in via em1

01002 nat 1 ip from any to any out via em0

01003 allow ip from any to any

01500 pipe tablearg ip from any to table(11) out via em1

01501 ngtee 65534 ip from any to any out via em1

01502 allow ip from any to any

02000 pipe tablearg ip from table(12) to any in via em1

02001 ngtee 65534 ip from any to any in via em1

02002 allow ip from any to any

02500 ngtee 65534 ip from any to any out via em1

02501 allow ip from any to any

03000 ngtee 65534 ip from any to any in via em1

03001 nat 1 ip from any to any out via em0

03002 allow ip from any to any

03500 ngtee 65534 ip from any to any out via em1

03501 allow ip from any to any

04000 ngtee 65534 ip from any to any in via em1

04001 allow ip from any to any

65535 allow ip from any to any

 

 

чтота я несовсем понял

http://image2you.ru/1498/7231/ а тут что

 

 

[photon]

При массовом использовании правил с tablearg нужно каким-то образом вручную генерировать номера пайпов (для pipe tablearg) или номера правил (для skipto tablearg) на основе IP-адреса. При этом, между ними должно быть взаимооднозначное соответствие: pipe id <-> IP, иначе правилами будет трудно управлять автоматически через биллинг. В случае динамических пайпов этого делать не нужно, достаточно добавлять/удалять IP в соответствующую таблицу.

Изменено 14 июня, 2009 пользователем photon

[jab]

При массовом использовании правил с tablearg нужно каким-то образом вручную генерировать номера пайпов (для pipe tablearg) или номера правил (для skipto tablearg) на основе IP-адреса. При этом, между ними должно быть взаимооднозначное соответствие: pipe id <-> IP. В случае динамических пайпов этого делать не нужно, достаточно добавлять/удалять IP в соответствующую таблицу.

Зачем вручную ? Скриптом религия не позволяет ?

[photon]

Зачем вручную ? Скриптом религия не позволяет ?

Имелось в виду, конечно же, не в уме или на калькуляторе считать, а генерировать своим скриптом. Дело в том, что тут возникает нетривиальная математическая задача. Вот придумайте на досуге хэш-функцию для этого случая: каждому IP-адресу (грубо говоря, числу между 1 и 2^32-1) должно соответствовать два уникальных номера (от 1 до 2^16-1) для пайпов на вход и выход. В случае skipto задачу можно несколько упростить: нужен лишь один номер. И чтобы не было коллизий при количестве записей около 6-8 тысяч. Проще всего, конечно, отбросить два первых октета у IP (hash = ip AND 0x0000FFFF), но тогда нельзя будет шейпить адреса с разными первыми и одинаковыми последними октетами.

Изменено 14 июня, 2009 пользователем photon

[jab]

Зачем вручную ? Скриптом религия не позволяет ?

Имелось в виду, конечно же, не в уме или на калькуляторе считать, а генерировать своим скриптом. Вот придумайте на досуге хэш-функцию для этой задачи: каждому IP-адресу (грубо говоря, числу между 1 и 2^32-1) должно соответствовать два уникальных номера (от 1 до 2^16-1) для пайпов на вход и выход. В случае skipto задачу можно несколько упростить: нужен лишь один номер. И чтобы не было коллизий при количестве записей около 6-7 тысяч. Проще всего в этом случае отбросить два первых октета у IP (hash1 = ip >> 16; hash2 = hash1 + 1), но тогда нельзя будет шейпить адреса из сетей с одинаковыми последними октетами.

У Вас есть account_id и набор адресов к нему.

[sid1333]

Зачем вручную ? Скриптом религия не позволяет ?

Имелось в виду, конечно же, не в уме или на калькуляторе считать, а генерировать своим скриптом. Вот придумайте на досуге хэш-функцию для этой задачи: каждому IP-адресу (грубо говоря, числу между 1 и 2^32-1) должно соответствовать два уникальных номера (от 1 до 2^16-1) для пайпов на вход и выход. В случае skipto задачу можно несколько упростить: нужен лишь один номер. И чтобы не было коллизий при количестве записей около 6-7 тысяч. Проще всего в этом случае отбросить два первых октета у IP (hash1 = ip >> 16; hash2 = hash1 + 1), но тогда нельзя будет шейпить адреса из сетей с одинаковыми последними октетами.

У Вас есть account_id и набор адресов к нему.

Аналогично. Номер аккаунта соответствует номеру входящей трубы, номер аккаунта +2^15-1 - исходящей.

Коллизий нет. И на кой тут хэш-функции? :)

 

[photon]

Ну если просто занумеровать все адреса по порядку, и хранить эту таблицу соответствия, то считать номер пайпа из IP не нужно.

Изменено 14 июня, 2009 пользователем photon

[jab]

Ну если просто занумеровать все адреса по порядку, и хранить эту таблицу соответствия

А в биллинге Вы эти соответствия не храните ?

[photon]

Конечно, id у юзерских аккаунтов есть, но для управления шейпером используются не они, а id тарифов (в качестве номеров таблиц). Впрочем, я никого не заставляю делать также. Нравится вам конфигурить, скажем, несколько тысяч нод в Netgraph или несколько тысяч статических пайпов вместо небольшого числа правил для динамических -- делайте так.

Изменено 14 июня, 2009 пользователем photon

[[GP]Villi]

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

[photon]

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

Раньше, при небольшом числе юзеров, было такое дело, а сейчас -- нет. Это приводит к дополнительным сложностям во всем: в биллинге, в автоматизации управления свичами и в правилах шейпинга. Если юзер хочет подключить несколько машин, он ставит себе дома роутер.

Изменено 14 июня, 2009 пользователем photon

[jab]

Раньше, при небольшом числе юзеров, было такое дело, а сейчас -- нет. Это приводит к дополнительным сложностям во всем: в биллинге, в автоматизации управления свичами и в правилах шейпинга. Если юзер хочет подключить несколько машин, он ставит себе дома роутер.

Еще раз повторяю - ipfw не догма, а руководство к действию. В одном и том же конфиге Вы можете сочетать и динамические трубы, и статические, и с tablearg и без, и со skipto ( особенно если net.inet.ip.fw.one_pass ), и с netgraph и с ALTQ и с divert sockets.

 

[photon]

Да пожалуйста, делайте сколь угодно сложные решения. Я буду делать, как проще.

[sid1333]

Да пожалуйста, делайте сколь угодно сложные решения. Я буду делать, как проще.

При чём тут сложность? Мы говорим о том, как решить конкретную задачу с минимумом затрат и максимально оптимально.

 

[sid1333]

Нашел в итоге в чём был косяк.

Прознал про замечательную команду - cpuset. Прибил dummynet к 0 ядру и всё - 0.00% нагрузка на него сразу стало. И даже не думает подпрыгивать как было раньше.

[[GP]Villi]

это где такое, можно поподробнее пожалуйста?

[sid1333]

это где такое, можно поподробнее пожалуйста?

Команда где? Во Freebsd

[XeonVs]

Спорный момент, у меня привязка к определенному ядру дает обратный эффект.

 

наилучший результат пока достигнут на такой маске:

# cpuset -g -p 53

pid 53 mask: 0, 1, 2, 3, 6, 7

 

pid53 это dummunet. ядра 4 и 5 заняты обработкой прерываний сетевух.

Изменено 30 сентября, 2009 пользователем XeonVs

[sid1333]

Спорный момент, у меня привязка к определенному ядру дает обратный эффект.

 

наилучший результат пока достигнут на такой маске:

# cpuset -g -p 53

pid 53 mask: 0, 1, 2, 3, 6, 7

 

pid53 это dummunet. ядра 4 и 5 заняты обработкой прерываний сетевух.

А система какая у вас? У меня такой эффект дало на 2 шейперах - один 7.2@amd64, 2ой 7.1@i386

До привязки как я уже писал нагрузка на dummynet прыгала до 60% (7.1@i386 1.5Гбит/с in/out)

Через 2ой шейпер бегает пока намного меньше, но и там это наблюдалось.

 

 

[XeonVs]

Спорный момент, у меня привязка к определенному ядру дает обратный эффект.

 

наилучший результат пока достигнут на такой маске:

# cpuset -g -p 53

pid 53 mask: 0, 1, 2, 3, 6, 7

 

pid53 это dummunet. ядра 4 и 5 заняты обработкой прерываний сетевух.

А система какая у вас? У меня такой эффект дало на 2 шейперах - один 7.2@amd64, 2ой 7.1@i386

До привязки как я уже писал нагрузка на dummynet прыгала до 60% (7.1@i386 1.5Гбит/с in/out)

Через 2ой шейпер бегает пока намного меньше, но и там это наблюдалось.

AMD64 7.2-STABLE #12: Tue Sep 29 05:10:11 MSD 2009

 

у меня там и 100% было, сейчас отключил(net.isr.direct=0) прямой процессинг пакетов, стало легче, выше 50% не поднимается пока.

все соптимизированно естессно, пользуется tablearg.

[sid1333]

Спорный момент, у меня привязка к определенному ядру дает обратный эффект.

 

наилучший результат пока достигнут на такой маске:

# cpuset -g -p 53

pid 53 mask: 0, 1, 2, 3, 6, 7

 

pid53 это dummunet. ядра 4 и 5 заняты обработкой прерываний сетевух.

А система какая у вас? У меня такой эффект дало на 2 шейперах - один 7.2@amd64, 2ой 7.1@i386

До привязки как я уже писал нагрузка на dummynet прыгала до 60% (7.1@i386 1.5Гбит/с in/out)

Через 2ой шейпер бегает пока намного меньше, но и там это наблюдалось.

AMD64 7.2-STABLE #12: Tue Sep 29 05:10:11 MSD 2009

 

у меня там и 100% было, сейчас отключил(net.isr.direct=0) прямой процессинг пакетов, стало легче, выше 50% не поднимается пока.

все соптимизированно естессно, пользуется tablearg.

А драйвера на em у вас какие? Использую yandex'овские

 

[jab]

AMD64 7.2-STABLE #12: Tue Sep 29 05:10:11 MSD 2009

у меня там и 100% было, сейчас отключил(net.isr.direct=0) прямой процессинг пакетов, стало легче, выше 50% не поднимается пока.

все соптимизированно естессно, пользуется tablearg.

А на yandex драйверах ?

 

91 processes:  11 running, 68 sleeping, 12 waiting
CPU:  0.0% user,  0.0% nice, 18.0% system,  0.0% interrupt, 82.0% idle
Mem: 9172K Active, 6900K Inact, 169M Wired, 72K Cache, 8512K Buf, 2780M Free
Swap:

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   15 root        1 171 ki31     0K    16K CPU3    3 286.1H 90.87% idle: cpu3
   17 root        1 171 ki31     0K    16K CPU1    1 286.7H 90.43% idle: cpu1
   13 root        1 171 ki31     0K    16K CPU5    5 279.8H 89.84% idle: cpu5
   11 root        1 171 ki31     0K    16K CPU7    7 267.3H 83.98% idle: cpu7
   12 root        1 171 ki31     0K    16K CPU6    6 246.7H 76.51% idle: cpu6
   14 root        1 171 ki31     0K    16K RUN     4 238.1H 75.34% idle: cpu4
   16 root        1 171 ki31     0K    16K RUN     2 226.6H 73.63% idle: cpu2
   18 root        1 171 ki31     0K    16K RUN     0 220.5H 70.51% idle: cpu0
   39 root        1  43    -     0K    16K WAIT    6  43.2H 18.31% em2_rx_kthread_0
   40 root        1  43    -     0K    16K CPU6    4  43.1H 18.26% em2_rx_kthread_1
  157 root        1  43    -     0K    16K WAIT    6  36.2H 13.48% em1_rx_kthread_3
   36 root        1  43    -     0K    16K WAIT    0  36.2H 13.18% em1_rx_kthread_1
   35 root        1  43    -     0K    16K WAIT    4  36.2H 12.94% em1_rx_kthread_0
  156 root        1  43    -     0K    16K WAIT    7  36.2H 12.65% em1_rx_kthread_2
  153 root        1  43    -     0K    16K WAIT    0  32.6H 12.16% em0_rx_kthread_3
   43 root        1  43    -     0K    16K WAIT    0  29.9H 11.96% em3_rx_kthread_0
   31 root        1  43    -     0K    16K RUN     2  32.7H 11.77% em0_rx_kthread_0
   32 root        1  43    -     0K    16K WAIT    4  32.6H 11.47% em0_rx_kthread_1
  152 root        1  43    -     0K    16K WAIT    7  32.6H 11.43% em0_rx_kthread_2
   44 root        1  43    -     0K    16K WAIT    7  29.9H 11.43% em3_rx_kthread_1
   30 root        1 -68    -     0K    16K WAIT    4 249:35  0.29% em0_txcleaner
   19 root        1 -32    -     0K    16K WAIT    4  76:52  0.15% swi4: clock
   53 root        1 -68    -     0K    16K -       3  25.1H  0.00% dummynet
   34 root        1 -68    -     0K    16K WAIT    7 173:03  0.00% em1_txcleaner
   42 root        1 -68    -     0K    16K WAIT    7 124:16  0.00% em3_txcleaner
   38 root        1 -68    -     0K    16K WAIT    6  90:37  0.00% em2_txcleaner
   21 root        1 -44    -     0K    16K WAIT    5  33:29  0.00% swi1: net

 

200kpps in+out, четыре сетевухи в двух бриджах

[XeonVs]

AMD64 7.2-STABLE #12: Tue Sep 29 05:10:11 MSD 2009

у меня там и 100% было, сейчас отключил(net.isr.direct=0) прямой процессинг пакетов, стало легче, выше 50% не поднимается пока.

все соптимизированно естессно, пользуется tablearg.

А на yandex драйверах ?

а там нет инетелов это IBM BladeCenter HS21

и внутрях у каждого лезвия пара NetXtreme II BCM5708S Gigabit Ethernet

 

[jab]

и внутрях у каждого лезвия пара NetXtreme II BCM5708S Gigabit Ethernet

Гадость редкостная...

[XeonVs]

Спорный момент, у меня привязка к определенному ядру дает обратный эффект.

 

наилучший результат пока достигнут на такой маске:

# cpuset -g -p 53

pid 53 mask: 0, 1, 2, 3, 6, 7

 

pid53 это dummunet. ядра 4 и 5 заняты обработкой прерываний сетевух.

А система какая у вас? У меня такой эффект дало на 2 шейперах - один 7.2@amd64, 2ой 7.1@i386

До привязки как я уже писал нагрузка на dummynet прыгала до 60% (7.1@i386 1.5Гбит/с in/out)

Через 2ой шейпер бегает пока намного меньше, но и там это наблюдалось.

AMD64 7.2-STABLE #12: Tue Sep 29 05:10:11 MSD 2009

 

у меня там и 100% было, сейчас отключил(net.isr.direct=0) прямой процессинг пакетов, стало легче, выше 50% не поднимается пока.

все соптимизированно естессно, пользуется tablearg.

А драйвера на em у вас какие? Использую yandex'овские

jab`у ответил уже

 

яндексовские драйвера пробовал на другой машине, не понравилось, но там был NAT(мегабит 300 поток на 100kpps), а не шейпер\роутер.

 

и внутрях у каждого лезвия пара NetXtreme II BCM5708S Gigabit Ethernet

Гадость редкостная...

да сам тоже не ввосторге, но выбирать не приходится. :(