Перейти к содержимому
Калькуляторы

NAS на FreeBSD 9.0. Тестирование под нагрузкой.

Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов.

 

Полная чушь. Никакого прохода ни по какому списку интерфейсов в этом случае не выполняется (да и не за чем). Буквально выполняется сравнение первых двух символов имени интерфейса пакета с 'n' и 'g'.

 

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

Изменено пользователем littlesavage

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Настало время отметиться здесь.

 

На всех трех серверах паники не было, но впервые столкнулись с невиданным ранее сбоем mpd-5.6. Закончилась вся память, SWAP-раздел мы не организовываем на маррутизаторах с SSD-дисками. MPD оставил все туннели как есть а сам вылетел с криками о попытках проникнуть в своп, котрого нет. 450 ng интерфейсов так и остались висеть, но траф по ним уже не шел. При рестарте mpd эти мёртвые ng-шки так и оставались в вистеме. Пришлось отправить ось в ребут. Сразу добавили графики RAM-а в cacti (не на всех серверах они были добавлены в свое время). И теперь наблюдаем такую картину. На всех серверах с 7.4-STABLE и 9.0-STABLE горизонтальная планка 24/7:

 

graphimage.png

 

Uploaded with ImageShack.us

 

И на одном серваке вот такая картина:

 

graphimage1.png

 

Uploaded with ImageShack.us

 

Сам mpd жрёт < 300 Mb. В top ничего подозрительного не замечено. Куда девается память? С другой стороны если считать mem+buf+free=free то никуда она не девается судя по графику.

Изменено пользователем kaN5300

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И на одном серваке вот такая картина:

Сам mpd жрёт < 300 Mb.

Много.

 

В top ничего подозрительного не замечено. Куда девается память? С другой стороны если считать mem+buf+free=free то никуда она не девается судя по графику.

vmstat -m.

Графики мне напомнили давным давно пофикшенный kern/145865.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

         Type InUse MemUse HighUse Requests  Size(s)
       sigio     1     1K       -        1  64
    filedesc    48    49K       -   336446  16,32,64,128,512,1024,2048,4096
        kenv    90    11K       -      101  16,32,64,128
      kqueue     0     0K       -     3422  256,2048
   proc-args    26     2K       -   159407  16,32,64,128,256
       hhook     2     1K       -        2  128
    acpitask     1     2K       -        1  2048
     ithread   134    21K       -      134  32,128,256
CAM dev queue     5     1K       -        5  128
   CAM queue    17     1K       -       86  16,32
      KTRACE   100    13K       -      100  128
     acpisem    18     3K       -       18  128
      linker   223   122K       -      282  16,32,64,128,256,512,1024,2048,4096
       lockf    26     3K       -      478  64,128
  loginclass     1     1K       -     1043  64
     CAM SIM     5     2K       -        5  256
        temp  1609    66K       - 21859887  16,32,64,128,256,512,1024,2048,4096
      devbuf   722  6957K       -      738  16,32,64,128,256,512,1024,2048,4096
      module   275    35K       -      275  128
    mtx_pool     2    16K       -        2
     ata_pci     2     1K       -        2  64
  CAM periph     4     1K       -       20  16,32,64,128,256
     subproc   286   290K       -   335305  512,4096
        proc     2    16K       -        2
     session    23     3K       -     1079  128
        pgrp    24     3K       -     1124  128
        cred    38     6K       -  2955072  64,256
     uidinfo     5     3K       -   124845  128,2048
      plimit    13     4K       -   182753  256
     CAM XPT    39    22K       -      139  32,64,128,1024,2048
   sysctltmp     0     0K       -  1739034  16,32,64,128,256,4096
   sysctloid  6321   317K       -     6447  16,32,64,128
      sysctl     0     0K       -   399196  16,32,64
     tidhash     1    16K       -        1
     callout     5  2560K       -        5
        umtx  1716   215K       -     1716  128
    p1003.1b     1     1K       -        1  16
      bus-sc   101   100K       -     3590  16,32,128,256,512,1024,2048,4096
         bus   869    87K       -    39975  16,32,64,128,256,1024,2048
     devstat     8    17K       -        8  32,4096
