vasya_petrovich Опубликовано 13 февраля, 2013 · Жалоба Добрый день. Господа, помогите оптимизировать работу шлюза. Имеем 2 гига оперы ддр3, процессор Intel® Core i7-3770T CPU @ 2.50GHz + сетевая карта Intel I350-T4, драйвер загружен с опциями RSS=4,4,4,4 InterruptThrottleRate=3000,3000,3000,3000 QueuePairs=1,1,1,1 LLIPort=80 Также на борту вертится НАТ + iptables filtering + HTB shaping + netflow (ipt_netflow) + с десяток вланов + ifb В таблесах филтер порядка 3000 правил + 3000 правил в мангле + в нат 3 подсети Трафик с интерфейсов заворачивается на IFB устройства (4 штуки) и там же шейпится с помощью тс + НТВ. В мангле правила для классификации трафика. И все это дело у меня начинает давать частичные дропы и падение скорости под вечер, когда начинается нагрузка. При этом загрузка проца под вечер пляшет от 60% до 80% и трафик валит со скоростью 350 мегабит/с в одну и 350 в другую сторону. P.S.> Хотел бы через хеш классифицировать в шейпере, но проблема в том, что там траф уже светится за натом (т.е. не попадают ипник вида 192.168.*.*). Что можете посоветовать по оптимизации? Пока только думаю увеличивать мощность поставить 8 ядерный амд. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 февраля, 2013 · Жалоба Что можете посоветовать по оптимизации? Пока только думаю увеличивать мощность поставить 8 ядерный амд. Это тупиковый путь. Однозначно стоит забыть про такой "апгрейд". Как минимум убрать вот это QueuePairs=1,1,1,1 LLIPort=80 из опций драйвера и попытаться вынести NAT с этой машины на другую, которую поставить чуть дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 13 февраля, 2013 · Жалоба Что можете посоветовать по оптимизации? Пока только думаю увеличивать мощность поставить 8 ядерный амд. Это тупиковый путь. Однозначно стоит забыть про такой "апгрейд". Как минимум убрать вот это QueuePairs=1,1,1,1 LLIPort=80 из опций драйвера и попытаться вынести NAT с этой машины на другую, которую поставить чуть дальше. т.е. Вы предлагаете вынести нат дальше, а на этой машине не классифицировать траффик, а использовать хеш фильтры? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 13 февраля, 2013 · Жалоба И еще вопрос о таком кол-ве правил в iptables. Может быть стоит эти сложности разобрать по косточкам и выяснить как уменьшить это кол-во? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 13 февраля, 2013 (изменено) · Жалоба И еще вопрос о таком кол-ве правил в iptables. Может быть стоит эти сложности разобрать по косточкам и выяснить как уменьшить это кол-во? Согласен. Думал над этим. Просто изначально не правильно продумал, вот и получил результат. Еще один вопрос. Я в биосе отключил гипертрединг в связи с тем, что когда-то давно у меня были с ним проблемы по причине того, что у меня ядро в кору вываливалось, сейчас ядро 2.6.32. Поможет ли мне включение гипертрединга? И не будет ли вываливаться ядро в кору? Изменено 13 февраля, 2013 пользователем vasya_petrovich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 13 февраля, 2013 · Жалоба 8-миядерный амд на самом деле 4-хядерный, сделаете только хуже. Да и не в количестве ядер тут дело, а в удельной частоте ядра. Гипертрединг вообще никакой погоды не делает, хоть и гуляет мнение что он даже вреден. Однозначно ветвить правила, 3к последовательно это очень много. Посмотреть в сторону поменять местами порядок полисинга и ната чтобы использовать хеши. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 14 февраля, 2013 (изменено) · Жалоба Чините iptables. Зачем там 6000 правил??? Если это разрешение/запрет клиентам - залейте его в ipset и используйте 1 правило, получите разгрузку раз в 10 минимум. Изменено 14 февраля, 2013 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 14 февраля, 2013 (изменено) · Жалоба Я в биосе отключил гипертрединг в связи с тем, что когда-то давно у меня были с ним проблемы по причине того, что у меня ядро в кору вываливалось, сейчас ядро 2.6.32. Поможет ли мне включение гипертрединга? И не будет ли вываливаться ядро в кору? На ядрах 3.2.x - 3.7.x и камнях E3-E5 Xeon таки допилили HT до приемлемого уровня. Поэтому, если приобретете когда-нибудь мат. плату на чипсете Intel C20x, 60x, то включайте. Все будет шоколадно. С более ранними ядрами, старыми ОС, старым железом и т.п. действительно вылезали неприятные косяки и были перекосы по нагрузке на ядра. В последнее время вроде как детские болезни прошли, но нужна новая программно-аппаратная основа для юзанья HT. Изменено 14 февраля, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 14 февраля, 2013 · Жалоба 8-миядерный амд на самом деле 4-хядерный, сделаете только хуже. 8 полноценных целочисленных ядер, разве что декодер команд общий. Проблема у амд в другом кроется.. Да и не в количестве ядер тут дело, а в удельной частоте ядра. Не угадали. Ключевую роль играют как раз латентность памяти и кешей. По сабжу - да, цепочки ветвить или юзать ipset; htb - хеш-фильтры строить; очереди на сетевухах повключать по кол-ву ядер и привязать очередь к ядру... Дальше уже думать, если не хватит производительности, над более глубокими оптимиациями Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 14 февраля, 2013 · Жалоба Не угадали. Ключевую роль играют как раз латентность памяти и кешей. А оно с каких-то пор не соотносится к частоте? Подбором железа занимаюсь не я в основном, мог пропустить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 14 февраля, 2013 (изменено) · Жалоба Господа, спасибо за советы. Уже занимаюсь оптимизацией (ipset, хэш фильтры htb) О резалтах сообщу позже. Нитро, в чем скрытая проблема у амд? Изменено 14 февраля, 2013 пользователем vasya_petrovich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 14 февраля, 2013 (изменено) · Жалоба Столкнулся с непонятным для меня сабжем. Чтобы обойти проблему НАТ, решил снимать трафик с внутренних интерфейсов (вход и исход) и редиректить их на IFB устройства. На внутренний интерфейс прилепил дисциплину ингресс, и добавил фильтр для редиректа трафика на псевдойстройство. Фильтр отрабатывает как надо, НО! ком*** tc -s filter show dev $MY_INTERNAL_INTERFACE ничего не показывает. Почему? Изменено 14 февраля, 2013 пользователем vasya_petrovich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 14 февраля, 2013 · Жалоба А оно с каких-то пор не соотносится к частоте? Куда больше соотносится с особенностями архитектуры. Сравните латентность интела и амд. Нитро, в чем скрытая проблема у амд? Написал уже: латентность кешей/памяти больше... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 14 февраля, 2013 · Жалоба А, ну с этой точки зрения да, логично. Просто кроме Xeon'ов ничего не закупаем) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 15 февраля, 2013 · Жалоба Столкнулся с непонятным для меня сабжем. Чтобы обойти проблему НАТ, решил снимать трафик с внутренних интерфейсов (вход и исход) и редиректить их на IFB устройства. На внутренний интерфейс прилепил дисциплину ингресс, и добавил фильтр для редиректа трафика на псевдойстройство. Фильтр отрабатывает как надо, НО! ком*** tc -s filter show dev $MY_INTERNAL_INTERFACE ничего не показывает. Почему? Оказывается все просто: tc -s filter show dev $MY_INTERNAL_INTERFACE parent ffff: Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 15 февраля, 2013 · Жалоба Как победить большое кол-во дропов на псевдоустройстве IFB? Заворачиваю туда трафик и дроппед начинает расти. Хотя я еще не повесил ни одну дисциплину tc. В чем засада? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 17 февраля, 2013 (изменено) · Жалоба Надо отказываться от использования псевдоустройств и распределить разные функции по нескольким машинам (одна машина или коммутатор для терминации вланов, другая -- шейпирующий мост, третья -- border router c NAT и Netflow). Изменено 17 февраля, 2013 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 17 февраля, 2013 · Жалоба Надо отказываться от использования псевдоустройств и распределить разные функции по нескольким машинам (одна машина или коммутатор для терминации вланов, другая -- шейпирующий мост, третья -- border router c NAT и Netflow). +1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 17 февраля, 2013 · Жалоба Надо, но вообще-то оно работает, и работает хорошо. Хорошо нагруженный PPPoE BRAS, на ifb0 заворачивается трафик с bond-интерфейса(2х1G), реальный трафик до 1.5G. root#nas4 ~ #ifconfig ifb0 ifb0 Link encap:Ethernet HWaddr 4A:D7:D1:01:C3:2C UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:238564346874 errors:0 dropped:0 overruns:0 frame:0 TX packets:238564346874 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:224471746282797 (204.1 TiB) TX bytes:224471746282797 (204.1 TiB) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 18 февраля, 2013 · Жалоба Надо, но вообще-то оно работает, и работает хорошо. Хорошо нагруженный PPPoE BRAS, на ifb0 заворачивается трафик с bond-интерфейса(2х1G), реальный трафик до 1.5G. Такой подход усложняет масштабируемость и создает single point of failure. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 19 февраля, 2013 · Жалоба Оптимизировал работу шлюза с IPSET, результат на лицо. Теперь стоит задача с хэш фильтрами. У меня есть деление по подсетям: 1) Пиринг (около 50 подсетей) 2) Весь остальной трафик. На данный момент это реализовано тупо через линейный список, в конце которого u32 0.0.0.0 action egress redirect to dev ifb0. Никак не вьеду, как здесь прикрутить хэш фильтры. И имеет ли смысл? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 19 февраля, 2013 · Жалоба Сколько всего фильтров tc используется сейчас и для каких целей? Если меньше сотни, то хэширование не особо нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 19 февраля, 2013 (изменено) · Жалоба Сколько всего фильтров tc используется сейчас и для каких целей? Если меньше сотни, то хэширование не особо нужно. Сейчас у меня есть с десяток вланов, которые через tc filter фильтруют трафик подсеток и редиректят его на псевдодейвайсы (а на псевдодевайсах у меня весят классы + туда надо хэш фильтры затащить): 1. 123.45.0.0/18 -> ifb1 \ 2. 234.56.0.0/19 -> ifb1 - ПИРИНГ направлять на ifb1 ... / 50. 0.0.0.0/0 -> ifb0 - Весь остальной трафик на ifb0 Хочу оптимизировать это безобразие, т.к. эти фильтры на каждом интерфейсе (которые редиректят) Изменено 19 февраля, 2013 пользователем vasya_petrovich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 19 февраля, 2013 · Жалоба Сколько всего фильтров tc используется сейчас и для каких целей? Если меньше сотни, то хэширование не особо нужно. Сейчас у меня есть с десяток вланов, которые через tc filter фильтруют трафик подсеток и редиректят его на псевдодейвайсы (а на псевдодевайсах у меня весят классы + туда надо хэш фильтры затащить): 1. 123.45.0.0/18 -> ifb1 \ 2. 234.56.0.0/19 -> ifb1 - ПИРИНГ направлять на ifb1 ... / 50. 0.0.0.0/0 -> ifb0 - Весь остальной трафик на ifb0 Хочу оптимизировать это безобразие, т.к. эти фильтры на каждом интерфейсе (которые редиректят) 50 фильтров и так работают довольно быстро, проблема в избыточных копированиях трафика на псевдоустройства. Узким местом в этом случае является не процессор, а шина оперативной памяти. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 19 февраля, 2013 · Жалоба Да перестаньте, нет там никаких проблем. В IMQ помню мы еще упирались на железках уровня core duo, в IFB то же железо перестало упираться, а на современной платформе его вклад вообще копеечный. Все при окологигабитных скоростях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...