nshut

не обязательно линукс, можно и фряху. интересует софтнат. 110 гигабит, хм, наверно размер пакета 1 гиг и был :) Естественно нат айпи в айпи не интересует, я такое минут за 10 напишу на любой оси. Просто все что я находил меньше 1мппс, ну редко чуть больше. Интересуют возможности. Про ограничение пси-экспресс и слушать не хочу. Процы растут, память тоже, а все топчутся на 1-2мппс, ну не верю. К примеру есть статья "Recipe for building a 10Mpps FreeBSD based router" и другие, но это все синтетик тесты, я же интересуюсь практическим использованием.

локи весч не однозначная. отследить в режиме lock_trace мне так и не удалось на загруженной системе. ибо локи перфа сжирают весь проц. Плюс патч разделения локов на контрак не дал прироста в стейтфул, а только на новые и удаляемые сессии. Кто может объяснить несколько вещей, много перечитал но не все нашел. 1. Сколько максимум выжимали pps на nat, выше писали 2.2mpps, это фуллдуплекс? есть где-нибудь тесты не 100 летней давности. 2. "UDP хэшинг по портам включен", это что и что дает? тыкните ссылкой если не сложно 3. nat events, я так понимаю берет эвенты с модуля контрэк, т.е. храним все сессии без направления трафика в netflow. а как же скачанные байты и пакеты, где их снимают? или я не так понимаю. И можно настройки модуля тоже в студию, у меня модуль в2.2 нагло жрет от 4% до 20%, фактически пики цпу он и делает по своим экспериментам скажу, очереди вроди бы выравнивают лучше загрузку проца если отправлять по 2 очереди на ядро. При загрузке >5Gbp/s речи о буфере 2048 и меньше речи не идет, ставлю максимум. я на продакшине экспериментальном приблизился к 0.9мппс, загрузка ни о чем 20% (и неравномерность). Хочу плюнуть еще 800мппс для теста, но так как продакшин не хочу уронить его. после запуска в бой еще абонентов на новый серв графики и результаты выложу, до 1 мппс смысла нет.

День добрый. Ответьте на ламерский вопрос. Сколько пользователей данный калиссификатор способен классифицировать? интересует практика: гигабит в сек на вход, количество пользователей (ip=скорость) и производительность. Прочитал тему, порыл интернет, увы кроме фраз, тысячи и теория ничего не нашел. Либо тыкните пальцем в куда надо :)

это я понимаю. Меня конкретно интересует практическое использование. т.е. те кто использует может назовет цифры: 2Гб/с - 2к пользователей, цпу загрузка столько то процентов.

Кто вообще видел цыфры производительности. Какие вообще реальные цифры данного шейпера? в тысячах пользователей?

начинал тюнить на дебияне, некоторые параметры включались по 5 минут, точнее связь пропадала до сервера на 5 минут. кто виноват не скажу. но я привык делать так. #!/bin/sh ethtool -x xxxxxx sleep 60 reboot т.е. если связь не теряется, я успеваю остановить ребут. иначе в ребут. хватило два раза выезда на голову. 600Кппс, 5Гб вход, 1,2Г аут, 1,5Мега стейтов. NAT + policer (ISG) загрузка проца 60% в пике. больше не грузил, начинаются дропы в сетевой дырке входящей, т.е. с инета. Сетвевая двухдырковая x520DA2

присоединяюсь, и также как там с мультипроцессорностью, а то на практике мало примеров, одна теория. не в этом дело. вы 0 ядро отобрали у очередей. оно хоть и было в полке, но очередь разгребало. ipfw NAT меня аж плющит. я недавно на линукс и назвать его синтаксис удобным язык не поворачивается. ipfw show также удобен с любыми параметрами вывода чем iptables с кучей цепочек и вываливающей инфу не влазиющее в 80 символов. общее число ядер. т.е. 12 ядер = 12 очередей. Причем тестируя выяснил, что производительность больше, если вешать все прерывания на один проц, и видел подобное на форуме, однако 2 проца всеравно производительней чем один. Уйдя от PF, у меня на фряхе систему грузят только прерывания (цпу-1 не нужен), никаких системных загрузок ядер не видно. Естественно NAT и шейп и висит в этих прерываниях, поэтому и выразил свое подозрение про допиленный SMP в PF. ну и в защиту линукс, скриншоты с одного сервера, тесты проводились тупо меняя хард диск (linux vs freebsd). Точнее это не тест, это графики боевого сервера.