eventhandler    76     6K       -       76  64,128
      kbdmux     6    18K       -        6  16,512,1024,2048
        kobj   176   704K       -      271  4096
     Per-cpu     1     1K       -        1  32
         LED     8     1K       -        8  16,128
        rman   266    31K       -      666  16,32,128
        sbuf     1     1K       -    56033  16,32,64,128,256,512,1024,2048,4096
       stack     0     0K       -        2  256
   taskqueue    47     4K       -       47  16,32,128
      Unitno    15     1K       -  1780545  32,64
         iov     0     0K       -    15558  16,64,128,256,512
      select   760    95K       -      760  128

    ioctlops     0     0K       - 39179996  16,32,64,128,256,512,1024
         msg     4    30K       -        4  2048,4096
         sem     4   106K       -        4  2048,4096
         shm     1    20K       -        1
         tty    20    20K       -       27  1024,2048
         pts     1     1K       -        6  256
    mbuf_tag   105     4K       - 3686550832  32,64
       shmfd     1     8K       -        1
      DEVFS1    83    42K       -      104  512
         pcb    34   158K       -  1727443  16,32,64,128,1024,2048,4096
      soname     4     1K       - 56304997  16,32,128
         acl     0     0K       -     1561  4096
    vfscache     1  1024K       -        1
  cl_savebuf     0     0K       -       27  64
    vfs_hash     1   512K       -        1
      DEVFS3    99    25K       -      133  256
      vnodes     2     1K       -        2  256
 vnodemarker     0     0K       -    48773  512
       mount    61     3K       -      131  16,32,64,128,256
         BPF   788    99K       -     8853  128
 ether_multi  1576    62K       -    16546  16,64
      ifaddr  2393   817K       -    26007  32,512,4096
       ifnet   789  1584K       -     8860  128,256,512,1024,2048,4096
       clone     5    20K       -        5  4096
      arpcom     5     1K       -        5  16
     lltable  1229   505K       -    10443  256,512
       DEVFS    15     1K       -       16  16,128
    routetbl   934   165K       -   230081  32,64,128,256,512
netflow_hash     1  3072K       -        1
netflow_general     1     1K       -        1  256
netgraph_msg     0     0K       - 24217550  64,128,256,512,1024
netgraph_node  7130  1783K       -   144452  256
netgraph_hook 20112  2514K       -   330418  128
    netgraph  5611 11213K       -    91792  64,128,256,512,1024,4096
netgraph_iface   782    98K       -     8847  128
netgraph_ksock   784    98K       -    13928  128
netgraph_sock     4     1K       -    43306  128
netgraph_path     0     0K       - 12390542  16,32
        igmp   788   197K       -     8853  256
    in_multi   785   197K       -     8269  256
 IpFw/IpAcct    18     3K       -       32  16,32,64,128
    ipfw_tbl  5250  1313K       -    10748  256
   sctp_iter     0     0K       -        3  256
    sctp_ifn     3     1K       -        3  128
    sctp_ifa     4     1K       -        4  128
    sctp_vrf     1     1K       -        1  64
   sctp_a_it     0     0K       -        3  16
   hostcache     1    28K       -        1
    syncache     1    96K       -        1
    libalias 482503 60441K       - 244360384  128
     sctpnat     6    80K       -        6
         rpc     2     1K       -        2  256
