Потери пакетов при увеличении нагрузки_v2



  • Имеем
    pfSense 1.2.3-RELEASE
    Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz
    Ram 2.0GB
    LAN-интерфейс RealTek 8101E/8102E/8102EL PCIe 10/100baseTX
    WAN-интерфейс VIA VT6105 Rhine III 10/100BaseTX
    HD 30GB
    over 150 users

    Потери пакетов видим на скринах.
    В приниципе, это не критично. Жалоб нет. Но потери пакетов есть.

    Что почем интересно было бы разобрать.
    Есть у кого-нибудь предположения? Предоставлю любые необходимые выводы











  • Дай увидем

    top -SPH
    netstat -i
    vmstat -z | egrep 'ITEM|mbuf'
    netstat -s output | grep drop
    sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
    pciconf -lvcb
    ipfw show



  • Ув. goliy , да перейдите Вы наконец на 2.0  ;D.
    Выгрузите конфиг из 1.2.3 –> поставьте 2.0 –> подгрузите конфиг.

    P.s. Возможно 1.2.3 не в состояние обрабатывать такой объем трафика  с таким кол-вом пользователей :-[



  • @werter:

    Ув. goliy , да перейдите Вы наконец на 2.0  ;D.
    Выгрузите конфиг из 1.2.3 –> поставьте 2.0 –> подгрузите конфиг.
    P.s. Возможно 1.2.3 не в состояние обрабатывать такой объем трафика  с таким кол-вом пользователей :-[
    [/quote]
    Во-первых, я сразу отмечаю, что это не критичная проблема, а пища для размышлений.

    Возможно 1.2.3 не в состояние обрабатывать такой объем трафика  с таким кол-вом пользователей :-[
    [/quote]
    Во-вторых, что это вообще такое значит?

    Выгрузите конфиг из 1.2.3 –> поставьте 2.0 –> подгрузите конфиг.

    переезд происходит, только все не так просто, как у вас расписано. К примеру, подгрузить конфиг от 1.2.3 версии на 2.0 вообще нельзя.










  • переезд происходит, только все не так просто, как у вас расписано. К примеру, подгрузить конфиг от 1.2.3 версии на 2.0 вообще нельзя.

    Я именно так переезжал.



  • Так, повторюсь, сейчас я тут не переезжаю, а потери расследую -)
    Почему то при прошлой попытке подгрузить конфиг от 1.2.3 я видел ошибку по типу "не вижу в предлагаемом файле параметров для рестора" или что-то похожее, что явно навело меня на умозаключении о несовместимости конфигов… Но сейчас и вправду, конфиг залился и отконвертился. Что, несомненно, радует. Спасибо за приятную новость, но все же я предпочитаю потратить время и переписать конфиг с чистого листа, чтобы все было чисто и правильно.
    Но вопрос-то не в этом. Почему пакеты теряются?

    pciconf -lvcb

    hostb0@pci0:0:0:0: class=0x060000 card=0x29c01849 chip=0x29c08086 rev=0x10 hdr=0x00
       class      = bridge
       subclass   = HOST-PCI
       cap 09[e0] = vendor (length 11) Intel cap 11 version 1
    vgapci0@pci0:0:2:0: class=0x030000 card=0x29c21849 chip=0x29c28086 rev=0x10 hdr=0x00
       class      = display
       subclass   = VGA
       bar   [10] = type Memory, range 32, base 0xfe980000, size 524288, enabled
       bar   [14] = type I/O Port, range 32, base 0xcc00, size  8, enabled
       bar   [18] = type Prefetchable Memory, range 32, base 0xe0000000, size 268435456, enabled
       bar   [1c] = type Memory, range 32, base 0xfe800000, size 1048576, enabled
       cap 05[90] = MSI supports 1 message
       cap 01[d0] = powerspec 2  supports D0 D3  current D0
    pcib1@pci0:0:28:0: class=0x060400 card=0x27d01849 chip=0x27d08086 rev=0x01 hdr=0x01
       class      = bridge
       subclass   = PCI-PCI
       cap 10[40] = PCI-Express 1 root port
       cap 05[80] = MSI supports 1 message
       cap 0d[90] = PCI Bridge card=0x27d01849
       cap 01[a0] = powerspec 2  supports D0 D3  current D0
    pcib2@pci0:0:28:1: class=0x060400 card=0x27d21849 chip=0x27d28086 rev=0x01 hdr=0x01
       class      = bridge
       subclass   = PCI-PCI
       cap 10[40] = PCI-Express 1 root port
       cap 05[80] = MSI supports 1 message
       cap 0d[90] = PCI Bridge card=0x27d21849
       cap 01[a0] = powerspec 2  supports D0 D3  current D0
    pcib3@pci0:0:30:0: class=0x060401 card=0x244e1849 chip=0x244e8086 rev=0xe1 hdr=0x01
       class      = bridge
       subclass   = PCI-PCI
       cap 0d[50] = PCI Bridge card=0x244e1849
    isab0@pci0:0:31:0: class=0x060100 card=0x27b81849 chip=0x27b88086 rev=0x01 hdr=0x00
       class      = bridge
       subclass   = PCI-ISA
       cap 09[e0] = vendor (length 12) Intel cap 1 version 0
    features: Quick Resume, SATA RAID-5, 6 PCI-e x1 slots, SATA RAID-0/1/10, SATA AHCI
    atapci0@pci0:0:31:1: class=0x01018a card=0x27df1849 chip=0x27df8086 rev=0x01 hdr=0x00
       class      = mass storage
       subclass   = ATA
       bar   [10] = type I/O Port, range 32, base 0x1f0, size  8, enabled
       bar   [14] = type I/O Port, range 32, base 0x3f4, size  1, enabled
       bar   [18] = type I/O Port, range 32, base 0x170, size  8, enabled
       bar   [1c] = type I/O Port, range 32, base 0x374, size  1, enabled
       bar   [20] = type I/O Port, range 32, base 0xffa0, size 16, enabled
    atapci1@pci0:0:31:2: class=0x01018f card=0x27c01849 chip=0x27c08086 rev=0x01 hdr=0x00
       class      = mass storage
       subclass   = ATA
       bar   [10] = type I/O Port, range 32, base 0xc080, size  8, enabled
       bar   [14] = type I/O Port, range 32, base 0xc000, size  4, enabled
       bar   [18] = type I/O Port, range 32, base 0xbc00, size  8, enabled
       bar   [1c] = type I/O Port, range 32, base 0xb880, size  4, enabled
       bar   [20] = type I/O Port, range 32, base 0xb800, size 16, enabled
       cap 01[70] = powerspec 2  supports D0 D3  current D0
    none0@pci0:0:31:3: class=0x0c0500 card=0x27da1849 chip=0x27da8086 rev=0x01 hdr=0x00
       class      = serial bus
       subclass   = SMBus
       bar   [20] = type I/O Port, range 32, base 0x400, size 32, enabled
    re0@pci0:1:0:0: class=0x020000 card=0x81361849 chip=0x813610ec rev=0x02 hdr=0x00
       class      = network
       subclass   = ethernet
       bar   [10] = type I/O Port, range 32, base 0xd800, size 256, enabled
       bar   [18] = type Prefetchable Memory, range 64, base 0xfdeff000, size 4096, enabled
       bar   [20] = type Prefetchable Memory, range 64, base 0xfdee0000, size 65536, enabled
       cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
       cap 05[50] = MSI supports 1 message, 64 bit enabled with 1 message
       cap 10[70] = PCI-Express 2 endpoint IRQ 0
       cap 11[ac] = MSI-X supports 2 messages in map 0x20
       cap 03[cc] = VPD
    vr0@pci0:3:2:0: class=0x020000 card=0x14051186 chip=0x31061106 rev=0x8b hdr=0x00
       class      = network
       subclass   = ethernet
       bar   [10] = type I/O Port, range 32, base 0xe800, size 256, enabled
       bar   [14] = type Memory, range 32, base 0xfebffc00, size 256, enabled
       cap 01[44] = powerspec 2  supports D0 D1 D2 D3  current D0




  • Покупите 2 EXPI9301CTBLK и замените лан карточки.
    http://www.intel.com/products/desktop/adapters/gigabit-ct/gigabit-ct-overview.htm

    От биоса изкл. все что не ползуете (соунд,усб,1394,разни райд контолера)

    ipfw show
    ipfw -d show | wc -l



  • Уже заказаны Intel pwla8391gt и E1G42ET. Но как могут создавать потери карты, которые фактически ничего умного не делают. Они же просто как "трубы".
    Что интересно по фаерволу? ipfw в pfsense не используется только pf + шейпинг на altq. Тут все стандартно. Вот как сейчас устроен мой шейпинг:

    queue qwanRoot bandwidth 19Mb priority 0 hfsc { qwandef, qwanacks, qP2PUp, qGamesUp, qOthersUpH }
    queue qlanRoot bandwidth 48Mb priority 0 hfsc { qlandef, qlanacks, qP2PDown, qGamesDown, qOthersDownH }
    queue qwandef bandwidth 0% priority 2 qlimit 500 hfsc (  ecn default upperlimit 97% linkshare(0% 3000 33%) realtime(37% 3000 1Kb) )
    queue qlandef bandwidth 0% priority 2 qlimit 500 hfsc (  ecn default upperlimit 97% linkshare(0% 5000 68%) realtime(62% 10000 1%) )
    queue qwanacks bandwidth 0% priority 7 qlimit 500 hfsc (  linkshare 25% realtime 35% )
    queue qlanacks bandwidth 0% priority 7 qlimit 500 hfsc (  linkshare 15% realtime 10% )
    queue qP2PUp bandwidth 0% priority 1 qlimit 2000 hfsc (  red ecn upperlimit 97% linkshare 1Kb )
    queue qP2PDown bandwidth 0% priority 1 qlimit 2000 hfsc (  red ecn upperlimit 97% linkshare 1Kb )
    queue qGamesUp bandwidth 0% priority 4 hfsc (  linkshare 20% realtime 6% )
    queue qGamesDown bandwidth 0% priority 4 hfsc (  upperlimit 30% linkshare 12% realtime 6% )
    queue qOthersUpH bandwidth 0% priority 6 hfsc (  ecn linkshare 1% realtime 1% )
    queue qOthersDownH bandwidth 0% priority 6 hfsc (  ecn linkshare 1% realtime 1% )

    В трубках ack живет еще трафик tcp на 53ий порт(DNS). A в othersdownH/upH ICMP и UDP dns



  • pwla8391gt е стар 82541PI чипсет. Замени на карточка с  82574L ( EXPI9301CTBLK) . E1G42ET  хорошая карточка с 82576 чипсет.На ети карточки можно балансират нагрузке :) (msi-x,interrupt moderation).
    Попробаи ипфв шеипер и каптиве портал.



  • для второй карточки только pci слот есть. так что 82574L не пойдет
    что предполагается под ипфв шейпером?
    При переезде на 2.0 попробую максимум шейпинга перенести на dummynet(для наконец-то реальной идеи из веб-интерфейса поделить полосу per host)
    Captive portal опять же для чего? Нее, тут что-то со не то, я думаю что-то отконфигурено не правильно в ядре. Только вот что - понять не могу. Конечно может я и не кривой, а просто пров дает канал не А+ качества. Что еще предстоит проверить.. Но пока не так-то просто это сделать



  • А с шейпером тоже потери?



  • Может вы имели ввиду "без шейпера"?
    Так-то шейпер всегда включен. Не понимаю, как может с вкл. шейпингом теряться Меньше?

    новый аттач. сегодня чего-то поплохело

    upd. Отключил шейпер. пинги бегают куда лучше. и потери нет. вроде как. Но надолго эксперимент затянуть не выйдет.










  • uberi pf sheipa.
    Sheip na pf dlq qos,narezka na kanal/trafic ,net dlia na usera.
    Poprobai sheip na limiter (ipfw/dummynet) .



  • Тут как-то была подобная тема, хотя там было существенно больше пользователей. И все же не будет лишним проверить, что у вас не переполняется State table.



  • Да-да, моя тема была -)
    Поэтому эта и называется "Потери пакетов при увеличении нагрузки_v2"
    Но там при переполнении table states'ов у нас потери были 100%



  • @goliy:

    Поэтому эта и называется "Потери пакетов при увеличении нагрузки_v2"

    Вот-вот, а посреди обсуждения выясняется, что должна называться "Потери пакетов при использовании шейпера", или по-другому "Пчёлы против мёда".  :)
    Шейпинг на уровне TCP/IP, особенно при отсутствии Random Early Detection, Explicit Congestion Notification и тупых клиентах, неизбежно вызывает потери пакетов при превышении лимита. А как вы хотели? В волшебство надеюсь не верите?



  • Я усердно верю, что RRD графики таки меряются по пингам на оперделенный RRD-сервер. А пинги у нас в отдельной трубе, без потерь с задержек, как и весь остальной ICMP траффик. Так что я не думаю, что  при текущих условиях потери распространяются и на них.

    queue   qOthersDownH on vr0 bandwidth 0 b priority 6 hfsc( red ecn realtime 480Kb linkshare 480Kb )
     [ pkts:       7210  bytes:     707522  dropped pkts:      0 bytes:      0 ]
     [ qlength:   0/ 50 ]



  • У вас канал провайдера зарезан по полосе? Даже если не зарезан, такое случается при сильной загрузке одного из вышестоящих маршрутизаторов. Не все так бережно относятся к протоколу ICMP.
    Ещё я бы обратил внимание на пингуемый хост - у него может превышаться лимит на зхо.
    Для уверенности стоит по-тестировать канал ( iperf например) - возможно появится повод наехать на провайдера.


Locked