Потери пакетов при увеличении нагрузки_v2
-
Ув. 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% -
Поэтому эта и называется "Потери пакетов при увеличении нагрузки_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 например) - возможно появится повод наехать на провайдера.