audit_evclass   179     6K       -      218  32

     jblocks     8     2K       -        8  128,256
    savedino     0     0K       -      291  256
       sbdep     0     0K       -     2266  64
     jsegdep     0     0K       -    21436  64
        jseg     0     0K       -     5304  128
   jfreefrag     0     0K       -      159  128
     jnewblk     0     0K       -    15739  128
     jremref     0     0K       -     2765  128
     jaddref     0     0K       -     2773  128
     freedep     0     0K       -       35  64
    freework     1     2K       -      606  128,2048
   newdirblk     0     0K       -        6  64
      dirrem     0     0K       -     2753  128
       mkdir     0     0K       -       12  128
      diradd     0     0K       -     2761  128
    freefile     0     0K       -      472  64
    freeblks     0     0K       -      471  128
    freefrag     0     0K       -      159  128
    indirdep     0     0K       -     2097  128
      newblk     1   128K       -    15740  256
   bmsafemap     2     9K       -     2327  256
    inodedep     2   513K       -     5176  512
     pagedep     2   129K       -      422  256
 ufs_dirhash   858   183K       -      864  16,32,64,128,256,512
   ufs_mount    12    50K       -       12  512,4096
   vm_pgdata     1   128K       -        1
     UMAHash     3    13K       -       10  512,1024,2048,4096
     memdesc     1     4K       -        1  4096
    atkbddev     2     1K       -        2  64
   pfs_nodes    21     6K       -       21  256
        GEOM    59    11K       -      782  16,32,64,128,256,512,1024
     acpidev    52     4K       -       52  64
    pci_link    16     2K       -       16  64,128
      apmdev     1     1K       -        1  128
   acpi_perf     6     3K       -        6  512
    acpiintr     1     1K       -        1  64
      isadev     5     1K       -        5  128
      qpidrv     1     1K       -        1  16
     io_apic     1     2K       -        1  2048
     entropy  1024    64K       -     1024  64
         MCA     7     1K       -        7  64,128
         msi    20     3K       -       20  128
    nexusdev     4     1K       -        4  16
        cdev     7     2K       -        7  256
      acpica  4954   536K       -    76964  16,32,64,128,256,512,1024,2048,4096
        UART     6     4K       -        6  16,512,1024
netgraph_mppc     0     0K       -        1  1024
netgraph_ppp   782  9384K       -     8847
netgraph_bpf  8772  1097K       -   123364  128

 

Перешел по ссылке, глянул сисктл, hw.bus.devctl_disable: 0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По идее можно написать скриптик который будет убивать ноды через ngctl в случае вылета mpd5.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По идее можно написать скриптик который будет убивать ноды через ngctl в случае вылета mpd5.

 

Это понятно, но хотелось бы обнаружить причину всех бед, т.к. аналогичный сервак (по софту и нагрузке) работает стабильно.

 

Вчера ночью перезагрузили mpd (первый скачек на графике) и потом еще крон видимо что-то делал, прибавился еще cached. Ждём когда free опустится до нуля и будем смотреть, повторится ли замеченный ранее симптом.

 

graphimage2t.png

 

Uploaded with ImageShack.us

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обнаружил кое-какое расхождение в конфиге с другими NAS-серверами на 9.0, подправил и обновил через portupgrade кваггу и все required порты. Заодно подтянул новые исходники через cvsup и пересобрал мир с ядром. Осталось ребутнуть. Во время этих мероприятий Memory free резко подскочило, а Cache соответственно уменьшился

 

graphimage3.png

 

Uploaded with ImageShack.us

 

Теперь стало заметно что утекает память относительно своего исходного размера. 24 назад было 1610, сейчас на 300 мегов меньше. Есть подозрение, что mpd зависнет когда абсолютно вся память таким образом исчезнет. Но дожидаться мы этого не будем, произведем ребут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обнаружил кое-какое расхождение в конфиге с другими NAS-серверами на 9.0, подправил и обновил через portupgrade кваггу и все required порты. Заодно подтянул новые исходники через cvsup и пересобрал мир с ядром. Осталось ребутнуть. Во время этих мероприятий Memory free резко подскочило, а Cache соответственно уменьшился

 

graphimage3.png

 

Uploaded with ImageShack.us

 

Теперь стало заметно что утекает память относительно своего исходного размера. 24 назад было 1610, сейчас на 300 мегов меньше. Есть подозрение, что mpd зависнет когда абсолютно вся память таким образом исчезнет. Но дожидаться мы этого не будем, произведем ребут.

