[AlKov]

Блин, вы бы уже быстрее сами попробовали бы и сравнили результаты.

Вы знаете, гадать на ромашке на не одной тысяче живых абонентов, как говориться нынче, по меньшей мере некошерно..

А не зная досконально предмет, одной "ромашки" может и не хватить.

Тренироваться на кошечках, к сожалению тоже не катит, нету кошечки..

[nuclearcat]

Alkov, не обращайте внимания, у FreeBSD-шников академическая система, но неакадемический и несистемный подход.

[lagman]

Я ответ на свой вопрос получу в итоге? :)

[nuclearcat]

Сделайте эксперимент, и увидите лично, данная тема открыта человеком, которому требуется совет, а не для ликбеза неграмотным :)

Мое IMHO: "Шедюлинг" тут вообще до фени, SMT хорош на числомолотильных задачах с относительно небольшим набором данных, которые нужны обеим задачам, что позволит приюзать все исполнительные ресурсы , а если это достаточно разные задачи с ощутимо большими наборами данных, они будут пополамить кеш и вымывать его друг другу.

[Dyr]

Вы знаете, гадать на ромашке на не одной тысяче живых абонентов, как говориться нынче, по меньшей мере некошерно.. А не зная досконально предмет, одной "ромашки" может и не хватить. Тренироваться на кошечках, к сожалению тоже не катит, нету кошечки..

 

То есть то, что у вас УЖЕ существует затык на двух ядрах - это можно, это ничего, а вот попробовать раскидать нагрузку, как вам говорится это уже всё, "бяда-бяда"? Притом что к затыку, очевидно, подходили постепенно, а значит имели время на проверку. Вы забавный...

 

Для академического интереса информация по нагрузке:

355Mbit 85Kpps транзитного траффика, 218K трансляций, 65K классов древовидного HTB шейпера

 

Надеюсь, это не всё, что вы смогли выжать из этого ксеона под Линуксом? А то не хочу вас расстраивать 500-600 Мбит/сек трафика на самом обычном обычном Core2Duo с FreeBSD PF NAT и dummynet. ^)

Изменено 2 марта, 2012 пользователем Dyr

[nuclearcat]

Надеюсь, это не всё, что вы смогли выжать из этого ксеона под Линуксом? А то не хочу вас расстраивать 500-600 Мбит/сек трафика на самом обычном обычном Core2Duo с FreeBSD PF NAT и dummynet. ^)

Разуйте глаза и посмотрите на нагрузку на процессор. У меня Sun Fire X4150 просто валялся не при делах, вот и запхнул на него нагрузку. Вообще там четыре сетевки, плюс куча незаюзанных ядер, можно конечно поизвращаться, но ненужно.

Если ресурсов останется меньше, я просто пересажу все на свежеполученные Fujitsu с Core i7, когда поставлю на них multiqueue сетевушки, конечно после тщательного тестирования.

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

[lagman]

Эксперимент, так эксперимент.

 

Нат, шейпинг, нетфло. Трафик такой:

svm# netstat -hI igb7 1

input (igb7) output

packets errs idrops bytes packets errs bytes colls

58K 0 0 37M 66K 0 63M 0

60K 0 0 37M 71K 0 69M 0

57K 0 0 38M 65K 0 60M 0

 

svm# sysctl kern.sched.topology_spec
kern.sched.topology_spec: <groups>
<group level="1" cache-level="0">
 <cpu count="24" mask="0xffffff">0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23</cpu>
 <children>
  <group level="2" cache-level="2">
   <cpu count="12" mask="0xfff">0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11</cpu>
   <children>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0x3">0, 1</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0xc">2, 3</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0x30">4, 5</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0xc0">6, 7</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0x300">8, 9</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0xc00">10, 11</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
   </children>
  </group>
  <group level="2" cache-level="2">
   <cpu count="12" mask="0xfff000">12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23</cpu>
   <children>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0x3000">12, 13</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0xc000">14, 15</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0x30000">16, 17</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0xc0000">18, 19</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0x300000">20, 21</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
    <group level="3" cache-level="1">
     <cpu count="2" mask="0xc00000">22, 23</cpu>
     <flags><flag name="THREAD">THREAD group</flag><flag name="SMT">SMT group</flag></flags>
    </group>
   </children>
  </group>
 </children>
</group>
</groups>

 

