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



  • Доброе время суток, уважаемые господа сетевики!
    Вопрос достаточно простой, но требует большого опыта в раздаче интернета.

    Имеем работающий сервер, чистый, только что установленный, функция одна - НАТ:
    1.2.3-RELEASE
    built on Sun Dec 6 23:21:36 EST 2009
    FreeBSD 7.2-RELEASE-p5 i386

    Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz

    WAN сетевая карта - встроенная, на 100mbps, re0 (RTL8201L)
    LAN сетевая карта - торчит в pci слоте, на 1000mbps, D-link DGE-528T, (на чипсете rtl8169s)

    c LAN'a траффик идет к свичу D-link DES-1024D, а от него дальше, по большим и маленьким свичам равномерно распределяя канал 50/25mbps(down/up) на 50-100 пользователей. Месячный оборот траффика около 7-8 Тб.

    Проблема в потере пакетов. pingtest(pingtest.net) показывает от 2 до 18 процентов в пиковое время (19:00 до 01:00), на графиках же все еще хуже (см. в приложении).

    Соответственно, в моменты отдыха все лучше, потери стремятся к 1 проценту, что терпимо.

    Нагрузка на процессор минимальна, выходит дело в сетевых картах, либо в свиче, я так полагаю.

    Быть может, возможно как-то это определить? Или же неверно настроен pfsense?

    Подскажите, куда смотреть и как можно это потестировать.
    Спасибо.

    upd. Для решения проблемы потребовалось увеличить значение State table size в параметрах Advanced.
    Спасибо to
    "rubic" за решение проблемы! И за лучший совет, который помог диагностировать работоспособность железа. (без него были бы куплены пара ненужных сетевух и планировалось взять на тестирование большой дорогой и ненужный(в данном контексте) управляемый свич(в главной мере из-за моей некомпетенции)
    И большое спасибо всем, кто принимал участие в дискуссии!

    ![packet loss.png](/public/imported_attachments/1/packet loss.png)
    ![packet loss.png_thumb](/public/imported_attachments/1/packet loss.png_thumb)



  • что-нибудь вроде HP V1905-48 Switch, и выбросить половину свитчей. Постоянный мониторинг по SNMP каждого порта в коммутаторе (траффик, коллизии, icmp)



  • тебе нада все узлы проверять :)  ох и геморная это штука :)



  • WAN сетевая карта - встроенная, на 100mbps, dlink (re0)

    это как?

    читать отсюда http://forum.ixbt.com/topic.cgi?id=14:13800



  • @aleksvolgin:

    WAN сетевая карта - встроенная, на 100mbps, dlink (re0)

    это как?

    Имелось ввиду как WAN интерфейс используется встроенная в материнскую плату сетевая карта dlink на 100мбпс.

    @Tamriel:

    тебе нада все узлы проверять :)  ох и геморная это штука :)

    Данная проблема абсолютно во всех частях сети. И зависит только от нагрузки. Т.е. если подключить только одного пользователя на любом узле - потерь не будет.

    @deutsche:

    что-нибудь вроде HP V1905-48 Switch, и выбросить половину свитчей. Постоянный мониторинг по SNMP каждого порта в коммутаторе (траффик, коллизии, icmp)

    Поменять самый дешевый Длинк на управляемый ХП это вариант, конечно. Подскажите, какие параметры критичны, на что обращать внимания при выборе. Необходимо 16 портов, примерно 10k pps(пропускная способность пакетов в секунду), и 50mbps скорость интернет канала(в перспективе увеличение до 100). Это основной свич, который идет после маршрутизатора и распределяет траффик на другие(16ти портовые) свичи.

    Но зачем выкидывать свичи? У нас до клиента самая длинная цепь это: сервер - дальше центральный свич - от него кабеля расходится на 16 этажей, и на каждом стоит 16портовый свич - от него кабеля идут по блокам, в каждом из которых еще один свич и несколько клиентов, подключенных к нему.
     Укоротить схему возможности нет, ибо это повлечет на собой рассистематизацию и провода в неконтролируемом количестве.

    Получается и свич менять и сетевухи?
    Но начать надо таки со свича, так?



  • встроенная в материнскую плату сетевая карта dlink

    ещё раз

    сетевая карта - встроенная, на 100mbps, dlink (re0)



  • Еще раз - что тут не ясно?

    Или Вы имеете ввиду, что само собой разумеется, встроенная сетевая карта не выдерживает нагрузки?
    Перспектива читать 55 страниц форума о том, как человек выбирает себе сетевую карту для подключению 2х домашних компьютером не кажется мне очень целесообразным



  • Сетевухи конечно лучше сменить на Intel, этажные свитчи на гигабитные, главный свитч на гигабитый ну и мониторинг по всем портам в кактус (или что там у вас есть). Так вы узнайте хотябы какие блоки у вас заражены троянами ботнетов.



  • Вы считаете что имеет смысл менять свичи на гигабитные, когда соединение с провайдером все-равно 100мегабитное?

    Управляемый свич только чтобы найти ботнеты? Не подскажете какие параметры и функции желательно иметь у свича для увеличения его производительности при наших нагрузках(оперативная, флэш память)? Пока я понял, что желательны управляемые порты. Но кроме поиска перегрузок на узлах не вижу в этом плюсов. Но я никогда не имел дело с управляемыми портами, поэтому не могу судить.

    Сетевые сменить на интел, Intel PILA8461B, например, будет лучше нашего D-link DGE-530T (или 528го, не помню точно) или Intel PILA8460M? Будет ли разница? и за счет чего? (WAN должен быть только 100мб, т.к. там стоят медиаконвертеры, работающие только со 100мбитами)



  • Обнаружена очень интересная подробность!
    При быстром увеличении дропов траффик шэйпера неимоверно подлетает потеря пакетов.

    Сейчас 7:17 утра. Сеть разгружена. Имеем пакету пакетов 0-2%, при небольшом (10мегабит) траффике торрентов(pingtest.net). При ограничения upperlimit'a до 1% пропускной способности (256кбит) сильно подлетают дропы лишних пакетов и pingtest показывает до 52%(!!!) потерь пакетов(хотя RRD графики pfsens'a) молчат. Когда ограничение на 1% повышается до 80% - потери, фиксируемые pingtest'oм, снова приближаются к 0-2%.

    И, внимание, при отключении шэйпера - потери стабильно 0%!

    Жду вечера для подтверждения тестов. Пока главное предположение - все дело в дропах шэйпера.
    Но как его "правильно" настроить - еще вопрос.



  • @aleksvolgin:

    встроенная в материнскую плату сетевая карта dlink

    ещё раз

    сетевая карта - встроенная, на 100mbps, dlink (re0)

    Алекс, видимо, хочет сказать, что не d-link у тебя, а realtek.



  • Вопрос достаточно простой,

    Тут я бы  не горячился.

    Проблема в потере пакетов. pingtest показывает от 2 до 18 процентов в пиковое время (19:00 до 01:00), на графиках же все еще хуже (см. в приложении).

    откуда выполняется pingtest?



  • @Evgeny:

    откуда выполняется pingtest?

    В основном - клиентский компьютер. Иногда подсоединяется напрямую к LAN карте сервера. Иногда напрямую к кабелю провайдера.
    Я почти уверен, что у провайдера проблем нет. И после тестов я почти уверен, что проблема связана с шейпингом



  • @goliy:

    @Evgeny:

    откуда выполняется pingtest?

    В основном - клиентский компьютер. Иногда подсоединяется напрямую к LAN карте сервера. Иногда напрямую к кабелю провайдера.
    Я почти уверен, что у провайдера проблем нет. И после тестов я почти уверен, что проблема связана с шейпингом

    С консоли pfSense попробуй.
    Что-то мне подсказывает, что это не "проблема связана с шейпингом", а как раз шейпинг в работе. Радоваться нужно! Шейпинг работает -)



  • Извиняюсь, что сразу не пояснил до конца - pingtest это тест с сайта pingtest.net.
    С самого же маршрутизатора пинг летает успешно(как, собственно, и с клиентских машин), а проблемы я смотрю по RRD графикам.

    Работающий шейпинг мы прошли уже очень давно =)  (http://forum.pfsense.org/index.php/topic,26220.0.html)

    Это конечно хорошо, но когда потери такие как на графиках - это уже огромная проблема в производительности сети. Приложения в реальном времени почти совсем не работали.

    Сейчас я перенастроил шейпер Визардом(видимо, вся проблема была в том, что я не правильно его настроил), в этот раз почти не меняя настроек после его работы. И с нетерпением жду вечернего краш-теста.
    Первый сюрприз - начал лагать веб-интерфейс. top показывает, что процессы php находятся в состоянии piperd и по очень подолгу не отвечают. Решилось - ребутом

    –----------------------------------------------------------------------------------------

    Итак, прогресса почти нет =(
    Снова нагрузка возрастает - потери увеличиваются. И так до тех же показателей потерь, как на приложении в первом сообщении.

    Пинг с сервера почти не выявляет потери(~0.5%), несмотря на графики RRD.
    пинг с клиенских маших - потери до 16%

    Главный вывод - проблема в сетевой карте LAN или со свичем.
    Подтвердите кто-нибудь, а =)



  • 1 народ прав :) ни длинк, ни тем более реалтек - не годны для подобного трафика :)
    з.ы. как пример - почему то VMWARE ESX их не поддерживают :)
    2 какая загрузка собстенно на пк? память? проц ? что немаловажно - винты?  если у тебя логи какие то пишутся может не хватать…
    по процу - если график такая же "гребенка" как и с потерями - то надо задуматься, + какое ядро стоит?
    но 90% что таки сетевуха, возьми и поставь интел, для начала...



  • Еще раз:
    Интерфейс LAN - сетевая карта re0: <rtl8201l 10="" 100="" media="" interface="">Интерфейс WAN - сетевая карта re1: <d-link dge-528(t)="" gigabit="" ethernet="" adapter="">Использование жесткого диска(32253MB <maxtor 4k040h2="" a08.1500="">) - 0%
    Использование оперативной памяти - максимум(2Gb) 5-6%
    Использование процессора(Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz) - максимум до 15-20% доходит. Но обычно 5-12%.

    С этим - все в порядке.

    Насчет сетевой карты - Какую посоветуете? И на что смотреть при выборе? Какие параметры критичны? Что в реалтеках/длинках не так?
    Ведь есть у них качественное оборудование. У билайна, например, все оборудование, кроме самых больших, шлюзовых элементов, стоят д-линки. Странно выглядят советы - просто сменить на Интел. Сейчас в сервере не самый худший д-линк(D-link DGE-528T) на интерфейсе ЛАН стоит. А интелы и по 200рублей бывают. Можно поточнее характеристики, модели, функции.
    Пока я вижу разницу только в наличии функции Flow Control, которая, ввиду разгруженного процессора, не будет иметь профита. Тем более в нашем д-линке(интерфейс ЛАН) она тоже есть.

    Кроме того, freebsd 7.2 не поддерживает никакие 100мегабитные карты Интела, судя по http://www.freebsd.org/releases/7.2R/hardware.html

    Думаю взять Intel EXPI9301CT как LAN, а что на WAN пока не придумал. Нужно 100мегабит. В крайнем случае грамотный способ смены режима работы на 100мегабит гигабитной карты. (аналог обычного rc.conf'a где находится в pfsense? или еще как-нибудь. Пока кроме прописывания ifconfig media 100baseT/UTP ничего в голову не приходит. Может создать в /etc/rc.d/file.sh в который и вписать эту команду? Но, имхо, просто карта на 100мегабит надежнее)

    На яндекс-маркете так ничего 100мегабитного не на чипсетах реалтека и д-линка не нашел =(

    Cегодня заменил карту на LAN'e с D-Link DGE-528(T) на D-Link DFE-530TX+, она 100мегабитная, но может будет лучше. Ждем вечера и заказываем Intel EXPI9301CT.

    Жду советов что взять на WAN интерфейс (pci, 100mbps)</maxtor></d-link></rtl8201l>



  • 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.



  • Да, признаю, что ошибся с картами. Криво смотрел. Спасибо, что показали.



  • @rubic:

    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 тоже самое :(



  • поставить с тарболла, ну.



  • @deutsche:

    Возможно проблема с производительностью шейпера. Посмотрите подробную нагрузку по ядрамс парамерами 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





    shaper.txt



  • @deutsche:

    поставить с тарболла, ну.

    не понял, как?
    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



  • @rubic:

    Хм.. при таких нагрузках я бы еще последил за 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 поставил



  • @alexandrnew:

    блин, а столько версий было :)
    я у себя Firewall Maximum States сразу в 100000 поставил

    У меня 180000 стоит, ибо при консервативном режиме фаервола (advanced->Firewall Optimization Options- conservative)при больших нагрузках table states поднимается до 120-130k



  • у меня торентов нет в корп сети :)



  • дык у меня еще и normal стоит :) я не менял :) на данный момент, значение без нагрузки Current state count: 10367 :)
    посмотрю через час.. при нагрузке :)



  • @alexandrnew:

    дык у меня еще и normal стоит :) я не менял :) на данный момент, значение без нагрузки Current state count: 10367 :)
    посмотрю через час.. при нагрузке :)

    Попробуйте агрессивный, но там есть нюансы:
    Agressive - expires idle connections quicker. More efficient use of CPU and memory but can drop legitimate connections.



  • В таком случае какая вообще целесообразность в использовании данного режима?



  • @goliy:

    В таком случае какая вообще целесообразность в использовании данного режима?

    Освобождает простаивающие соединения быстрее. Более эффективное использование ресурсов процессора и памяти, но могут быть сброшены легитимные соединения.
    Просто попробовать нужно. Те соединения которые могут быть сброшены просто переконнектятся еще раз.



  • Ну то есть есть смысл использовать при нехватки ресурсов оперативной памяти и процессора, я так понимаю.
    А если всего вдостатке - юзаем conservative, чтобы максимально избежать дропов, как раз за счет использования процессора и оперативной памяти.


Log in to reply