у вас память переходит в Inactive?? Дело в том , что у меня почти на всех насах так. И по 2 месяца уже пашут. freemem 150 мб обычно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Перезагрузили:

 

graphimage4.png

 

Uploaded with ImageShack.us

 

Всё равно тенденция не здоровая. Будем смотреть за состоянием mpd теперь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Илья ну что решил свою проблему? Короче у меня проблема аналогичная и вот какая:

Есть Роутер софтовый на FreeBSD 9.0R i386, netgraph через tee генерит netflow, NAT через PF (очень мало), шейпит IPFW (dummynet), IPv6 в ядре включен

Сетевая карточка i350 - Quad PORT

 

ядро:

options         NETGRAPH
options         IPFIREWALL
options         IPDIVERT
options         IPSTEALTH
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=100
options         IPFIREWALL_FORWARD
options         DUMMYNET
options         HZ=1000


# pf
device          pf
device          pflog
device          pfsync

 

Также настроен Quagga OSPF отдает маршрут по умолчанию и получает порядка 1к маршрутов

Вообщем железо все проверил, сеть.карточки менял.

Суть в том что роутер перегружается произвольно после (1-40 минут) добавления в ospfd.conf

default-information originate always metric 1 metric-type 1 (т.е. чтобы роутер анонсил себя в качестве шлюза) как только побежал трафик сервак произвольно перегружается.

Кернел Дампы не пишет. Из того что мне удалось выяснить:

отключил модули

 

kldload ng_ipfw

kldload ng_ether

kldload ng_tee

kldload ng_netflow

 

Ессено трафик пока не считается,

пока полет нормальный, нужно ждать. Так вот что то подсказывает мне, что изменения относительно netflow v9 в FreeBSD 9.0 некорректно работают с IPv6

 

У кого какие идеи?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Привет, Виталий!

 

У нас ребуты пропали после перехода на архитектуру AMD64 и выкидывания из ядра IPV6.

 

<kan5300@nas1>uptime
3:48PM  up 112 days, 15:29, 2 users, load averages: 2.63, 2.20, 2.05

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня два сервера с 9.0 в продакшене работают с лета без единой проблемы. Тоже сетёвка i350 с lagg, NAT + dummynet + ng_netflow. IPv6 включен (и на одном даже используется), архитектура amd64.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня два сервера с 9.0 в продакшене работают с лета без единой проблемы. Тоже сетёвка i350 с lagg, NAT + dummynet + ng_netflow. IPv6 включен (и на одном даже используется), архитектура amd64.

У нас тоже работает нормально, но IPv6 пришло отключить, так как наблюдаются проблемы: mpd5 + quagga.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Помогите разобраться что за чудева творятся, 2 NASa на freebsd 9.1 amd64

Первый: 2 x XEONA 6 ядерных с 2портовой intel (igb) сетевухой:

Функционал: radius, mpd5, netgraph (шейпер)

при нагрузке:

 

 

 

# netstat -w1 -h -Iigb0
           input         (igb0)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
      15k     0     0        14M        14k     0       6.8M     0
      14k     0     0        12M        13k     0       6.4M     0
      16k     0     0        15M        15k     0       6.6M     0
      13k     0     0        11M        14k     0       6.9M     0