Тогда извиняюсь. Вообще по процессору запаса у вас уже мало. У меня на рабочей системе шейпера 9.2 дамминет не жрет ничего, т.е. 0. увы сейчас не скажу чем добился, но прошло когда уходит от pf NAT. В 10ке его допилили на мультипроцессорность, но что-то у вас эта дрянь все равно есть проц. Так же тестами на линухе и фрибсд лучших результатов добился прибивая очереди по одной на ядро, т.е. дефолт количество теперь меняю, правда у меня их минимальный проц с 6 ядрами.

если изменять, то только эти параметры и наблюдать. Я тоже начитавшись советов поизменял все кучей. Два дня проблему искал, то пинги росли, то ошибки сыпались. сейчас на штатных дровах centos с ethtool применил только размер очередей и количество очередей ethtool -L ix0 combined 6 ethtool -L ix1 combined 6 ethtool -G ix1 tx 4096 rx 4096 ethtool -G ix0 tx 4096 rx 4096 и проблемы все с ошибками ушли. все tso, gro и т.д. опции читал по интел документации и все параметры настраивал и с другой стороны. Факт на лицо, без касания этих именно параметров стало лучше. Увы тестировать какой именно проблему вызывает на рабочей системе не могу :( , хотя крутил их ночью и по очереди и с перезагрузкой сервера.

2 Dyr могу ошибаться, т.к. с 10 еще не работал, но из того, что видно похоже очереди не прибиты по прерываниям, а если и прибиты то не все. Отсюда как минимум неравномерная нагрузка на ядра

увы нет. время не ноч, зависимости нет. самое сложное задание это бэкап сервера, длится 3 секунды. Есть подозрение, что ng_nat будет грузить систему также, в принципе нат бсдевый те ноды и использует, разве что переписать в корне весь нат. Пробывал подымать кучу нод для нарезки пользователям полисинга. Скажем так: поведение ну очень неадекватное системы. Ноды когда их много реагируют по разному и бывает просто не реагируют даже на управляющие команды, пару нод убил только выгрузив модуль ядра. Хотя может уже пропатчили, но пока забросил и не проверял больше. фрибсд нагрузку могу потестировать до 1,5 гига трафика, остальное у меня на линухе, фряху 10ую не пробовал. Нет свободного сервера для внедрения в работающую систему. А модули потестить запросто. 10ку не пробовал, потому что помню тесты 9.1 release когда он вышел. Слетание маршрутов при использовании ПФ, и замена дефолтного маршрута на адрес сети из сети которая даже не принадлежит этому серверу, это была жесть и тот же пинг под 3к. Данный баг многие описали в мэйллисте, результат поправили через пол года и статус бага был не критичен, да и нетмап апи стали писать из-за того что в последнее время ну очень теряется производительность систем изза того что в ядре накручено. Раньше сказав "работает в ядре" звучало престижно, круто и быстро, сейчас смотрю модули юзерспейс как фри так и линуха уже по грамотней пишут

фря 9.2 работает примерно в таком же режиме, нат и т.д. в определенное время (мониторю все ядра) возникает скачек нагрузки на одно два ядра, и через время проходит само собой. из всего что мониторю, стейты в этот момент не увеличиваются, ппс и объем трафика такой же. вываливал весь трафик по нетфлоу и отдельный файл и прогонял через функции libalias, в эти моменты хэш таблица назначений и источника определенной истансы разрастается не пропорционально. т.е. допустим в истанс 1 таблица размером 100-200, а 2ая 900 и выше. Увеличил размеры таблиц в либалиас по максимуму, проц до 100% взлетать перестал, анализ прекратил. Видимо реакция на торент или вирусы определенные, но явно функция расчета хэш не оптимальная. Наблюдая вижу также неравномерность но система не умирает по загрузке. Может у вас не так, но у меня так :) руки не доходят посмотреть как контрэк в линухе описан, но явно получше чем во фряхе. Не обижайтесь, я сам обожаю фряху, но если кто-нибудь не перепишет ядро, либо не доработает netmap как nat сервер на большой нагрузке приходится жертвовать чем то.

