Потери пакетов при увеличении нагрузки
-
pingtest.net - это не совсем пинг, вернее совсем не он, не ICMP. Там с вашей машины летят пакетики на TCP или UDP порт 8080 удаленного сервера. И вот только pfsense знает в какую очередь шейпера они попадают, какой у нее приоритет и насколько она загружена вашими пользователями.
Что касается RRD Quality, то там, насколько я понял, задержки и потери пакетов определяются постоянным пингом шлюза с WANa pfSense. Как-то трудно представить себе сценарий, при котором вся ваша остальная инфраструктура могла бы на этот график хоть как-то влиять. Единственное исключение - конкретный перегруз канала. Ну еще, учитывая, что upload трафик шейпится на выходе с WAN, возможны варианты.
Отключите шейпер в момент максимальной нагрузки и посмотрите что будет. Если все нормально, то причем тут свитчи и сетевые карты? -
Кроме того, freebsd 7.2 не поддерживает никакие 100мегабитные карты Интела
:D чукча не читатель, чукча писатель :D
http://www.freebsd.org/releases/7.2R/hardware.html#ETHERNET
Adapters supported by the fxp(4) driver include:
Intel EtherExpress PRO/10
Intel InBusiness 10/100
Intel PRO/100B / EtherExpressPRO/100 B PCI Adapter
Intel PRO/100+ Management Adapter
Intel PRO/100 VE Desktop Adapter
Intel PRO/100 VM Network Connection
Intel PRO/100 M Desktop Adapter
Intel PRO/100 S Desktop, Server and Dual-Port Server Adapters
Contec C-NET(PI)-100TX (PC-98)
NEC PC-9821Ra20, Rv20, Xv13, Xv20 internal 100Base-TX (PC-98)
NEC PC-9821X-B06 (PC-98)
Many on-board network interfaces on Intel motherboards
http://www.freebsd.org/cgi/man.cgi?query=fxp&sektion=4&manpath=FreeBSD+7.2-RELEASE
The fxp driver provides support for Ethernet adapters based on the Intel
i82557, i82558, i82559, i82550, and i82562 chips. The driver supports
TCP/UDP/IP checksum offload for both transmit and receive on i82550 and
i82551. On i82559 only TCP/UDP checksum offload for receive is sup-
ported. TCP segmentation offload (TSO) for IPv4 as well as VLAN hardware
tag insertion/stripping is supported on i82550 and i82551. Wake On Lan
(WOL) support is provided on all controllers except i82557, i82259ER and
early i82558 revisions. -
Да, признаю, что ошибся с картами. Криво смотрел. Спасибо, что показали.
-
pingtest.net - это не совсем пинг, вернее совсем не он, не ICMP. Там с вашей машины летят пакетики на TCP или UDP порт 8080 удаленного сервера. И вот только pfsense знает в какую очередь шейпера они попадают, какой у нее приоритет и насколько она загружена вашими пользователями.
Что касается RRD Quality, то там, насколько я понял, задержки и потери пакетов определяются постоянным пингом шлюза с WANa pfSense. Как-то трудно представить себе сценарий, при котором вся ваша остальная инфраструктура могла бы на этот график хоть как-то влиять. Единственное исключение - конкретный перегруз канала. Ну еще, учитывая, что upload трафик шейпится на выходе с WAN, возможны варианты.
Отключите шейпер в момент максимальной нагрузки и посмотрите что будет. Если все нормально, то причем тут свитчи и сетевые карты?При отключении шейпера при нагрузках трафик забивается торрентами на 100%, что влечет за собой большое увеличение времени пинга, что влечет за собой аналогичные проблемы с юзабилити - никакие реал-тайм пиложения не работают, даже ДНСки перестают отвечать.
Так что сам я уже думал об этом, что дело в шейпере, но в любом случае он должен работать и в случае его вины - очень нуждаюсь в помощи по его настройке.Сегодня в момент нагрузки попробую протестировать командами ping host с сервера и с клиентов с отключенным и включенным шейпингом и отпишу что получилось.
–----------------------------------------------------------------------------------------------
21:00, нагрузка стандартна.
И, о чудо! Либо сегодня все пользователи отключили свои ботнеты, либо проблема крылась в глючной сетевухе D-link DGE-528T, которую сегодня утром успешно сменила DFE-530TX на нелегком её посту. И потери приблизились к более-менее нормальным(/допустымым), на мой взгляд. Итак:При включенном шейпере:
на RRD все терпимо(я бы даже сказал на 4+, потерь почти совсем нет), pingtest.net показывает, что потери не привышают 1-2%(изредка долетает до 8-12), 80 процентов замеров показали 0% потерь
ping host с сервера не выявил потерь,
пинг хост с клиента:
замер 1--- ya.ru ping statistics ---
2381 packets transmitted, 2326 received, 2% packet loss, time 3241083ms, что, я думаю, тоже терпимо, хоть и не идеально.
замер 2--- ya.ru ping statistics ---
209 packets transmitted, 195 received, 6% packet loss, time 316615ms
rtt min/avg/max/mdev = 3.175/4.501/11.848/1.482 ms
Иногда вылетает до 10-15%(как и на pingtest.net)При отключенном шейпере:
На RRD также все четко. pingtest.net почти стабильно 0%.
ping host с сервера:
--- ya.ru ping statistics ---
364 packets transmitted, 360 packets received, 1.1% packet loss
round-trip min/avg/max/stddev = 2.924/6.394/15.897/2.980 ms
ping host с клиента:
--- ya.ru ping statistics ---
316 packets transmitted, 305 received, 3% packet loss, time 375755ms
rtt min/avg/max/mdev = 3.121/6.615/13.389/2.976 msт.е. сейчас дело уже не в нагрузках а в ШЕЙПЕРЕ.
Помогите его адекватнее настроить, пожалуйста -
Возможно проблема с производительностью шейпера. Посмотрите подробную нагрузку по ядрамс парамерами io wait, user. Используйте atop.
-
atop - а где его в пфсенсе взять?
[2.0-RC1][root@tun.mob]/root(1): atop
atop: Command not found.
в 1.2.3 тоже самое :( -
поставить с тарболла, ну.
-
Возможно проблема с производительностью шейпера. Посмотрите подробную нагрузку по ядрамс парамерами io wait, user. Используйте atop.
Не подойдет ли простой top(который говорит о том, что нагрузка на ЦП не поднимается выше 15-18% при максимальной нагрузке)?
atop'a больше нет в пакетах для freebsdЕще, замечу, pfsense собран для однопроцессорной машины, у нас же 2 ядра. Это считается за 1 процессор?) Ибо dmesg сообщает о 2х процессорах. Может переставить?
И, вот мой конфиг шэйпера, может в нем что-то не так. Такое чувство, что из-за переполнения каналов(/трубок)в главной мере из-за торрентов, шэйпер дропает и приоритетные пакеты (с 80 порта в том числе), хотя должен как бэ резать торренты до такой степени, при которой все остальные трубки были бы рады и счастливы!
Вот, к примеру, опыт. Запущены торренты. upperlimit у них 80%. При полной нагрузке канала имеем на хттп доунлоад со скоростью 20%!! хотя должны иметь максимально допустимую, судя по приоритетам трубок шэйпера. И это при том, что у трубки, в которую входит 80порт 20% это Гарантированная пропускная способность.
При отключении торрентов - видим максимальную скорость скачки по хттп.
Очередное умозаключение - во-первых, неправильно работают приоритеты трубок. Торренты не освобождают канал более приоритетным трубкам.
во-вторых потери происходят в результате дропов шейпера при переполнении всего канала.(хотя должны просто обрезаться торренты)
Помогите настроить шейпер!
Что не так в конфиге?p.s. прикрепляю конфиг шэйпера, а также данный по процессору взятые с top'a и графиков RRD
-
поставить с тарболла, ну.
не понял, как?
pkg_add -r atop
не помогает, в пакаджах я его не нашел, компилятора в пфсенсе нету. что бы скомпилить… -
Очередной вечер.
На RRD гребенка, но не такая, как раньше. Получше.
пинг хост с сервера и с клиентского компа о потерях не сообщает, но серфинг сильно страдает.
pingtest.net говорит о 1-3%. Иногда подскакивает на гораздо большие значения.
Что делать - не знаю.
По графикам можно предположить, что потери возникают при переполнении каналов.(хотя и не всегда)
-
Хм.. при таких нагрузках я бы еще последил за State table size в Status -> System на предмет переполнения..
-
Да!, она часто на пределе. Но т.к. я не знаю что это такое и где Оно увеличивается - ничего сделать не мог.
Сейчас увеличу и посмотрю что будет.
Может еще расскажете что-нибудь о настройках Advancer? И до какого значения имеет смысл увеличивать данное значение? От чего оно зависит?Cейчас увеличил значение Firewall Maximum States до 20000(т.е в 2 раза), также поставил галочку на Clear DF bit instead of dropping и сменил Firewall Optimization Options с Normal на conservative.
Поправьте, если что не так.
Ждём вечера.
Спасибо за помощь!–---------------------------------------
Даже сейчас, в7 утра, после увеличения значения Firewall Maximum States оно сразу подскочило до 15-16k. Почитав о том, что 1 table state занимает 1кб оперативной памяти, а она у меня больше чем на 1-3% занята не бывает - увеличиваю значение до 180k.
-
Не меняйте все сразу. Посмотрите что будет после увеличения State table size, а то потом непонятно будет, что помогло.
DF-бит - ни о чем, а вот Firewall Optimization Options, думаю, прямо влияет на загрузку State table. При conservative будет хранить все состояния до последнего. Лучше оставьте пока normal. -
ок. пока снова сменил на normal
И да, ты был прав, значение сразу снизилось с 25-30k до 7-9k -
Хм.. при таких нагрузках я бы еще последил за State table size в Status -> System на предмет переполнения..
ПОМОГЛО!!!
Нормальное значение table state у меня 24-25k.
СПАСИБО!–-----------------------------------
Помогите еще с тем, чтобы шейпер уступал канал торрентов для траффика хттп.
Трубка для торрентов:
Bandwidth 1%
Priority 1
Random Early Detection
Explicit Congestion Notification
Upperlimit: 80%
Real time: 1kb
Из стандартных настроек я изменил только upperlimitТрубка для хттп:
Bandwidth 35%
Priority 4
Random Early Detection
Explicit Congestion Notification
Real time: 30%Дело в том, что при полной загрузке канала на хттп выделяется только 54%
А на торренты 38%.
Примерно -
блин, а столько версий было :)
я у себя Firewall Maximum States сразу в 100000 поставил -
блин, а столько версий было :)
я у себя Firewall Maximum States сразу в 100000 поставилУ меня 180000 стоит, ибо при консервативном режиме фаервола (advanced->Firewall Optimization Options- conservative)при больших нагрузках table states поднимается до 120-130k
-
у меня торентов нет в корп сети :)
-
дык у меня еще и normal стоит :) я не менял :) на данный момент, значение без нагрузки Current state count: 10367 :)
посмотрю через час.. при нагрузке :) -
дык у меня еще и normal стоит :) я не менял :) на данный момент, значение без нагрузки Current state count: 10367 :)
посмотрю через час.. при нагрузке :)Попробуйте агрессивный, но там есть нюансы:
Agressive - expires idle connections quicker. More efficient use of CPU and memory but can drop legitimate connections.
