Оптимизация Dummynet под широкий канал

[goletsa]

Спасибо, знач на 7.2 Останусь.
А как быть с несколькими с привязыванием ядер к сетевым, на 7.2 это нормально реализовано?

Не запаривался пока с таким. Кстати пока гоняю новую(относительно) платформу от интела.
На борту распаяны две карты на чипе 82576EB http://ark.intel.com/Product.aspx?id=37166
Почти такой же чип стоит на E1G42ET ( там правда везде пишут просто 82576).

И немного цифр:

Код:

last pid: 27330;  load averages:  0.21,  0.11,  0.09    up 1+18:14:54  19:16:32
31 processes:  1 running, 30 sleeping
CPU:  0.9% user,  0.0% nice,  1.3% system, 21.1% interrupt, 76.7% idle
Mem: 47M Active, 988M Inact, 518M Wired, 232K Cache, 414M Buf, 2326M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
 1600 root        1   8  -15 61668K 43020K nanslp  0  60:28  4.83% perl5.12.3
 1452 root        4  44  -15 43828K 37148K select  2   2:48  2.39% ipcad
25762 root        1  44    0 25096K  7516K select  2   0:03  0.00% bsnmpd


last pid: 27302;  load averages:  0.02,  0.07,  0.07    up 1+18:11:52  19:13:30
97 processes:  5 running, 68 sleeping, 24 waiting
CPU 0:  0.9% user,  0.0% nice,  2.2% system, 30.7% interrupt, 66.2% idle
CPU 1:  0.4% user,  0.0% nice,  3.1% system,  0.9% interrupt, 95.6% idle
CPU 2:  0.0% user,  0.0% nice,  2.2% system,  0.0% interrupt, 97.8% idle
CPU 3:  0.0% user,  0.0% nice,  0.9% system, 57.9% interrupt, 41.2% idle
Mem: 47M Active, 988M Inact, 518M Wired, 232K Cache, 414M Buf, 2326M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   13 root        1 171 ki31     0K    16K RUN     1  39.6H 95.95% idle: cpu1
   12 root        1 171 ki31     0K    16K CPU2    2  38.3H 75.00% idle: cpu2
   14 root        1 171 ki31     0K    16K CPU0    0  40.8H 73.93% idle: cpu0
   11 root        1 171 ki31     0K    16K CPU3    3  41.1H 48.63% idle: cpu3
   36 root        1 -68    -     0K    16K WAIT    3  39:42 40.19% irq260: igb2
   30 root        1 -68    -     0K    16K WAIT    0  34:45 36.77% irq256: igb0
   56 root        1 -68    -     0K    16K -       2 335:21 27.59% dummynet
 1600 root        1   8  -15 61668K 43020K nanslp  1  60:18  4.05% perl5.12.3
 1452 root        4  44  -15 43828K 37148K select  0   2:43  2.78% ipcad
   31 root        1 -68    -     0K    16K -       2   1:36  0.93% igb0 que
   37 root        1 -68    -     0K    16K -       1   1:06  0.68% igb2 que
   16 root        1 -32    -     0K    16K WAIT    1  12:07  0.00% swi4: clock
   63 root        1  20    -     0K    16K syncer  0   1:10  0.00% syncer

# netstat -w1 -h
            input        (Total)           output
   packets  errs      bytes    packets  errs      bytes colls
      105K     0        84M        98K     0        84M     0
      104K     0        83M        97K     0        83M     0
      104K     0        81M        95K     0        90M     0
      105K     0        85M        99K     0        85M     0

# netstat -w1 -I igb2 -h
            input         (igb2)           output
   packets  errs      bytes    packets  errs      bytes colls
       57K     0        51M        46K     0        32M     0
       54K     0        50M        43K     0        28M     0
       56K     0        53M        43K     0        27M     0
       57K     0        55M        43K     0        27M     0
^C


# uname  -a
FreeBSD nat4.tinconet.ru 7.4-RELEASE-p2 FreeBSD 7.4-RELEASE-p2 #0: Mon Jun 13 04:41:41 MSD 2011     root@nat4.tinconet.ru:/usr/obj/usr/src/sys/TINCONAT  amd64

[Demeo]

А может мне кто-нить объяснить, почему на новых Интеловских дровах у меня прерывания входящей карточки распределяются на 4 ядра, а внутренняя (самая нагруженная сервисами) на одном висит?

Код:

last pid: 39256;  load averages:  0.12,  0.07,  0.05              up 0+03:20:09  13:07:02
177 processes: 5 running, 143 sleeping, 29 waiting
CPU 0:  0.5% user,  0.0% nice,  1.0% system, 35.9% interrupt, 62.5% idle
CPU 1:  0.5% user,  0.0% nice,  7.9% system,  5.8% interrupt, 85.9% idle
CPU 2:  0.5% user,  0.5% nice,  5.2% system,  4.2% interrupt, 89.5% idle
CPU 3:  0.5% user,  0.0% nice, 11.0% system,  3.1% interrupt, 85.3% idle
Mem: 379M Active, 58M Inact, 257M Wired, 292K Cache, 108M Buf, 7225M Free
Swap: 16G Total, 16G Free

  PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root       171 ki31     0K    64K CPU1    1 182:44 100.00% {idle: cpu1}
   11 root       171 ki31     0K    64K CPU3    3 178:22 91.46% {idle: cpu3}
   11 root       171 ki31     0K    64K RUN     2 177:38 86.96% {idle: cpu2}
   11 root       171 ki31     0K    64K CPU0    0 149:25 70.90% {idle: cpu0}
   12 root       -68    -     0K   464K WAIT    0  37:19 26.37% {irq261: igb1:que}
    0 root       -68    0     0K   240K -       3  20:33  9.18% {dummynet}
   12 root       -68    -     0K   464K WAIT    0  10:42  7.08% {irq256: igb0:que}
   12 root       -68    -     0K   464K WAIT    3   9:08  5.66% {irq259: igb0:que}
   12 root       -68    -     0K   464K WAIT    2   9:28  5.18% {irq258: igb0:que}
   12 root       -68    -     0K   464K WAIT    1   8:17  4.49% {irq257: igb0:que}
    0 root       -68    0     0K   240K -       1   3:47  1.17% {igb1 que}
   12 root       -32    -     0K   464K WAIT    2   1:02  0.10% {swi4: clock}
    0 root        44    0     0K   240K sched   2   1:49  0.00% {swapper}
 2949 root        44  -15 37028K 14924K nanslp  2   1:27  0.00% perl5.12.4
 1220 root        44    0 50616K 14512K select  2   0:46  0.00% {mpd5}

[Lexx]

глубину причин не знаю
но лучше разкидать по процам вручную
procstat -at
и потом тридам некоторым сказать cpuset -t 1111 -l 0-1 (тоесть первый и второй процы)

[Demeo]

Код:

procstat -at | grep igb
    0 100031 kernel           igb0 que           2   16 sleep   -
    0 100033 kernel           igb0 que           3   16 sleep   -
    0 100035 kernel           igb0 que           1   16 sleep   -
    0 100037 kernel           igb0 que           1   16 sleep   -
    0 100040 kernel           igb1 que           1   16 sleep   -
    0 100042 kernel           igb1 que           2   16 sleep   -
    0 100044 kernel           igb1 que           0   16 sleep   -
    0 100046 kernel           igb1 que           0   16 sleep   -
   12 100030 intr             irq256: igb0:que   0   16 wait    -
   12 100032 intr             irq257: igb0:que   1   16 wait    -
   12 100034 intr             irq258: igb0:que   2   16 wait    -
   12 100036 intr             irq259: igb0:que   3   16 wait    -
   12 100038 intr             irq260: igb0:lin   3   16 wait    -
   12 100039 intr             irq261: igb1:que   0   16 wait    -
   12 100041 intr             irq262: igb1:que   1   16 wait    -
   12 100043 intr             irq263: igb1:que   2   16 wait    -
   12 100045 intr             irq264: igb1:que   3   16 wait    -
   12 100047 intr             irq265: igb1:lin   3   16 wait    -

Картина вроде адекватная, но вопрос все-таки почему?
А cpuset при перезагрузке сбросится?

[Lexx]

да, при перезагрузке надо опять устанавливать
в rc.local сделать небольшой скриптик

[Lexx]

а причины стоит искать в исходниках драйверов... что не совсем комфортно и нужно
cpuset нормально решает проблему

[Elisium]

А может мне кто-нить объяснить, почему на новых Интеловских дровах у меня прерывания входящей карточки распределяются на 4 ядра, а внутренняя (самая нагруженная сервисами) на одном висит?

[Чисто теория, полёт мысли...]
Если у тебя стоит МПД и принимает ПППчегототам и всё эти соединения находятся на одном (единственном) влане/физ. ифейсе, то, КАК ГДЕТО ПИСАЛИ (наг), интеловские дрова НЕ РАЗБРАСЫВАЮТ такой трафик на несколько потоков.
Причина - очереди (дрова) заточены под ТСП/УДП пакеты (пакеты попадают в разные очереди на основе заголовков Л3/4), а там ПППххх.

п.с. всё это выгребаю из глубин памяти. НО - при желании поиск рулит...

Апд: Таки да, рулит.. на слово Линукс НЕ СМОТРИМ .. смотрим "ширше" (С)
http://forum.nag.ru/forum/index.php?showtopic=60803

[Rico-X]

Причины и метод решения затронуты в этой статье http://dadv.livejournal.com/138951.html (3 части).

[Demeo]

Причины и метод решения затронуты в этой статье http://dadv.livejournal.com/138951.html (3 части).

Спасибо, статьи помогли немного разнести по ядрам (правда скрипт разноса прерываний по ядрам не работает)