4 очереди, каждая пара на смт ядрах одного физического ядра, шарят л1 кэш:

 PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  12 root       -68    -     0K  1408K WAIT   12 299.9H 35.99% {irq291: igb7:que}
  12 root       -68    -     0K  1408K WAIT   15 305.0H 30.62% {irq294: igb7:que}
  12 root       -68    -     0K  1408K WAIT   14 302.8H 30.57% {irq293: igb7:que}
  12 root       -68    -     0K  1408K CPU13  13 313.9H 30.32% {irq292: igb7:que}

 

4 очереди, пары прибиты к первым смт ядрам в группах, шарят л2 кэш:

 PID USERNAME        PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
  12 root       -68    -     0K  1408K WAIT   12 313.9H 30.03% {irq292: igb7:que}
  12 root       -68    -     0K  1408K CPU12  12 299.9H 28.86% {irq291: igb7:que}
  12 root       -68    -     0K  1408K WAIT   14 305.0H 26.37% {irq294: igb7:que}
  12 root       -68    -     0K  1408K WAIT   14 302.9H 26.37% {irq293: igb7:que}

 

Все те же 4 очереди, прибиты к ядрам с разных процессоров:

 PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  12 root       -68    -     0K  1408K CPU14  14 302.9H 27.44% {irq293: igb7:que}
  12 root       -68    -     0K  1408K CPU4    4 313.9H 26.32% {irq292: igb7:que}
  12 root       -68    -     0K  1408K RUN    14 305.0H 26.22% {irq294: igb7:que}
  12 root       -68    -     0K  1408K WAIT    4 299.9H 25.88% {irq291: igb7:que}

 

Выигрыш от отсутствия шаринга кэша - менее 10%.

Выводы для себя: SMT удваивает кол-во ядер без заметного падения производительности. Ну а вопрос мой все еще остается в силе ;)

Изменено 2 марта, 2012 пользователем lagman

[Dyr]

Рад за вас, чо. Я как бы уже давно с Core2Duo всех пересадил на E3-1270, так что запаса хватает с головой.

[nuclearcat]

Выводы для себя: SMT удваивает кол-во ядер без заметного падения производительности. Ну а вопрос мой все еще остается в силе ;)

Только в процентах. Фактически все сложнее, и это непросто обьяснить человеку, который не представляет архитектуру процессора.

 

Два bzip2 на одном ядре

1

real 0m37.174s

user 0m18.488s

sys 0m0.066s

2

real 0m37.197s

user 0m18.513s

sys 0m0.069s

 

Один bzip2

 

1

real 0m18.300s

user 0m18.195s

sys 0m0.074s

 

Прикрепляем к разным физическим ядрам

1

real 0m18.359s

user 0m18.260s

sys 0m0.069s

2

real 0m18.545s

user 0m18.439s

sys 0m0.075s

 

Прикрепляем к одному ядру, но разным SMT тредам

Наблюдаем 100% у обоих потоков, ооо, 100% прирост по вашей логике. Но реальная работа:

1

real 0m30.370s

user 0m30.216s

sys 0m0.103s

2

real 0m30.395s

user 0m30.210s

sys 0m0.133s

[lagman]

А при чем тут бзип2? :)

[AlKov]

Такс, подсказки, с примером:

Прочёл три раза. Увы - как применить на себя, так и не дошло.. :(

Не хватает познаний..

Как же все-таки правильно распределить очереди в моем случае (два 2-х ядерных cpu Xeon E5503)?

Кстати, вот этот каталог (queues/rx-0) у меня сейчас отсутствует

/sys/class/net/eth0/queues/rx-0/rps_cpus

По-видимому из-за того, что у меня сейчас всего 4 очереди, раскиданные на 4 ядра. Так?

[nuclearcat]

Не хватает познаний..

Запустите этот скриптик https://gist.github.com/1089968

И запостите результат сюда.

 

Это пример условно-числомолотильной задачи, на которой заметен выигрыш SMT.

12 root -68 - 0K 1408K WAIT 12 299.9H 35.99% {irq291: igb7:que}

12 root -68 - 0K 1408K CPU13 13 313.9H 30.32% {irq292: igb7:que}

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

[AlKov]

Запустите этот скриптик https://gist.github.com/1089968

И запостите результат сюда.

 

cpu0: [Package #0, Core #0]
 same package as 0,2
 L1 Data:        32K 8-way with 64 byte lines
 L1 Instruction: 32K 4-way with 64 byte lines
 L2 Unified:     256K 8-way with 64 byte lines
 L3 Unified:     4096K 16-way with 64 byte lines
                 [shared with 0,2]

cpu1: [Package #1, Core #0]
 same package as 1,3
 L1 Data:        32K 8-way with 64 byte lines
 L1 Instruction: 32K 4-way with 64 byte lines
 L2 Unified:     256K 8-way with 64 byte lines
 L3 Unified:     4096K 16-way with 64 byte lines
                 [shared with 1,3]

cpu2: [Package #0, Core #2]
 same package as 0,2
 L1 Data:        32K 8-way with 64 byte lines
 L1 Instruction: 32K 4-way with 64 byte lines
 L2 Unified:     256K 8-way with 64 byte lines
 L3 Unified:     4096K 16-way with 64 byte lines
                 [shared with 0,2]

cpu3: [Package #1, Core #2]
 same package as 1,3
 L1 Data:        32K 8-way with 64 byte lines
 L1 Instruction: 32K 4-way with 64 byte lines
 L2 Unified:     256K 8-way with 64 byte lines
 L3 Unified:     4096K 16-way with 64 byte lines
                 [shared with 1,3]

[nuclearcat]

Два двухядерных процессора с разделяемым на каждый проц L3.

 

В принципе в первой картине у вас было разведено правильно, это аналогично:

echo 5 >/proc/irq/70/smp_affinity

echo 1 >/proc/irq/71/smp_affinity

echo 4 >/proc/irq/72/smp_affinity

echo a >/proc/irq/73/smp_affinity

echo 2 >/proc/irq/74/smp_affinity

echo 8 >/proc/irq/75/smp_affinity

 

Затык судя по всему из-за firewall или шейперов.

Ядро стандартное или самосбор? Есть ли netflow?

Сколько правил в iptables? Ветвление или линейно?

Как сделан шейпер? (Ветвление или линейные u32 правила? Если можно краткий пример)

[AlKov]

Два двухядерных процессора с разделяемым на каждый проц L3.

 

В принципе в первой картине у вас было разведено правильно, это аналогично:

echo 5 >/proc/irq/70/smp_affinity

echo 1 >/proc/irq/71/smp_affinity

echo 4 >/proc/irq/72/smp_affinity

echo a >/proc/irq/73/smp_affinity

echo 2 >/proc/irq/74/smp_affinity

echo 8 >/proc/irq/75/smp_affinity

В таком случае, есть ли смысл увеличивать количество очередей до 8 на интерфейс?

options igb IntMode=2,2,2,2 RSS=8,8,8,8 InterruptThrottleRate=100000,100000,100000,100000 QueuePairs=0,0,0,0

И если есть, то какой будет "принцип" их распределения по ядрам?

Затык судя по всему из-за firewall или шейперов.

Ядро стандартное или самосбор? Есть ли netflow?

Сколько правил в iptables? Ветвление или линейно?

Как сделан шейпер? (Ветвление или линейные u32 правила? Если можно краткий пример)

1. Ядро самосборное - 2.6.34

2. netflow до сегодняшнего дня не было. Поставил для того, чтобы выяснить причину непонятного скачка исходящего трафика. Не исключено, что собственно трафика и не существует, а "выброс" на картинке создает зашкаливший из-за перегрузки проца счётчик.

3. В iptables (1.48) порядка 100 правил

iptables -L -nv | wc -l
117

("лишние 17 - заголовки строк). Ветвления есть, в-основном по протоколам. Возможно несколько корявые, т.к. писал все это еще будучи совсем зеленым (преимущественно копипастил :)) и с тех пор "ветки" практически не изменял.

4. Шейпера нет. Он на NAS-ах (в mpd). На этой машине только роутинг, NAT и firewall.

Изменено 2 марта, 2012 пользователем AlKov

[nuclearcat]

В таком случае, есть ли смысл увеличивать количество очередей до 8 на интерфейс?

Можно конечно 4 очереди, на все ядра, но помоему не сильно поможет.

 

3. В iptables (1.48) порядка 100 правил

iptables -L -nv | wc -l
117

("лишние 17 - заголовки строк). Насчет ветвления в правилах не готов ответить (пытаюсь осмыслить, как это правильно определить :))

Попробуйте уменьшить количество правил.

Суть в том, что если большинство пакетов у вас вынуждены пробежать 100 цепочек правил, то это очень много. Нужно составить логическую цепочку прохождения пакета через правила, для типичных пакетов составляющих основную нагрузку.

[_INF_]

3. В iptables (1.48) порядка 100 правил

iptables -L -nv | wc -l
117

("лишние 17 - заголовки строк). Ветвления есть, в-основном по протоколам. Возможно несколько корявые, т.к. писал все это еще будучи совсем зеленым (преимущественно копипастил :)) и с тех пор "ветки" практически не изменял.

 

Суть в том, что кучу правил типа

 

-A FORWARD -p udp --dport 445 -j DROP
-A FORWARD -p udp --dport 135 -j DROP
-A FORWARD -p udp --dport 137 -j DROP
...

 

Можно заменить одним

-A FORWARD -p udp -m set --set badudp dst -j DROP

предварительно создав set badudp и добавив в него порты

ipset -N badudp portmap --from 1 --to 65535
ipset -A badudp 445
ipset -A badudp 135
ipset -A badudp 137

 

Аналогичным образом оптимизируются правила типа

 

-A FORWARD -d 192.168.0.0/16 -j DROP
-A FORWARD -d 10.0.0.0/8 -j DROP

 

Чем меньше наворотов в правилах, тем меньше нагрузка на CPU.

 

Также хотелось бы напомнить, что необходимо подкрутить

ethtool -G eth0 rx 2048
ethtool -G eth1 rx 2048

ethtool -G eth0 tx 2048
ethtool -G eth1 tx 2048

ethtool -K eth0 tso off
ethtool -K eth1 tso off

Значения выбирать таким чтобы дропов не было по выводу

ethtool -S eth0  
ethtool -S eth1

также

ifconfig eth0 txqueuelen 10000
ifconfig eth1 txqueuelen 10000

 

Выставить параметр hashsize примерно равным максимальному количеству conntrack соединений

 

для примера

echo "500000" >/sys/module/nf_conntrack/parameters/hashsize

 

 

Кстати в sysctl что-нибудь крутили ?

[AlKov]

В таком случае, есть ли смысл увеличивать количество очередей до 8 на интерфейс?

Можно конечно 4 очереди, на все ядра, но помоему не сильно поможет.

Т.е. Вы считаете, что 8 очередей на интерфейс - это излишне? И даже 4 существенно не поправят "перекос"?

Ну вот например, сейчас - 470М/61Kpps, conntrack ~ 170K

PRC | sys    0.35s | user   0.36s | #proc    120  | #trun      1 | #tslpi   133 | #tslpu     0 | #zombie    0 | clones     1  |              | #exit      0 |
CPU | sys       0% | user      3% | irq     163%  | idle    234% | wait      0% |              | steal     0% | guest     0%  | curf 2.00GHz | curscal   ?% |
cpu | sys       0% | user      0% | irq      53%  | idle     47% | cpu002 w  0% |              | steal     0% | guest     0%  | curf 2.00GHz | curscal   ?% |
cpu | sys       0% | user      0% | irq      49%  | idle     51% | cpu000 w  0% |              | steal     0% | guest     0%  | curf 2.00GHz | curscal   ?% |
cpu | sys       0% | user      2% | irq      32%  | idle     65% | cpu001 w  0% |              | steal     0% | guest     0%  | curf 2.00GHz | curscal   ?% |
cpu | sys       0% | user      0% | irq      29%  | idle     70% | cpu003 w  0% |              | steal     0% | guest     0%  | curf 2.00GHz | curscal   ?% |

Два ядра на 50% и два на 30%. Вроде неплохо было бы и подравнять?

Да, "4 очереди на все ядра" - это так?

options igb IntMode=2,2,2,2 RSS=4,4,4,4 InterruptThrottleRate=100000,100000,100000,100000 QueuePairs=0,0,0,0

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

           CPU0       CPU1       CPU2       CPU3

70:          8          0          0          0   PCI-MSI-edge      eth2
71:  248930170          0          0          0   PCI-MSI-edge      eth2-TxRx-0
72:      52868          0  245411633          0   PCI-MSI-edge      eth2-TxRx-1
73:          8          0          0          0   PCI-MSI-edge      eth3
74:      64699  577642339          0          0   PCI-MSI-edge      eth3-TxRx-0
75:      46723          0          0  548095947   PCI-MSI-edge      eth3-TxRx-1

Попробуйте уменьшить количество правил.

Суть в том, что если большинство пакетов у вас вынуждены пробежать 100 цепочек правил, то это очень много. Нужно составить логическую цепочку прохождения пакета через правила, для типичных пакетов составляющих основную нагрузку.

Разве 100 правил - это много? Учитывая еще то, что %30 из них находятся в почти неиспользуемых цепочках (INPUT,OUTPUT).

Оптимизацией фаервола конечно давно пора заняться и это я постараюсь в ближайшее время осуществить. Но честно говоря, слабо верится, что эффект будет заметен. Хотя.. Доверяй (себе), но проверяй. :)

Изменено 2 марта, 2012 пользователем AlKov

[lagman]

Офигеть, сотня правил для линукса - много :(

[_INF_]

Разве 100 правил - это много? Учитывая еще то, что %30 из них находятся в почти неиспользуемых цепочках (INPUT,OUTPUT).

Оптимизацией фаервола конечно давно пора заняться и это я постараюсь в ближайшее время осуществить. Но честно говоря, слабо верится, что эффект будет заметен. Хотя.. Доверяй (себе), но проверяй. :)

 

Вы не поверите, но дело еще в том, что это за правила.

 

Например тот же connlimit прекрасно работает на 10-100 kpps, но использовать его на высоких нагрузках опасно, т.к. загрузка процессоров будет в потолок. (В свое время тестировал на гигабите трафика, практически аналогичные правила с использованием recent грузили процессоры на 20-30% меньше).

 

Поэтому советую еще раз пересмотреть порядок, и свойства правил iptables.

 

Офигеть, сотня правил для линукса - много :(

 

Иногда лучше молчать чем говорить.

Изменено 2 марта, 2012 пользователем _INF_

[AlKov]

Суть в том, что кучу правил типа

 

-A FORWARD -p udp --dport 445 -j DROP
-A FORWARD -p udp --dport 135 -j DROP
-A FORWARD -p udp --dport 137 -j DROP
...

 

Можно заменить одним

-A FORWARD -p udp -m set --set badudp dst -j DROP

....

Чем меньше наворотов в правилах, тем меньше нагрузка на CPU.

Ну у меня правила ветвления даже более примитивные, чем в вашем примере. ipset вообще не использую. Хотя, может быть все это и есть "минус".

Также хотелось бы напомнить, что необходимо подкрутить

ethtool -G eth0 rx 2048
ethtool -G eth1 rx 2048

ethtool -G eth0 tx 2048
ethtool -G eth1 tx 2048

ethtool -K eth0 tso off
ethtool -K eth1 tso off

также

ifconfig eth0 txqueuelen 10000
ifconfig eth1 txqueuelen 10000

Давно уже так.

Выставить параметр hashsize примерно равным максимальному количеству conntrack соединений

Тоже давно увеличено и даже с огромным запасом

cat /sys/module/nf_conntrack/parameters/hashsize
2097152

Кстати в sysctl что-нибудь крутили ?

Крутил. И много чего..

P.S. Кстати, хочу заметить, что проблема никак не связана с загрузкой сети. Может быть и при минимуме.

Изменено 2 марта, 2012 пользователем AlKov

[kayot]

Запустите этот скриптик https://gist.github.com/1089968

И запостите результат сюда.

Спасибо, интересный скрипт. Сразу нашел у себя на паре BRASов ошибки с распределением, при навешивании на ядра с общим кешем загрузка снижается :)

[nuclearcat]

Еще можно запустить профайлер (perf в ядре или oprofile) и посмотреть - какая функция в ядре жрет проц

[AlKov]

Причину "перекоса" нашел - действительно было в iptables.

После оптимизации получил практически идеальный результат - при 500М/64Kpps/175K трансляций получил следующую загрузку:

CPU0 - 28%

CPU1 - 26%

CPU2 - 25%

CPU3 - 22%

Учитывая еще запущенный netflow (ipt_netflow).

Но.. Похоже "главного врага" я так и не нашел.. После оптимизации снова получил "выброс" исходящего трафа и соотв. загрузку CPU.

Правда, в этот раз, "выброс" не достиг максимума(ширины аплинка), а всплеск загрузки произошел только на CPU3, на остальных был соотв. "провал".

А последние сутки вообще прошли без катаклизмов..

Жду повторов и пока не представляю, что же еще мониторить, если снова глюкнет..

 

Еще можно запустить профайлер (perf в ядре или oprofile) и посмотреть - какая функция в ядре жрет проц

К сожалению, для меня это тёмный лес.. :(

Изменено 5 марта, 2012 пользователем AlKov

[nuclearcat]

Если заоптимизировали проц, уже не надо.

По поводу мониторинга аплинка, можно написать по идее минимальную программку, которая будет поллить интерфейс, и когда загрузка превысит номинальную - дампить хотя бы хеадеры траффика. Как доеду на работу - попробую сделать, но не обещаю.