Перейти к содержимому
Калькуляторы

Добрый день.

Господа, помогите оптимизировать работу шлюза.

Имеем 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 ядерный амд.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что можете посоветовать по оптимизации? Пока только думаю увеличивать мощность поставить 8 ядерный амд.

Это тупиковый путь. Однозначно стоит забыть про такой "апгрейд".

 

Как минимум убрать вот это QueuePairs=1,1,1,1 LLIPort=80 из опций драйвера и попытаться вынести NAT с этой машины на другую, которую поставить чуть дальше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что можете посоветовать по оптимизации? Пока только думаю увеличивать мощность поставить 8 ядерный амд.

Это тупиковый путь. Однозначно стоит забыть про такой "апгрейд".

 

Как минимум убрать вот это QueuePairs=1,1,1,1 LLIPort=80 из опций драйвера и попытаться вынести NAT с этой машины на другую, которую поставить чуть дальше.

т.е. Вы предлагаете вынести нат дальше, а на этой машине не классифицировать траффик, а использовать хеш фильтры?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще вопрос о таком кол-ве правил в iptables. Может быть стоит эти сложности разобрать по косточкам и выяснить как уменьшить это кол-во?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще вопрос о таком кол-ве правил в iptables. Может быть стоит эти сложности разобрать по косточкам и выяснить как уменьшить это кол-во?

Согласен.

Думал над этим. Просто изначально не правильно продумал, вот и получил результат.

 

Еще один вопрос.

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

Поможет ли мне включение гипертрединга? И не будет ли вываливаться ядро в кору?

Изменено пользователем vasya_petrovich

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8-миядерный амд на самом деле 4-хядерный, сделаете только хуже. Да и не в количестве ядер тут дело, а в удельной частоте ядра.

Гипертрединг вообще никакой погоды не делает, хоть и гуляет мнение что он даже вреден.

Однозначно ветвить правила, 3к последовательно это очень много. Посмотреть в сторону поменять местами порядок полисинга и ната чтобы использовать хеши.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чините iptables. Зачем там 6000 правил??? Если это разрешение/запрет клиентам - залейте его в ipset и используйте 1 правило, получите разгрузку раз в 10 минимум.

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поможет ли мне включение гипертрединга? И не будет ли вываливаться ядро в кору?

На ядрах 3.2.x - 3.7.x и камнях E3-E5 Xeon таки допилили HT до приемлемого уровня. Поэтому, если приобретете когда-нибудь мат. плату на чипсете Intel C20x, 60x, то включайте. Все будет шоколадно.

 

С более ранними ядрами, старыми ОС, старым железом и т.п. действительно вылезали неприятные косяки и были перекосы по нагрузке на ядра. В последнее время вроде как детские болезни прошли, но нужна новая программно-аппаратная основа для юзанья HT.

Изменено пользователем replicant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8-миядерный амд на самом деле 4-хядерный, сделаете только хуже.

8 полноценных целочисленных ядер, разве что декодер команд общий. Проблема у амд в другом кроется..

 

Да и не в количестве ядер тут дело, а в удельной частоте ядра.

Не угадали. Ключевую роль играют как раз латентность памяти и кешей.

 

По сабжу - да, цепочки ветвить или юзать ipset; htb - хеш-фильтры строить; очереди на сетевухах повключать по кол-ву ядер и привязать очередь к ядру... Дальше уже думать, если не хватит производительности, над более глубокими оптимиациями

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не угадали. Ключевую роль играют как раз латентность памяти и кешей.

А оно с каких-то пор не соотносится к частоте? Подбором железа занимаюсь не я в основном, мог пропустить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Господа, спасибо за советы.

Уже занимаюсь оптимизацией (ipset, хэш фильтры htb)

О резалтах сообщу позже.

 

Нитро, в чем скрытая проблема у амд?

Изменено пользователем vasya_petrovich

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Столкнулся с непонятным для меня сабжем.

Чтобы обойти проблему НАТ, решил снимать трафик с внутренних интерфейсов (вход и исход) и редиректить их на IFB устройства.

На внутренний интерфейс прилепил дисциплину ингресс, и добавил фильтр для редиректа трафика на псевдойстройство. Фильтр отрабатывает как надо, НО! ком*** tc -s filter show dev $MY_INTERNAL_INTERFACE ничего не показывает.

Почему?

Изменено пользователем vasya_petrovich

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А оно с каких-то пор не соотносится к частоте?

Куда больше соотносится с особенностями архитектуры. Сравните латентность интела и амд.

 

Нитро, в чем скрытая проблема у амд?

Написал уже: латентность кешей/памяти больше...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А, ну с этой точки зрения да, логично. Просто кроме Xeon'ов ничего не закупаем)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Столкнулся с непонятным для меня сабжем.

Чтобы обойти проблему НАТ, решил снимать трафик с внутренних интерфейсов (вход и исход) и редиректить их на IFB устройства.

На внутренний интерфейс прилепил дисциплину ингресс, и добавил фильтр для редиректа трафика на псевдойстройство. Фильтр отрабатывает как надо, НО! ком*** tc -s filter show dev $MY_INTERNAL_INTERFACE ничего не показывает.

Почему?

Оказывается все просто: tc -s filter show dev $MY_INTERNAL_INTERFACE parent ffff:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как победить большое кол-во дропов на псевдоустройстве IFB?

Заворачиваю туда трафик и дроппед начинает расти. Хотя я еще не повесил ни одну дисциплину tc.

В чем засада?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надо отказываться от использования псевдоустройств и распределить разные функции по нескольким машинам (одна машина или коммутатор для терминации вланов, другая -- шейпирующий мост, третья -- border router c NAT и Netflow).

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надо отказываться от использования псевдоустройств и распределить разные функции по нескольким машинам (одна машина или коммутатор для терминации вланов, другая -- шейпирующий мост, третья -- border router c NAT и Netflow).

+1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надо, но вообще-то оно работает, и работает хорошо.

Хорошо нагруженный 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)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надо, но вообще-то оно работает, и работает хорошо.

Хорошо нагруженный PPPoE BRAS, на ifb0 заворачивается трафик с bond-интерфейса(2х1G), реальный трафик до 1.5G.

Такой подход усложняет масштабируемость и создает single point of failure.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Оптимизировал работу шлюза с IPSET, результат на лицо. Теперь стоит задача с хэш фильтрами.

У меня есть деление по подсетям:

1) Пиринг (около 50 подсетей)

2) Весь остальной трафик.

 

На данный момент это реализовано тупо через линейный список, в конце которого u32 0.0.0.0 action egress redirect to dev ifb0.

Никак не вьеду, как здесь прикрутить хэш фильтры. И имеет ли смысл?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сколько всего фильтров tc используется сейчас и для каких целей? Если меньше сотни, то хэширование не особо нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сколько всего фильтров 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

 

Хочу оптимизировать это безобразие, т.к. эти фильтры на каждом интерфейсе (которые редиректят)

Изменено пользователем vasya_petrovich

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сколько всего фильтров 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 фильтров и так работают довольно быстро, проблема в избыточных копированиях трафика на псевдоустройства. Узким местом в этом случае является не процессор, а шина оперативной памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да перестаньте, нет там никаких проблем. В IMQ помню мы еще упирались на железках уровня core duo, в IFB то же железо перестало упираться, а на современной платформе его вклад вообще копеечный. Все при окологигабитных скоростях.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.