Перекомпилировав ядро можно добиться улучшений Через sysctl не искал но /usr/src/sys/netinet/libalias/alias_db.c #define ICMP_EXPIRE_TIME 60 #define UDP_EXPIRE_TIME 60 #define PROTO_EXPIRE_TIME 60 А это размер хэш по поиску стейтов /usr/src/sys/netinet/libalias/alias_local.h Исправить на #define LINK_TABLE_OUT_SIZE 65535 #define LINK_TABLE_IN_SIZE 65535 Больше 65535 смысла ставить нет, там это значение WORD Далее, у вас надо смотреть конкретно сколько записей в трансляции для каждой инстансы, и большие разносить на еще истансы. На моей практике на самом деле жрет одна или две истансы НАТ из 15-20 имеющихся. Не знаю, что там в ядре либалиасов намутили, но очень прожерливая система. Debian на этом же сервере 1,2 гига трафика дает загрузку ЦПУ в 2-3 меньше. Другой сервер линуха полисит и натит 5 гигов трафика не напрягаясь. Копая исходники фряхи очень не понравилась фраза (перевод на русский звучит так): почему то когда пакет проходит через сервер у него ломается чек сум пакета и ниже функция исправляющая это. Не понимаю как такие фразы вообще в ядре могут быть. В общем совет если только нат, то перейти на линух. Я тестировал меняя в сервере под нагрузкой жеские диски, т.е. тоже железо, разная ось. Причем у фряхи при нате нагрузка растет в геометрической прогрессии, в чем тоже был разочарован. В принципе имеются скриншоты тестов, если интересно могу приложить как найду их у себя

dmvy, можно получить контакт разработчика модуля? спс. уже не надо.

вопрос следующего характера: подумываю прикрутить возможность общения пхп с данным сервером, ну может не пхп, пример: цепляюсь по тсп, отправляю ДайМак00-00-00-00-00-00 и сервак отвечает что имеет. собсно сам вопрос к однопоточному сервису прикрутить в виде асинхронного ожидания как можно? Читал что не рекомендуется делать по прерываниям, т.к. это некрасиво или инфа устаревшая? в общем на том, что имеем какой красивый способ сделать это? идеи с примерами приветствуются :) Сейчас сервер через семафоры и таймауты ожидает команды, а лучше можно организовать? межпроцессорное взаимодействие плохо знаю, как и сокеты

обновил файл в шапке, изменил кое где отдачу клиенту данных через strncpy а также изменил вывод влана и порта, теперь выглядит S 1:2:15 1-vlan, 2 стек id (на 3100 результат заметен), ну и 15 порт. оптимизировать ничего не стал, все же это не тот сервис. Нашел что циска также отдает циркут айди, а вот зюксел по другому. стандарт стандартом, но видимо кроме circut type и id общего стандарта нет. не ссортесь :) мы же пишем для себя, а не за деньги. Я в хедере много могу чего объявить, увы изучать тонну литературы как красиво написать код не буду, мне хватит устранения ворнингов, а если я буду знать как красиво писать на си, пхп, перл и помнить все их функции какая лучше и красившне, голова лопнет. Мое мнение таково: "ОНО ВЕДЬ РАБОТАЕТ!" )))

2 Ivan_83 вот уже по делу. завтра послезавтра изучу приложенные ссылки. Седня уже под пивом, лучше не лезть :) кэша в моем коде никакого нет, не представляю что за сеть где один дхп обслужит больше 1к запросов, поэтому даже не думал, а так туже таблицу хэш как в айпифв тоже прикрутить можно, но всетаки не тот сервис. Причем тест проводился на обычной тачке пня. причем тест без обработки пакета. Пришел пакет, отправил пакет увеличил скорость всего в 4 раза. я так понял из всего там самое затратное это малоки и калоки, но не утверждаю т.к. на синтетический тест потратил не много времени. По поводу типов - дибильная привычка с винды, хочешь нужный тип, опиши сам )) за рфц ссылки еще раз спасибо, завтра буду изучать, ненавижу когда знаю что какойто кусок кода даст сбой. по поводу strcpy и команд по не лимитированым, набирая каждую команду пытаюсь продумать алгоритм переполнения. в моем сервере, а он тупо для меня основные баги можно вызвать конфиг файлов, т.е. там контроля ноль, в остальном длинну продумывал. А честно, я вообще думал краши буду ловить каждый день. т.к. до этого инет атон и т.д. а тем более о форке знал только в теории. а еще скажу. программить под никс системы одно удовольствие, тот же ман. Винда отдыхает. у них апи сложнее асембера местами

