[Hawk128]

720 байт на внешнем интерфейсе и 575 на тотале.

[jab]

 

При 150Mbit/s и 90kpps ?

[Hawk128]

stat# netstat -hdw1 -q3
            input        (Total)           output
   packets  errs idrops      bytes    packets  errs      bytes colls drops
       73K     0     0        41M        71K     0        45M     0     0 
       74K     0     0        41M        73K     0        47M     0     0 
       77K     0     0        42M        74K     0        46M     0     0 
stat# netstat -hdw1 -q3 -I igb0
            input         (igb0)           output
   packets  errs idrops      bytes    packets  errs      bytes colls drops
       27K     0     0        13M        26K     0        19M     0     0 
       26K     0     0        13M        25K     0        20M     0     0 
       25K     0     0        13M        24K     0        18M     0     0 
stat# netstat -hdw1 -q3 -I igb1
            input         (igb1)           output
   packets  errs idrops      bytes    packets  errs      bytes colls drops
       23K     0     0        17M        25K     0        12M     0     0 
       25K     0     0        18M        27K     0        12M     0     0 
       22K     0     0        16M        25K     0        12M     0     0

 

igb0 - внутренний

igb1 - внешний

 

last pid: 16097;  load averages:  2.02,  2.28,  2.53                       up 0+12:20:17  22:32:41
1054 processes:8 running, 1018 sleeping, 1 zombie, 27 waiting
CPU:  1.5% user,  0.0% nice, 27.5% system, 23.3% interrupt, 47.7% idle
Mem: 694M Active, 4026M Inact, 948M Wired, 125M Cache, 617M Buf, 45M Free
Swap: 2048M Total, 228K Used, 2048M Free

  PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root     171 ki31     0K    64K CPU3    3 484:56 55.57% {idle: cpu3}
   11 root     171 ki31     0K    64K RUN     2 474:37 52.88% {idle: cpu2}
   11 root     171 ki31     0K    64K CPU1    1 451:29 50.39% {idle: cpu1}
   11 root     171 ki31     0K    64K RUN     0 436:11 49.56% {idle: cpu0}
   13 root      68    -     0K    64K sleep   3 149:57 25.68% {ng_queue3}
   13 root      66    -     0K    64K CPU0    0 149:52 25.59% {ng_queue0}
   13 root      67    -     0K    64K sleep   3 149:44 25.39% {ng_queue2}
   13 root      67    -     0K    64K CPU3    0 149:57 24.17% {ng_queue1}
   12 root     -68    -     0K   448K WAIT    0  86:34 19.19% {irq261: igb1}
   12 root     -68    -     0K   448K WAIT    2  96:27 17.38% {irq263: igb1}
   12 root     -68    -     0K   448K WAIT    3  94:05 16.06% {irq264: igb1}
   12 root     -68    -     0K   448K WAIT    1  87:47 14.45% {irq262: igb1}
   12 root     -68    -     0K   448K WAIT    0  18:14  3.47% {irq256: igb0}
   12 root     -68    -     0K   448K WAIT    3  13:57  3.27% {irq259: igb0}
   12 root     -68    -     0K   448K CPU1    1  13:30  3.17% {irq257: igb0}
   12 root     -68    -     0K   448K WAIT    2  19:33  3.08% {irq258: igb0}
1154 root      45    0 49644K 20912K select  0  13:28  1.86% {mpd5}
7754 root      44  -15   371M   224M select  1   7:07  1.07% {ipcad}
   12 root     -32    -     0K   448K WAIT    1   2:47  0.00% {swi4: clock}
    0 root     -68    0     0K   272K -       2   2:36  0.00% {igb0 que}
    0 root     -16    0     0K   272K sched   3   2:29  0.00% {swapper}
    0 root     -68    0     0K   272K -       1   1:06  0.00% {dummynet}
   14 root      44    -     0K    16K -       1   1:02  0.00% yarrow
73848 bind      44    0   118M   105M ucond   2   0:59  0.00% {named}
73848 bind      44    0   118M   105M ucond   3   0:58  0.00% {named}
73848 bind      44    0   118M   105M ucond   2   0:58  0.00% {named}
73848 bind      44    0   118M   105M ucond   0   0:58  0.00% {named}
    0 root     -68    0     0K   272K -       1   0:43  0.00% {igb1 que}
   12 root     -64    -     0K   448K WAIT    3   0:39  0.00% {irq18: atapci0}
73848 bind      44    0   118M   105M kqread  1   0:36  0.00% {named}
   12 root     -64    -     0K   448K WAIT    3   0:31  0.00% {irq19: uhci0 uhc}
    0 root     -68    0     0K   272K -       1   0:29  0.00% {igb1 que}
2745 root      44    0 22960K  4256K select  3   0:23  0.00% nmbd
7754 root      44  -15   371M   224M select  2   0:22  0.00% {ipcad}
    0 root     -68    0     0K   272K -       0   0:22  0.00% {igb1 que}
    0 root     -68    0     0K   272K -       1   0:21  0.00% {igb1 que}
7754 root      44  -15   371M   224M select  1   0:18  0.00% {ipcad}
7754 root      44  -15   371M   224M select  2   0:17  0.00% {ipcad}
11559 root      44    0   147M 13476K select  1   0:16  0.00% httpd
   15 root     -68    -     0K   528K -       0   0:16  0.00% {usbus1}
   12 root     -24    -     0K   448K WAIT    1   0:16  0.00% {swi6: task queue}
    4 root      -8    -     0K    16K -       3   0:15  0.00% g_down
