Jump to content
Калькуляторы

Линукс NAT

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

Traffic.pngPPS.pngDiscards.png

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

 

Сетевухи сидят на 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

 

 

 

 

Share this post


Link to post
Share on other sites

sysctl net.netfilter.nf_conntrack_count

sysctl net.netfilter.nf_conntrack_buckets

sysctl net.netfilter.nf_conntrack_max

Share this post


Link to post
Share on other sites
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 by Oleg Gawriloff

Share this post


Link to post
Share on other sites
Сетевухи сидят на MSI на разных прерываниях:
прибейте вручную eth2 на нулевое ядро, а eth3 - на первое.

 

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

 

Share this post


Link to post
Share on other sites
Сетевухи сидят на MSI на разных прерываниях:
прибейте вручную eth2 на нулевое ядро, а eth3 - на первое.

 

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

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

Используется 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

 

Share this post


Link to post
Share on other sites

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

 

Share this post


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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
В том-то и дело, что уж больно они равномерно распределены. Это плохо, прерывание не должно постоянно перемещаться между 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 by Oleg Gawriloff

Share this post


Link to post
Share on other sites
Если отказаться от использования irqbalance и перейти на привязку прерываний к конкретным ядрам (т.е. если я вручную назначу первую сетевуху на 0 ядро, а 2ю на 4е) тогда я получу загруженные на 80% 0 и 4е ядра и простаивающие остальные. Что тоже по идее не есть гуд, ибо остается всего 20% запас.
У Вас именно так сейчас и есть, никакого четырехкратного запаса. Как уже было сказано, прыгающие по ядрам прерывания - очень плохо. И прибивать, скорее всего, прийдется не к 0 и 4, а к 0 и 1 чтобы был общий L2 кеш (хотя тут можно поэкспериментировать).

 

Share this post


Link to post
Share on other sites

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

Edited by 2c2i

Share this post


Link to post
Share on other sites
Запустите 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 by Oleg Gawriloff

Share this post


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

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

Share this post


Link to post
Share on other sites
Запустите 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. Оно вообще будет работать?

 

Share this post


Link to post
Share on other sites
будет

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

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 тогда заработает. Не есть гуд. Попробую - результаты сообщу.

 

 

 

Share this post


Link to post
Share on other sites

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

Edited by vadimus

Share this post


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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this