----
last pid: 71625;  load averages:  6.33,  7.94,  8.85                                                                                    up 0+11:43:08  13:45:39
289 processes: 29 running, 198 sleeping, 2 zombie, 60 waiting
CPU 0:   0.0% user,  0.0% nice,  2.3% system, 22.1% interrupt, 75.6% idle
CPU 1:   0.8% user,  0.0% nice,  2.3% system, 29.8% interrupt, 67.2% idle
CPU 2:   0.0% user,  0.0% nice,  4.6% system, 27.5% interrupt, 67.9% idle
CPU 3:   0.0% user,  0.0% nice,  1.5% system, 24.4% interrupt, 74.0% idle
CPU 4:   0.0% user,  0.0% nice,  2.3% system, 13.0% interrupt, 84.7% idle
CPU 5:   0.0% user,  0.0% nice,  0.0% system, 22.1% interrupt, 77.9% idle
CPU 6:   0.0% user,  0.0% nice,  2.3% system, 23.7% interrupt, 74.0% idle
CPU 7:   0.0% user,  0.0% nice,  0.0% system, 23.7% interrupt, 76.3% idle
CPU 8:   0.0% user,  0.0% nice,  4.6% system,  6.1% interrupt, 89.3% idle
CPU 9:   0.0% user,  0.0% nice,  9.2% system,  0.0% interrupt, 90.8% idle
CPU 10:  0.0% user,  0.0% nice, 10.7% system,  0.0% interrupt, 89.3% idle
CPU 11:  0.0% user,  0.0% nice, 17.6% system,  0.0% interrupt, 82.4% idle
CPU 12:  0.0% user,  0.0% nice, 13.0% system,  0.0% interrupt, 87.0% idle
CPU 13:  0.0% user,  0.0% nice, 20.6% system,  0.0% interrupt, 79.4% idle
CPU 14:  0.0% user,  0.0% nice, 16.8% system,  0.0% interrupt, 83.2% idle
CPU 15:  0.8% user,  0.0% nice, 22.1% system,  0.0% interrupt, 77.1% idle
CPU 16:  0.0% user,  0.0% nice, 19.8% system,  0.0% interrupt, 80.2% idle
CPU 17:  0.0% user,  0.0% nice, 18.3% system,  0.0% interrupt, 81.7% idle
CPU 18:  0.0% user,  0.0% nice, 18.3% system,  0.0% interrupt, 81.7% idle
CPU 19:  0.0% user,  0.0% nice, 18.3% system,  0.0% interrupt, 81.7% idle
CPU 20:  3.1% user,  0.0% nice, 16.8% system,  0.0% interrupt, 80.2% idle
CPU 21:  0.8% user,  0.0% nice, 23.7% system,  0.0% interrupt, 75.6% idle
CPU 22:  0.0% user,  0.0% nice, 21.4% system,  0.0% interrupt, 78.6% idle
CPU 23:  0.0% user,  0.0% nice, 20.6% system,  0.0% interrupt, 79.4% idle
Mem: 130M Active, 705M Inact, 955M Wired, 417M Buf, 2130M Free
Swap: 4096M Total, 4096M Free

 PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  11 root     155 ki31     0K   384K CPU10  10 665:48 93.36% idle{idle: cpu10}
  11 root     155 ki31     0K   384K CPU9    9 672:06 89.89% idle{idle: cpu9}
  11 root     155 ki31     0K   384K RUN     8 661:47 88.57% idle{idle: cpu8}
  11 root     155 ki31     0K   384K CPU11  11 664:58 88.28% idle{idle: cpu11}
  11 root     155 ki31     0K   384K RUN    15 624:01 81.98% idle{idle: cpu15}
  11 root     155 ki31     0K   384K CPU19  19 622:58 80.57% idle{idle: cpu19}
  11 root     155 ki31     0K   384K CPU22  22 623:50 79.59% idle{idle: cpu22}
  11 root     155 ki31     0K   384K CPU0    0 588:43 79.39% idle{idle: cpu0}
  11 root     155 ki31     0K   384K CPU16  16 624:53 79.30% idle{idle: cpu16}
  11 root     155 ki31     0K   384K CPU12  12 626:01 78.47% idle{idle: cpu12}
  11 root     155 ki31     0K   384K CPU13  13 624:44 77.49% idle{idle: cpu13}
  11 root     155 ki31     0K   384K CPU21  21 622:56 77.10% idle{idle: cpu21}
  11 root     155 ki31     0K   384K CPU4    4 593:10 77.10% idle{idle: cpu4}
  11 root     155 ki31     0K   384K CPU14  14 625:34 76.76% idle{idle: cpu14}
  11 root     155 ki31     0K   384K CPU18  18 624:14 76.46% idle{idle: cpu18}
  11 root     155 ki31     0K   384K CPU23  23 622:01 75.39% idle{idle: cpu23}
  11 root     155 ki31     0K   384K RUN    20 624:02 74.85% idle{idle: cpu20}
  11 root     155 ki31     0K   384K RUN    17 623:24 74.56% idle{idle: cpu17}
  11 root     155 ki31     0K   384K CPU5    5 596:37 74.17% idle{idle: cpu5}
  11 root     155 ki31     0K   384K CPU2    2 599:30 69.48% idle{idle: cpu2}
  11 root     155 ki31     0K   384K CPU3    3 572:30 66.99% idle{idle: cpu3}
  11 root     155 ki31     0K   384K CPU7    7 581:33 66.80% idle{idle: cpu7}
  11 root     155 ki31     0K   384K CPU1    1 594:19 62.79% idle{idle: cpu1}
  11 root     155 ki31     0K   384K CPU6    6 599:50 62.60% idle{idle: cpu6}
  12 root     -92    -     0K   960K WAIT    1  85:58 37.79% intr{irq257: igb0:que}
  12 root     -92    -     0K   960K WAIT    6  85:29 37.35% intr{irq262: igb0:que}
  12 root     -92    -     0K   960K WAIT    2  86:38 29.20% intr{irq258: igb0:que}
  12 root     -92    -     0K   960K WAIT    7 101:38 29.05% intr{irq263: igb0:que}

 

 

 

