[uxcr]

Странно, такое впечатление что исходящий трафик уходит в один поток. Можно посмотреть правила ipfw?

А так-то да, если решать проблему горизонтально, наверняка десятка с многопоточным pf задачу бы облегчила.

[doubtpoint]

01100 25912413349 26125310642905 nat tablearg ip from any to table(11) in
01300   262878097   313214384378 pipe tablearg ip from any to table(50) out
01400 32538177786 28793200428156 allow ip from any to 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12
11100       11184         566592 deny tcp from table(40) to any dst-port 25
41000 20110448958 12050388038925 nat tablearg ip from table(10) to any out
50000 20084813007 12143440771884 allow ip from any to any
65535         500          39378 allow ip from any to any

 

 

 

У меня немного смущает строчка lock(выводится через раз)

procstat -at | grep kernel | grep -v sleep ;
  0 100127 kernel           dummynet           7    8 lock    *taskqueu

[dadv]

У нас нет NAT под такой нагрузкой, но несколько замечаний общего плана всё-таки дам.

 

1. В ipfw операция поиска по таблице ДОРОГАЯ. Старайтесь по возможности делать таблицы поменьше и по таким правилам не прогонять пакеты, которые заведомо не предназначены для этих правил.

2. Количество инстансов ipfw nat лучше всего сделать равным количеству физических ядер системы, как и количество тредов драйвера сетевой карты - для уменьшения lock contention, что и приводит к нелинейному росту загрузки процессора за счет ненужного оверхеда.

3. Обновите систему до STABLE, в интелевских драйверах были нужные обновления.

4. Прочитайте главу в Handbook про DTRace: http://www.freebsd.org/doc/handbook/dtrace.html

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

5. Почитайте Черникова: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039640.html

[dadv]

Ещё один труднонаходимый источник проблем это dummynet, который не параллелится. Почитайте тут: http://forum.nag.ru/forum/index.php?showtopic=82298&view=findpost&p=810794

[DVM-Avgoor]

2. Количество инстансов ipfw nat лучше всего сделать равным количеству физических ядер системы, как и количество тредов драйвера сетевой карты - для уменьшения lock contention, что и приводит к нелинейному росту загрузки процессора за счет ненужного оверхеда.

 

 

Может ваши слова наконец воздействуют на ТС. Ему еще Х советов назад предлагалось...

[doubtpoint]

Может ваши слова наконец воздействуют на ТС. Ему еще Х советов назад предлагалось...

Натить 10000 (5000 онлайн) абонентов в 8 IP? Они не взвоют?

[DVM-Avgoor]

Натить 10000 (5000 онлайн) абонентов в 8 IP? Они не взвоют?

 

 

Загрустят конечно вероятно, но я же предлагал на пробу, всегда можно экспериментально найти нормальное кол-во.

[doubtpoint]

1. В ipfw операция поиска по таблице ДОРОГАЯ.

Судя по счетчику почти половина трафика попадает в 1 правило(хоть и таблеарг). Я сейчас увеличил table(10) в 16 раз до 16*256 записей - результат только положительный(более равномерная нагрузка инстансев). Так что не такая и дорогая...

41000 20110448958 12050388038925 nat tablearg ip from table(10) to any out

 

3. Обновите систему до STABLE, в интелевских драйверах были нужные обновления.

Обновил.

 

4. Прочитайте главу в Handbook про DTRace: http://www.freebsd.org/doc/handbook/dtrace.html

Почитаю. Я уже пытаюсь pmcstat:

ranularity: each sample hit covers 4 byte(s) for 0.00% of 2732083.00 seconds

 %   cumulative   self              self     total
time   seconds   seconds    calls  ms/call  ms/call  name
 9.3  253244.00 253244.00   107561  2354.42  2440.38  rn_match [22]
 8.7  490619.00 237375.00   165540  1433.94  6113.50  ipfw_chk [13]
 4.4  609543.00 118924.00    45263  2627.40  2627.40  _rw_rlock [33]
*  4.2  723651.00 114108.00   349817   326.19   352.88  _mtx_lock_sleep [31]
 4.2  837554.00 113903.00    59295  1920.95  1920.95  lookup_nat [35]
*  4.2  950984.00 113430.00    96576  1174.52  1181.15  _FindLinkIn [34]
 3.3 1042201.00 91217.00    37536  2430.12  2430.12  _rw_runlock [40]
 2.2 1102758.00 60557.00    24803  2441.52  2441.52  bzero [47]
 2.1 1159828.00 57070.00    23064  2474.42  2474.42  cpu_search_highest [50]
 1.7 1206864.00 47036.00    40585  1158.95 57417.06  ixgbe_rxeof [2]
 1.7 1252920.00 46056.00     7520  6124.47 11223.17  ixgbe_xmit [44]
 1.7 1298245.00 45325.00    58263   777.94 18373.37  ip_output [11]
 1.5 1340106.00 41861.00    85033   492.29  3291.63  bpf_mtap [19]
 1.5 1380468.00 40362.00    16592  2432.62  2432.62  bcopy [59]
 1.3 1416659.00 36191.00    52308   691.88  3744.26  ether_nh_input <cycle 2> [25]
 1.3 1452591.00 35932.00    11798  3045.60  7380.41  catchpacket [43]
 1.2 1485803.00 33212.00    58318   569.50 33215.96  ip_input [6]
 1.2 1518303.00 32500.00    89716   362.25  2473.86  ipfw_lookup_table [23]
 1.0 1545402.00 27099.00    18363  1475.74  2579.82  uma_zfree_arg [55]
 1.0 1572218.00 26816.00    11250  2383.64  2443.59  _bus_dmamap_load_buffer [67]
 1.0 1598878.00 26660.00    91871   290.19 14608.75  ip_forward [9]
 1.0 1624967.00 26089.00    19377  1346.39 19669.84  ether_output [18]
 1.0 1651004.00 26037.00    39158   664.92 50871.90  netisr_dispatch_src <cycle 2> [4]

* отмечены, те которые, вроде, возрастают нелинейно.

_FindLinkIn - функция которая просматривает всю таблицу трансляций. Вызывается при создании новой, может вызываться несколько раз если порт уже занят. И действительно проблема возникает когда трансляций в ipfw nat show больше (10000-50000). Попробую ограничить количество сессий.

[dadv]

Функции rn_match и ipfw_chk, которые у вас в топе при профилировании это и есть поиск по таблицам ipfw, как и _rw_rlock. rn_match делает непосредственное сравнивание, а цепочка вызовов выглядит примеро так:

 

ip_output > pfil_run_hooks > ipfw_check_hook > ipfw_chk > ipfw_lookup_table > rn_match > ...

 

Делайте выводы.

[doubtpoint]

Делайте выводы.

 

Да хоть и 10% каждая, но дело в том, что это линейные нагрузки, а производительности пока хватает. А вот нелинейные, они возрастают пиково и ограничивают производительность. Хотя убедили - поставлю перед правила skip to на всю подсеть в таблицах. Вообщем в понедельник буду пробовать(хотя м.б. уже приедет новые 10Г карты и модули и на этом все кончится...)

 

Для примера статистика ночью:

granularity: each sample hit covers 4 byte(s) for 0.00% of 801539.00 seconds

 %   cumulative   self              self     total
time   seconds   seconds    calls  ms/call  ms/call  name
11.2   89627.00 89627.00    31439  2850.82  2850.82  cpu_search_highest [15]
 7.3  148415.00 58788.00    25175  2335.17  2420.93  rn_match [22]
 6.6  201297.00 52882.00    31918  1656.81  6560.69  ipfw_chk [13]
 5.1  241999.00 40702.00    27874  1460.21  1465.63  _FindLinkIn [33]
 3.4  268997.00 26998.00     9957  2711.46  2711.46  _rw_rlock [38]
 3.1  293617.00 24620.00     8173  3012.36  3012.36  lookup_nat [40]
 2.8  315686.00 22069.00     9356  2358.81  2358.81  _rw_runlock [43]
 2.0  331624.00 15938.00     6751  2360.84  2360.84  bzero [49]
 1.8  346407.00 14783.00    10936  1351.77 47872.13  ixgbe_rxeof [5]
 1.4  357976.00 11569.00    13442   860.66 17742.95  ip_output [10]
 1.3  368339.00 10363.00     4303  2408.32  2408.32  bcopy [64]
 1.3  378677.00 10338.00     1596  6477.44 11746.63  ixgbe_xmit [47]
 1.2  388672.00  9995.00     5227  1912.19  1912.19  spinlock_exit <cycle 1> [65]
 1.2  398577.00  9905.00    18873   524.82  3731.33  bpf_mtap [18]
 1.1  407119.00  8542.00     2505  3409.98 10147.78  sched_switch <cycle 1> [39]
 1.0  415425.00  8306.00      716 11600.56 22769.44  sched_pickcpu [48]
 1.0  423687.00  8262.00    14899   554.53 28297.77  ip_input [8]
 1.0  431746.00  8059.00     2856  2821.78  2821.78  cpu_search_lowest [70]
 1.0  439520.00  7774.00     9382   828.61 58312.55  ixgbe_msix_que [4]
 1.0  447181.00  7661.00     3048  2513.45  7063.88  catchpacket [44]
 1.0  454801.00  7620.00    10470   727.79  4540.41  ether_nh_input <cycle 3> [30]

[doubtpoint]

Функции rn_match и ipfw_chk, которые у вас в топе при профилировании это и есть поиск по таблицам ipfw, как и _rw_rlock.

 

добавление первым правилом skipto всех nat_ip практически не меняет загрузки(в пределах погрешности измерения). Ну может быть сравнивает rn_match и ipfw_chk (а это 0,6%).

01000 2185506301 1363605858280 skipto 1200 ip from any to not xxx.xxx.xxx.0/24 in
01100 2483743735 2453230748442 nat tablearg ip from any to table(11) in
01300   17660441   17119604891 pipe tablearg ip from any to table(50) out
01400 3164630049 2817369182970 allow ip from any to 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12,46.32.64.0/19
11100          0             0 deny tcp from table(40) to any dst-port 25
15000      31035       8369531 fwd 127.0.0.1,9199 tcp from 10.125.0.0/16 to any dst-port 25 in
41000 2006465248 1291616832469 nat tablearg ip from table(10) to any out
50000 2004243617 1302780587462 allow ip from any to any

[dadv]

Этот skipto не отменяет поиска по таблицам в правилах 1300 и 41000.

[doubtpoint]

Этот skipto не отменяет поиска по таблицам в правилах 1300 и 41000.

Я не очень понимаю на, что намекаете.

Шейпер тоже должен быть и раскидывать клиентов по нат инстанцам тоже.

Таблицу 50 изменить не могу, а таблицу 10 наоборот увеличивал - результат положительный(для равномерной нагрузки инстанцы)

Изменено 24 ноября, 2013 пользователем doubtpoint

[dadv]

Ни на что не намекаю. Просто уточнил, что это skipto ничего кардинально изменить и не мог.