7754 root      44  -15   371M   224M select  1   0:14  0.00% {ipcad}
    3 root      -8    -     0K    16K -       1   0:14  0.00% g_up
4844 mysql     44    0   505M   199M sbwait  1   0:12  0.00% {mysqld}
7754 root      44  -15   371M   224M select  1   0:11  0.00% {ipcad}
7754 root      44  -15   371M   224M select  1   0:10  0.00% {ipcad}
7754 root      44  -15   371M   224M select  3   0:09  0.00% {ipcad}
7754 root      44  -15   371M   224M select  2   0:08  0.00% {ipcad}

 

Примерно так.

 

Сегодня решил попробовать опять вернуться на ipfw nat. Он тоже хорошо по ядрам разбежался.

 

До этого крутился простой natd. Нагрузку держал очень хорошо, но на одном ядре. Нагружал по вечерам уже на 65-70%.

 

Если что еще надо - выложу.

 

Как это ни странно, но natd похоже быстрее работает, чем ipfw nat.... Странно как то...

Изменено 10 июня, 2010 пользователем Hawk128

[jab]

 

Ну так у Вас там 50kpps при 400Mbit/s in+out. У меня pf nat на двух ядрах в пять раз больше жует. ( без mpd и ipcad )

 

natd параллелится лучше всех, но имеет самый большой overhead.

[Hawk128]

Как и писал выше, машинка пока что все в одном (скоро делить буду). К MPD5 там еще и ng_car прикручен, который похоже много чего пожирает. Тарифы до 16м безлимита....

 

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

Изменено 11 июня, 2010 пользователем Hawk128

[nicol@s]

Примерно так.

 

Сегодня решил попробовать опять вернуться на ipfw nat. Он тоже хорошо по ядрам разбежался.

А как вообще выглядит разбежавшийся по ядрам ipfw? Можно пример? Сам тестировал ipfw nat, но не увидел разбиения на треды.

[Hawk128]

По мануалы, как я понял, он добавляется к irq сетевых. У меня при переходе на них и переключилось. А они в моем случае по всем ядрам уже раскиданы.

[nicol@s]

А какой нат пошустрее и требует меньших ресурсов: ipfw nat, ng_nat или pf nat?

Создал тему на форуме http://forum.nag.ru/forum/index.php?showtopic=57859 , но никто не оставил свое мнение.

[Hawk128]

Еще natd забыли.

[jab]

еще забыли ipnat, но он, как и natd, ipfw nat и ng_nat торчит на libalias. Что нивелирует их скорость и параллельность до нуля.

 

Молодежь забывает, что скорость не главное. pf nat медленный и не параллелится, но зато он rock solid, и на гигабит дуплекса его хватает.

 

PS: что ни коим образом не оправдывает бесноватого Тео и банду.

[Ivan_83]

Зато либалиас вроде как больше корявых протоколов натит правильно, типа pptp, ftp, irc и прочих.

 

По либ алиас.

Там даты изменений 1996-2000 года.

 

Джаб, что вам мешает поднять пару нод ng_nat, привязать их к разным процам и заворачивать разные подсети на разные ноды?

 

Потом многие ругаются что либалиас правит заголовки и считает суммы сама -

/usr/src/sys/netinet/libalias/alias_util.c

либо патчим чтобы не считало (и патчим ng_nat чтобы он этим больше не заморачивался) либо патчим чтобы считало быстрее - у меня почти в 2 раза быстрее считает в uTP блокираторе.

 

И просто ради эксперимента, если оно на одном проце можно LIBALIAS_LOCK_ASSERT переобъявить как пустую заглушку и если паники не случится то будет ещё прирост.

 

 

Кстати в /usr/src/sys/contrib/pf/netinet/in4_cksum.c чуточку быстрее считает

[-Px-]

Зато либалиас вроде как больше корявых протоколов натит правильно, типа pptp, ftp, irc и прочих.

С ftp ровно обратная картина, правильно (в активном режиме) пускает только natd

[jab]

Джаб, что вам мешает поднять пару нод ng_nat, привязать их к разным процам и заворачивать разные подсети на разные ноды?

Там не пару нод надо а сотню-другую. И в каждой небось по memory leak.

[Slad]

Яндекс-дров под 8-STABLE нет.

есть уже.

[nicol@s]

А есть смысл использовать binat? Получу ли я значительный прирост в производительности? На pf nat особой разницы не заметил.

[windows_NT]

А есть смысл использовать binat? Получу ли я значительный прирост в производительности? На pf nat особой разницы не заметил.

Замучали этот несчастный pf на фре, он там дореволюционный и забитый. Забудьте про него. В каренте уже лежит третья версия ipfw с дупельнэтом там почти с нуля переписали всё. Думаю будет бэкпорт в 8.1. Вот там вы получите всё что хотите и паралельность и перпендикулярность.

[nicol@s]

Замучали этот несчастный pf на фре, он там дореволюционный и забитый. Забудьте про него. В каренте уже лежит третья версия ipfw с дупельнэтом там почти с нуля переписали всё. Думаю будет бэкпорт в 8.1. Вот там вы получите всё что хотите и паралельность и перпендикулярность.

Читал, что многие нахваливают ipfw3, но мои ожидания он пока не оправдал. Пример - не шейпит трафик как надо, т.е. все, что до 24Mbit/s режется на ура, а все, что выше - не режется ( http://forum.nag.ru/forum/index.php?showto...t=0#entry512327 )