В то же время есть второй NAS на i3 c em драйверами:

 

 

last pid: 98036;  load averages:  1.39,  1.49,  1.54                                                                                    up 0+13:05:00  13:51:13
111 processes: 6 running, 87 sleeping, 18 waiting
CPU 0:  0.0% user,  0.0% nice, 54.8% system,  0.0% interrupt, 45.2% idle
CPU 1:  0.0% user,  0.0% nice, 16.1% system,  6.5% interrupt, 77.4% idle
CPU 2:  0.0% user,  0.0% nice, 32.3% system,  0.0% interrupt, 67.7% idle
CPU 3:  0.0% user,  0.0% nice, 35.5% system,  0.0% interrupt, 64.5% idle
Mem: 34M Active, 777M Inact, 495M Wired, 6080K Cache, 209M Buf, 616M Free
Swap: 4096M Total, 4096M Free

 PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  11 root     155 ki31     0K    64K RUN     1 683:14 77.39% idle{idle: cpu1}
  11 root     155 ki31     0K    64K RUN     3 645:47 71.78% idle{idle: cpu3}
  11 root     155 ki31     0K    64K CPU2    2 642:18 67.77% idle{idle: cpu2}
  11 root     155 ki31     0K    64K RUN     0 570:15 51.46% idle{idle: cpu0}
   0 root     -92    0     0K   224K CPU0    0 192:43 44.97% kernel{em0 que}
  13 root     -16    -     0K    64K sleep   2  84:00 23.00% ng_queue{ng_queue1}
  13 root     -16    -     0K    64K sleep   1  84:08 22.75% ng_queue{ng_queue0}
  13 root     -16    -     0K    64K sleep   2  83:57 22.36% ng_queue{ng_queue2}
  13 root     -16    -     0K    64K sleep   1  83:59 21.19% ng_queue{ng_queue3}
  12 root     -92    -     0K   288K WAIT    2  36:13  9.47% intr{irq265: em1:rx 0}
  12 root     -92    -     0K   288K WAIT    2   7:31  1.66% intr{irq266: em1:tx 0}
 927 root      20    0   202M 41504K select  1   5:22  0.49% mpd5{mpd5}
 995 root      20    0 31668K  4420K select  3   0:13  0.10% zebra
  12 root     -60    -     0K   288K WAIT    1   3:57  0.00% intr{swi4: clock}
   0 root     -92    0     0K   224K -       1   2:14  0.00% kernel{dummynet}