Порт запилите ;) рано еще. клиент накидан очень кустарным способом. Плюс еще жду оборудование кроме длинка, чтобы проверить работу по circuit id (по которому вычисляется влан и порт) не нашел ни одной доки из чего это поле должно состоять. Возможно придется отдельным файлом делать шаблон в зависимости от версии коммутатора. А может как биллинг запущу и внедрю код напрямую работы с базой. увы начинаю понимать, что время утекает от нас очень быстро

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

абсолютно согласен, удобней чем с майскулом строить работу билинга еще ничего не видел. обратиться можно с любого языка программирования и т.д. и все связать дело не хитрое. Но прикручивать сам демон к базе и вставить функцию кэша у меня уже нет времени. Активно работаю над скелетом БД и как все это будет шейпится. пока работает на УТМ, кто админил тот знает :(

У сейчас примерно так и работает с freeradius+rlm_perl + БД билинга По идее для того, чтобы всё держать в своей собственной памяти серверу нужно прикрутить какое-то API, чтобы в случае, например, добавления абоненту IP-адреса или, например, изменения привязки абонента с одного порта на другой, билинг мог как-то взаимодействовать с dhcp-сервером, чтобы тот "освежил в памяти" изменённые данные. В случае с работой с БД билинга напрямую этих трудностей нет, хоть и медленнее. p.s. Я сейчас прикрутил ещё и memcached (запоминает на энное время уже "отвеченные" запросы, спасает от флуда), частично помогает снизить нагрузку на бд так и есть, клиентская тулза через шаред мемори опрашивает дшсп на последние записи перлом каждые 10 сек. нагрузки ноль. От момента получения абонента адреса и момента вход в личный кабинет проходит явно меньше времени чем интервал опроса. Но даже прикрутить апи к порту на котором сервак слушает и отвечает тем же удп ответом делов на час два. Мне просто надо было так, вот и накидал тулзу. т.е. у меня есть веб сервер который слушает от клиентов запросы и может вызывать любые команды на сервере и все это не от привилеге юзера. просто бывает свич подвисает (длинки любят по питанию) и один запрос идет тысячи раз, ловить это долго, вот и закрыта у меня запись всех изменений в базу. фактически уже работает у меня: клиент зашел, нажал кнопку это мой айпи и через секунду в дшсп уже статическая запись, ребут и он в сети с нужной скоростью. идея к порту привязывать пришла вчера, но тоже делов на пол дня максимум. главное ведь логика БД, а скелет сервера подтюнить всегда можно. цель была не рестартить дшсп при каждых изменениях базы и я ее достиг. а еще есть глюк, инженер меняет магистральный порт на котором ставится филтер дшсп. клиенты не получают адреса. как изменим настройку а это день может пройти, клиенты с такой скоростью долбят радиус дшсп что и он и база в шоке.

ах да, на скрине S 1:20 это статическая запись, 1 влан, 20 порт, t: время в секундах с последнего обновления айпи, следом айпишник это релей агент. помимо S - есть D(динамика), B (запись BAD т.е. когда компутер говорит что айпишник занят в сети, удаляется толи через час толи 2), и T это временная запись, когда айпишник сервер подготовил для клиента на его запрос, но клиент не запросил его, т.е. еще не было nack сообщения. Чистка базы от таких записей происходит только при выделении новой записи, т.е. если за сутки никто не запросит айпишник которого нет в базе, записи так и будут висеть. логика такая, ибо не нагружать лишними проверками

Не подскажете какую нагрузку дает tc на систему по сравнению с lISG при трафике в 1Гбит/сек к примеру? Если одну подсеть запустите не большую совместно с ISG то проблем не будет. Лично пробовал всех пользователей на tc распедалить, т.е. 1к пользователей каждому своя скорость (как ИСГ). Создавалось дерево из хашей оптимально по скорости расчета, после загрузки дерева проц ушел в полку. 100 подсетей tc раскурит без проблем. В свою очередь ISG курит у меня сейчас на ксеоне 5гигабит трафика, загрузка 12 ядер 40%, 1000к стейтов и 500к пакетов в секунду и этот же сервак и натит. Но это почти потолок, т.к. рулит одна карта x520-da2, жду еще одну и попытаюсь поднять нагрузку. А так разрулил пока на второй сервер isg. Но вопрос для меня тоже актуален. У пользователей допустим 3 ip, хочется чтобы он имел общий канал как в даминет а не каждому свой с определенной скоростью.

Представляю вашему вниманию сервер, который крутится у меня на город, примерно 5к устройств сейчас отрабатывает. Сервер работает месяц и пока не было ни одного краша и глюка, либо я еще не успел заметить. Предистория: хотел адаптировать перловый сервер для базы mysql, в результате писанины выяснено: майскул медленный для таких запросов когда есть флуд, а точнее он вообще колом стоит, плюс даже при старте перл 1 из 10 случаев теряет конект с базой. В результате я плюнул и решил с нуля написать именно то, что мне нужно. Спецификация сервера: - вся база хранится в памяти, скидывается на диск по запросу или при шутдауне сервера - сервер выдает новые записи удаляя старые при базе в 65к заполненой полностью со скоростью 1к в секунду. В связи с этим мультипроцессорность в код не внедрял. - сервер стартует двумя процессами, один наблюдает за дочерним, второй сам процесс выдачи адресов клиентам - сервер выдает айпи только через релей агенты (увы у меня только длинк и циска), циска на отрез отказалась опцию влан айди и порт выдавать, поэтому протестировано только на длинках 3200, 3100, 3526, 3620. Опция 82 не обязательна для работы сервера. - сервер поддерживает пулы, у меня 128 пока пулов, все зависит от памяти. Весь сервер с 65к записями жрет 8метров памяти - пул определяется из влана (опции 82) или по релей агенту записанного в виде начальный адрес агента, конечный адрес. Шлюз вычисляется на основе маски и является первым адресом сети. - пул может содержать мак адреса и ip адреса из других сетей, т.е. один пул может выдавать белые айпи (шлюз вычисляется аналогично). Один мак может находится во всех пулах, чтобы пользоватлель с буком мог регистрироваться в любой точке города. В одном же пуле айпи и мак являются уникальными значениями - к серверу есть утилита управления, которая: добавляет статику, удаляет, запрашивает статус сервера и для дальнейшей выгрузки в майскул есть функция показа всех записей, а также показа последних добавленных записей. На данный момент прорабатываю возможность выдачи только на одном порту, т.е. закрепление айпи за портом, если порт изменится, то выдаст временный айпи, что можно будет изменить через личный кабинет пользователя. В общем идея, привязка пользователей к свичам ацесс листами свичей. По снупингу привязка не понравилась ни в какой виде. Прошу сильно не пинать, это первая программа под фряху. Но обоснованная критика приветствуется. Также считаю, что программа без багов не бывает, может вы найдете :), буду только рад. Но особенно буду рад если кому-нибудь это пригодится, т.к. убил почти неделю непрерывной писанины. Далее в планах написать модуль ядра нарезки скорости, пока выбираю ОСЬ для этого. Linux isg штука хорошая, но кое чем тоже не устраивает. qdhcp.tar.gz

День добрый, хотел выложить результаты производительности двух серверов на карточках X520-DA2. Конфигурации (тюнинг) FreeBSD одинаковы, только версии ОС разные, т.к. 8.4 не завелась на новом железе асус, точнее завелась, но подлипала очень подозрительно, пакеты по 5-7 секунд некоторые где-то блуждали. Естественно на обоих серверах все очереди прибиты по процам. В общем по результатам понял: - что в процессоре и шине главное частота, а не количество ядер. - pf немного проигрывает IPFW NAT instance, обидно, т.к. по мне НАТ пф ну очень удобен с мудреными правилами На pf nat и шейпинге одновременно в одной железке, dummynet часто ложит в топ один проц, после разведения по серверам жрет 0%. Странно он себя ведет. Как то так, надеюсь кому-нибудь наблюдения будут полезны. п.с. на графиках синим изображается не весь процессор я одно ядро максимально нагруженное в один момент времени. т.е. другим ядрам немного легче