Линукс NAT

[Oleg Gawriloff]

Имеем сервер HP DL140G3 в следующей конфигурации: 2*E5310 Quad Core 1.6Ghz. На нем натим и маршрутизируем абонентов. На вход и выход стоят сетевухи HP NC373T (чип BCM5708). Gentoo на vanilla-ядре 2.6.30.9. При вырастании трафика свыше 120Мбит/15kpps начинают расти счетчики дискардов на сетевухах. Дискарды растут на rx_fw.

Как бы не сильно критично, но напрягает. Кто что посоветует?

 

Сетевухи сидят на MSI на разных прерываниях:

57: 2053855043 2049331913 2053924401 2055567115 2055453728 2051777514 2054708109 2051858111 PCI-MSI-edge eth2

58: 3148201286 3140557013 3148090009 3146445509 3146516576 3143505639 3147300619 3143431206 PCI-MSI-edge eth3

 

Настройки sysctl по сравнению с дефолтными и данные ethtool (если необходимо могу привести, форум почему-то не дает аттачить файлы).

Для клиентов которым NAT не нужен используем опцию NOTRACK. Таймером hrtimer, клоксорцом - hpet

 

 

 

 

[2c2i]

sysctl net.netfilter.nf_conntrack_count

sysctl net.netfilter.nf_conntrack_buckets

sysctl net.netfilter.nf_conntrack_max

[Oleg Gawriloff]

sysctl net.netfilter.nf_conntrack_count

sysctl net.netfilter.nf_conntrack_buckets

sysctl net.netfilter.nf_conntrack_max

Выкручено.

net.ipv4.netfilter.ip_conntrack_max = 500000

net.ipv4.netfilter.ip_conntrack_count = 44526

net.ipv4.netfilter.ip_conntrack_buckets = 500224

net.netfilter.nf_conntrack_acct=0

net.netfilter.nf_conntrack_tcp_timeout_established=21100

net.netfilter.nf_conntrack_tcp_timeout_fin_wait=45

net.ipv4.tcp_fin_timeout=1800

 

Edited February 5, 2010 by Oleg Gawriloff

[vitalyb]

Сетевухи сидят на MSI на разных прерываниях:

прибейте вручную eth2 на нулевое ядро, а eth3 - на первое.

 

Покажите или начните собирать подробную статистику по закрузке CPU.

 

[Oleg Gawriloff]

Сетевухи сидят на MSI на разных прерываниях:

прибейте вручную eth2 на нулевое ядро, а eth3 - на первое.

 

Покажите или начните собирать подробную статистику по закрузке CPU.

Вот загрузка процессора:

Используется irqbalance который судя по mpstat распределяет нагрузку по ядрам равномерно. Разве cpuset изменит ситуацию, по сути же irqbalance делает тоже самое. Или я чего не понимаю?

barzog@vulture ~ $ sudo mpstat -u -P 0,1,2,3,4,5,6,7 1

Linux 2.6.30.9 (vulture) 05.02.2010 _x86_64_ (8 CPU)

 

22:17:38 0 0,00 0,00 0,00 0,00 0,00 20,00 0,00 0,00 80,00

22:17:38 1 0,00 0,00 0,00 0,00 2,00 15,00 0,00 0,00 83,00

22:17:38 2 0,00 0,00 0,00 0,00 1,00 18,00 0,00 0,00 81,00

22:17:38 3 0,00 0,00 0,00 0,00 1,00 13,00 0,00 0,00 86,00

22:17:38 4 0,00 0,00 0,00 0,00 1,00 19,00 0,00 0,00 80,00

22:17:38 5 0,00 0,00 0,00 0,00 2,00 19,00 0,00 0,00 79,00

22:17:38 6 0,00 0,00 0,00 0,00 1,00 21,00 0,00 0,00 78,00

22:17:38 7 0,00 0,00 0,00 0,00 2,00 17,00 0,00 0,00 81,00

22:17:39 0 0,00 0,00 0,00 0,00 1,00 15,00 0,00 0,00 84,00

22:17:39 1 0,00 0,00 0,00 0,00 1,00 23,00 0,00 0,00 76,00

22:17:39 2 0,00 0,00 0,00 0,00 1,00 16,00 0,00 0,00 83,00

22:17:39 3 0,00 0,00 0,00 0,00 0,00 14,00 0,00 0,00 86,00

22:17:39 4 0,00 0,00 0,00 0,00 0,00 12,00 0,00 0,00 88,00

22:17:39 5 0,00 0,00 0,00 0,00 0,00 20,00 0,00 0,00 80,00

22:17:39 6 0,00 0,00 0,00 0,00 0,00 17,00 0,00 0,00 83,00

22:17:39 7 0,00 0,00 0,00 0,00 0,00 9,00 0,00 0,00 91,00

22:17:40 0 0,00 0,00 0,00 0,00 1,00 17,00 0,00 0,00 82,00

22:17:40 1 0,00 0,00 0,00 0,00 2,00 12,00 0,00 0,00 86,00

22:17:40 2 0,00 0,00 0,00 0,00 0,00 14,00 0,00 0,00 86,00

22:17:40 3 0,00 0,00 0,00 0,00 0,00 13,00 0,00 0,00 87,00

22:17:40 4 0,00 0,00 0,00 0,00 0,00 15,00 0,00 0,00 85,00

22:17:40 5 0,00 0,00 0,00 0,00 1,00 15,00 0,00 0,00 84,00

22:17:40 6 0,00 0,00 0,00 0,00 1,00 10,00 0,00 0,00 89,00

22:17:40 7 0,00 0,00 0,00 0,00 0,00 13,00 0,00 0,00 87,00

22:17:41 0 0,00 0,00 0,00 0,00 0,00 8,00 0,00 0,00 92,00

22:17:41 1 0,00 0,00 0,00 0,00 0,00 12,00 0,00 0,00 88,00

22:17:41 2 0,00 0,00 0,00 0,00 1,00 13,00 0,00 0,00 86,00

22:17:41 3 0,00 0,00 0,00 0,00 2,00 11,00 0,00 0,00 87,00

22:17:41 4 0,00 0,00 0,00 0,00 1,00 12,00 0,00 0,00 87,00

22:17:41 5 0,00 0,00 0,00 0,00 0,00 8,00 0,00 0,00 92,00

22:17:41 6 0,00 0,00 0,00 0,00 0,00 18,00 0,00 0,00 82,00

22:17:41 7 0,00 0,00 0,00 0,00 1,00 13,00 0,00 0,00 86,00

22:17:42 0 0,00 0,00 1,00 0,00 0,00 11,00 0,00 0,00 88,00

 

[Умник]

Oleg Gawriloff, у Вас судя по всему включен в ядре irq balancing. Отключите и используете userspace irqbalance (irqbalance.org), либо распределяйте прерывания по ядрам вручную при помощи /proc/irq/N/smp_affinity.

 

[Oleg Gawriloff]

Oleg Gawriloff, у Вас судя по всему включен в ядре irq balancing. Отключите и используете userspace irqbalance (irqbalance.org), либо распределяйте прерывания по ядрам вручную при помощи /proc/irq/N/smp_affinity.

Гмм. Вроде как в ядре ничего такого нет (как опция ядра называется?, сходу не нашел), userspace irqbalance используется, по mpstat видно что прерывания равномерно распределяются по всем ядрам.

[Умник]

В том-то и дело, что уж больно они равномерно распределены. Это плохо, прерывание не должно постоянно перемещаться между CPU, иначе часто инвалидейтится кеш процессора. Опция называется CONFIG_IRQBALANCE, проверьте еще раз. Если выключено, то балансировку прерываний может делать сама материнская плата. Но я таких случаев еще не встречал.

[Oleg Gawriloff]

В том-то и дело, что уж больно они равномерно распределены. Это плохо, прерывание не должно постоянно перемещаться между CPU, иначе часто инвалидейтится кеш процессора. Опция называется CONFIG_IRQBALANCE, проверьте еще раз. Если выключено, то балансировку прерываний может делать сама материнская плата. Но я таких случаев еще не встречал.

Согласно доке этой опции начиная с ядра 2.6.28 нет. У меня 2.6.30 и использовать я ее поэтому никак не могу. Как я понимаю такое распределение и есть результат работы irqbalance на 8 ядрах. Если отказаться от использования irqbalance и перейти на привязку прерываний к конкретным ядрам (т.е. если я вручную назначу первую сетевуху на 0 ядро, а 2ю на 4е) тогда я получу загруженные на 80% 0 и 4е ядра и простаивающие остальные. Что тоже по идее не есть гуд, ибо остается всего 20% запас.

 

Более того: настроек irqbalance я не нашел.

 

Рекомендуют еще включить CONFIG_IP_FIB_TRIE если много маршрутов.

vulture linux # netstat -rn | wc

3555 28436 287885

Это много или мало? Уже пора с FIB_HASH на FIB_TRIE переключаться?

Edited February 6, 2010 by Oleg Gawriloff

[vitalyb]

Если отказаться от использования irqbalance и перейти на привязку прерываний к конкретным ядрам (т.е. если я вручную назначу первую сетевуху на 0 ядро, а 2ю на 4е) тогда я получу загруженные на 80% 0 и 4е ядра и простаивающие остальные. Что тоже по идее не есть гуд, ибо остается всего 20% запас.

У Вас именно так сейчас и есть, никакого четырехкратного запаса. Как уже было сказано, прыгающие по ядрам прерывания - очень плохо. И прибивать, скорее всего, прийдется не к 0 и 4, а к 0 и 1 чтобы был общий L2 кеш (хотя тут можно поэкспериментировать).

 

[2c2i]

Запустите perf top (tools/perf в исходниках ядра) и посмотрите что там сверху. У вас правил в iptables не сильно много?

Edited February 8, 2010 by 2c2i

[Oleg Gawriloff]

Запустите perf top (tools/perf в исходниках ядра) и посмотрите что там сверху. У вас правил в iptables не сильно много?

Изучил вопрос: дока, фишка эта появилось в 2.6.31. У меня же 2.6.30. Апгрейд все равно был запланирован, результаты сообщу. Строчек в iptables не сильно много:

barzog@vulture ~ $ sudo iptables-save | wc

90 1005 6874

Активно используем ipset.

 

Если отказаться от использования irqbalance и перейти на привязку прерываний к конкретным ядрам (т.е. если я вручную назначу первую сетевуху на 0 ядро, а 2ю на 4е) тогда я получу загруженные на 80% 0 и 4е ядра и простаивающие остальные. Что тоже по идее не есть гуд, ибо остается всего 20% запас.

У Вас именно так сейчас и есть, никакого четырехкратного запаса. Как уже было сказано, прыгающие по ядрам прерывания - очень плохо. И прибивать, скорее всего, прийдется не к 0 и 4, а к 0 и 1 чтобы был общий L2 кеш (хотя тут можно поэкспериментировать).

Ок, понял. Будем экспериментировать, результаты сообщу. Соотв. если дело именно в этом получается что дальнейшее повышение производительности делается чисто апгрейдом частоты процессора и покупкой сетевух с разделением очередей по прерываниям. Т.е. если сейчас 2 сетевухи, каждая из которых использует по 1 прерыванию на 1 логическом ядре частатой в 1.6Ghz то оптимальным конфигом будет 2е сетевухи с 4мя очередями каждая из которые использует по 1 прерыванию на 8 логических ядрах. Если не будет хватать - повышать частоты отдельного ядра. Логика верная?

Edited February 8, 2010 by Oleg Gawriloff

[Oleg Gawriloff]

Запустите perf top (tools/perf в исходниках ядра) и посмотрите что там сверху. У вас правил в iptables не сильно много?

Запустил на тестовом сервере (из активности только компиляция ядра), после 3х минут работы сервер впал в ступор: не пингуется, на консоль не реагирует. Пришлось ребутать по питанию. На боевых серверах такой тест не рискну я запускать.

[Oleg Gawriloff]

Запустите perf top (tools/perf в исходниках ядра) и посмотрите что там сверху. У вас правил в iptables не сильно много?

Вот результаты oprofile:

CPU: Core 2, speed 1596 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

62686 6.5986 bnx2_poll_work

51522 5.4234 __nf_conntrack_find

49060 5.1643 ipt_do_table

46604 4.9058 bnx2_start_xmit

37870 3.9864 nf_conntrack_find_get

35114 3.6963 mwait_idle

34608 3.6430 ip_route_input

31911 3.3591 __hash_conntrack

30026 3.1607 dev_queue_xmit

28325 2.9816 connlimit_mt

25905 2.7269 fn_hash_lookup

19868 2.0914 skb_dma_unmap

18819 1.9810 skb_release_head_state

17069 1.7968 __alloc_skb

15981 1.6822 irq_entries_start

15226 1.6028 bnx2_msi

14985 1.5774 handle_edge_irq

13546 1.4259 __vlan_hwaccel_rx

12698 1.3366 memset_c

12430 1.3084 ip_forward

 

Особого криминала здесь не вижу. Насчет привязки к CPU. Согласно доке оно работает только для IOAPIC. У меня сетевухи сидят на MSI. Оно вообще будет работать?

 

[Max P]

будет

[Oleg Gawriloff]

будет

Обчитался дальше.

barzog@vulture ~ $ sudo cat /proc/irq/58/smp_affinity

80

barzog@vulture ~ $ sudo cat /proc/irq/57/smp_affinity

02

Вместе с тем по: watch --interval=1 'grep eth /proc/interrupts'

57: 294495918 294403227 294377949 294186519 294390542 294218428 294270130 294257390 PCI-MSI-edge eth2

58: 337394724 337490992 337515441 337226090 337502025 337335655 337627845 337296327 PCI-MSI-edge eth3

Растут равномерно по всем ядрам, это значит что значения выставленные irqbalance не работают. Пишут что для bnx2 и моего чипа принудительно нужно выключать MSI тогда заработает. Не есть гуд. Попробую - результаты сообщу.

 

 

 

[vadimus]

Не желательно очень на серверах использовать сетевухи broadcom, когда попадаются такие сервера, я ставлю внешнюю Intel. У меня 150 kpps и проблем нету, на Gentoo vanilla-2.6.27, стоит две сетевухи intel, прибита каждая к отдельному ядру, а на остальных запущен irqbalance, там в его конфигурации можно исключить определенные прерывания и процессоры (ну в смысле ядра).

Edited February 12, 2010 by vadimus

[Oleg Gawriloff]

Не желательно очень на серверах использовать сетевухи broadcom. У меня 150 kpps и проблем нету, на Gentoo vanilla-2.6.27, стоит две сетевухи intel, прибита каждая к отдельному ядру, а на остальных запущен irqbalance, там в его конфигурации можно исключить определенные прерывания и процессоры (ну в смысле ядра).

Это я уже понял:) Но хотелось бы сначала все испробывать на текущем железе, а потом уже за правильным интелом бежать.