1101 root      20    0 37996K  9240K uwait   0   1:25  0.00% utm5_radius{utm5_radius}
  15 root     -16    -     0K    16K -       1   1:18  0.00% yarrow

при нагрузке:

# netstat -w1 -h -Iem0
           input          (em0)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
      20k     0     0        21M        16k     0       6.7M     0
      21k     0     0        23M        16k     0       7.1M     0
      22k     0     0        24M        17k     0       7.7M     0

 

 

 

После увиденного начал крутить тюнинг, но нагрузки смешные.

В часы пик (до 300-400Мбит/с на роутер) нагрузка на мощном сервере возрастает до 20 average и все заваливается очередями.

 

Накрутил до такого:

# less /boot/loader.conf 
netgraph_load="YES"
ng_ipfw_load="YES"
ng_car_load="YES"
ng_nat_load="YES"
autoboot_delay="1"
kern.ipc.maxpipekva="32000000"
hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.max_interrupt_rate=32000

# less /etc/sysctl.conf 
# $FreeBSD: src/etc/sysctl.conf,v 1.8.38.1 2010/12/21 17:10:29 kensmith Exp $
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0
net.inet.ip.forwarding=1
net.inet.ip.fastforwarding=1
net.inet.ip.redirect=0
net.inet.ip.intr_queue_maxlen=10240
net.inet.tcp.delayed_ack=0
net.inet.tcp.sendspace=3217968
net.inet.tcp.recvspace=3217968
net.inet.tcp.blackhole=2
net.inet.tcp.drop_synfin=1
net.inet.udp.recvspace=65535
net.inet.udp.maxdgram=57344
net.inet.udp.blackhole=1
net.inet.icmp.drop_redirect=1
net.inet.icmp.icmplim=200
net.inet.icmp.drop_redirect=1
kern.ipc.nmbclusters=400000
kern.ipc.somaxconn=8192
kern.ipc.maxsockbuf=83886080
kern.ipc.maxsockets=204800
kern.ipc.shmall=8388608
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
net.link.ether.inet.proxyall=1
net.inet.tcp.tso=0
net.graph.maxdgram=8388608
net.graph.recvspace=8388608
dev.igb.0.rx_processing_limit=-1
dev.igb.1.rx_processing_limit=-1

но и это не спасло.

 

Правила ipfw:

# ipfw show
00010     181884      16382428 deny ip from any to table(50) dst-port 135-139,445
00010     187498      17600048 deny ip from table(50) to any dst-port 135-139,445
00030          6           264 deny ip from any to table(20) dst-port 22
00060   20178202    5843214445 allow ip from 172.16.0.0/16 to 10.0.0.0/8
00060    4935741     349274219 allow ip from 10.0.0.0/8 to 172.16.0.0/16
00099    4601461     549651491 allow ip from any to any via lo0
00180  919184129  425389336692 allow ip from 10.0.0.0/8 to 10.0.0.0/8 in recv igb1
00180 1196334153 1065094085564 allow ip from 10.0.0.0/8 to 10.0.0.0/8 out xmit igb1
00210    6833708     685236677 allow ip from 172.16.0.0/16 to 172.16.0.0/16
00240    1495928     399786619 allow ip from any to me
00250    2149835     230655428 allow ip from me to any
01000   34531407   30906027365 allow ip from any to table(30)
01000   30950224   14061136330 allow ip from table(30) to any
03000     280389     135646215 netgraph tablearg ip from table(105) to any in recv ng*
03000     301370     289195850 netgraph tablearg ip from any to table(110) out xmit ng*
03500  849038581  374112825085 allow ip from table(100) to any
03500 1057548376 1046505656451 allow ip from any to table(100)
04000    1385327    1911201279 allow ip from table(99) to any
04000     731285      51537058 allow ip from any to table(99)
04100      33872       2621244 allow ip from 192.168.0.254 to any
04100          4           200 allow ip from any to 192.168.0.254
65535   34711897    5723493059 deny ip from any to any

Отключил netgraph (шейпер) на проблемном сервере и нагрузка нормализовалась:

Посоветуйте

post-6752-057733800 1356283586_thumb.png

Изменено пользователем kirush

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1) На проблемном сервере после резкого увеличения lavg выполнить "vmstat -z|grep items"

2) Шейпирование реализовано через shape или rate-limit?

3) hyper-threading я бы отключил

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1) На проблемном сервере после резкого увеличения lavg выполнить "vmstat -z|grep items"

2) Шейпирование реализовано через shape или rate-limit?

3) hyper-threading я бы отключил

 

1)

Проблемный:

# vmstat -z|grep items

NetGraph items: 104, 4118, 39, 3354,932282611, 0, 0

NetGraph data items: 104, 522, 1, 521,3937276999,5336084, 0

Нормальный:

# vmstat -z|grep items

NetGraph items: 72, 4118, 52, 441,1108945697, 0, 0

NetGraph data items: 72, 522, 0, 522,3870054604,20029, 0

Очень станно, что на проблемном в 2 раза больше items, сервера идентичны на 100%

2) через ng_car :)

3) не мешал на 7.2 (была до этого).

Изменено пользователем kirush

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1) На проблемном сервере после резкого увеличения lavg выполнить "vmstat -z|grep items"

2) Шейпирование реализовано через shape или rate-limit?

 

2) через ng_car :)

 

имелось ввиду mpd-limit all shape или mpd-limit rate-limit?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подозреваю что rate-limit меньше требователен к ресурсам в отличие от shape. Мы применяли shape во времена тарифов по 128k. Потом перешли на limit. На самом последнем насе у нас по всем счётчикам vmstat только в одном месте есть отклонение счетчика фейлов (128 Bucket: 22135). Остальные все нули.

 

Попробуй по библии dadv'а сделать:

 

net.graph.maxdata=65536

net.graph.maxalloc=65536

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как вы думаете, что происходит с системой, когда пакет передаётся между ядрами разных процов?

Простой=блокировка выполнения потока. При этом шедулер ОС считает что время простоя=время работы.

И сравнение не корректное из за настроек и различий железа: у ем одно прерывание, а у игб их больше, при ваших настройках вся (до нетграфа) обработка пакетов происходит в обработчике прерывания.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отказаться от планировщика выключив гипер-трединг и прибив процессы к ядрам как вариант. Но с другой стороны у нас насы с сервисами all-in-one тащат по 40-50 kpps в ЧНН с дефолтным шедулером из 9.0 и четырьмя ядрами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А не в том ли смысл, что на "24 ядерном" пиковая нагрузка при 100% будет 24 lavg

А на слабенькой машине i3 пик будет 4lavg?

и тогда получается что с картинками все ок?

Изменено пользователем kirush

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А не в том ли смысл, что на "24 ядерном" пиковая нагрузка при 100% будет 24 lavg

А на слабенькой машине i3 пик будет 4lavg?

и тогда получается что с картинками все ок?

 

Невозможно будет каждый процессор забить на 100%. К тому же lavg это такой абстрактный параметр, с единой интерпретацией которого даже гуру не могут определиться: http://www.teamquest.com/pdfs/whitepaper/ldavg1.pdf

 

Экспериментальным путём я выяснил что при увеличении значения load average 15m больше 3.0 на многопроцессорном (многоядерном) сервер доступа начинаются явные проблемы. По этому стараюсь выводить такие сервера из DNS до восстановления этих значений в норму.

 

Еще заметил что порой может рандомно на каком-то из насов lavg резко взлететь до 40 например и в таком состоянии сервер будет находиться минут 20. Такое бывает очень редко. Раз в месяц примерно. Возможно связано с нетипичным трафиком с зараженного компа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Kirush, проблема больше не проявляется?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас