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

возвращаясь к посту http://forum.nag.ru/forum/index.php?showtopic=46335&view=findpost&p=894019

отчего то сразу не заметил, но растет значение счетчика rx_no_dma_resources, гугление по данному вопросу однозначного метода борьбы не дало, поделитесь опытом, коллеги.

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


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

Здраствуйте. Извените если не в тему.

Есть проблема с шейпером tbf.

Не шейпит нормально. Скорость на закачку очень оочень маленькая.

У меня стоит accel-ppp которий записивает правила.

Все правила пишуться правильно. Но скорость низкая.

А если удалить правило і поставить правило с большим mtu всьо начинает работать нармальна.

accel-ppp не нашол метода ставить большой mtu. Да і думаю что ето не нормально.

С такими параметрами у меня скорость режит нормально

tc q a dev ppp418 root tbf rate 50Mbit burst 625kb latency 5ms mtu 5000

Стоит Debian 7.

Подскажите в чьом беда. Буду примного благодарен.

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


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

Сервер из предыдущего сообщения...

 

Переделал шейпер c HTB+pfifo на HFSC+sfq, нагрузка возросла на 6%, а не снизилась в 2-3 как тут писали выше. Так же увеличилось количество переключений контекста с 5,5к до 11к (в 2 раза)

Неудивительно, т.к. sfq более сложная дисциплина, чем pfifo. В чем заключается цель такого перехода? Если появляются потери пакетов из-за переполнения очереди, нужно увеличить размеры rx/tx rings с помощью ethtool, увеличить параметр limit у pfifo. Вместо pfifo также можно использовать red. Да, и iptables с шейпера хорошо бы убрать. Блокировать трафик можно прямо в tc с помощью filter actions.

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

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


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

При выборе процессора на форвардинг (плюс терминация VPN) стоит ли учитывать модель процессора (Intel Core 2 Quad, i5, i7, Xeon и т.д.) или в первую очередь нужно ориентироваться на количество ядер и тактовую частоту для обработки прерываний?

Ессно надо смотреть на семейство. Ориентир - минимальная латентность кешей/памяти и производительность ядра. Ну и ядра с гигагерцами ессно тоже не помешают, но при прочих равных - даже в среднепотолочной вычислительной нагрузке модный некогда Е8500 где-то на уровне целерона G1610-1620. На роутинге - думается, у старых процов будет все еще печальнее.

А можете подсказать примеры "проверенных" процессоров?

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


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

Сервер из предыдущего сообщения...

 

Переделал шейпер c HTB+pfifo на HFSC+sfq, нагрузка возросла на 6%, а не снизилась в 2-3 как тут писали выше. Так же увеличилось количество переключений контекста с 5,5к до 11к (в 2 раза)

Неудивительно, т.к. sfq более сложная дисциплина, чем pfifo. В чем заключается цель такого перехода? Если появляются потери пакетов из-за переполнения очереди, нужно увеличить размеры rx/tx rings с помощью ethtool, увеличить параметр limit у pfifo. Вместо pfifo также можно использовать red. Да, и iptables с шейпера хорошо бы убрать. Блокировать трафик можно прямо в tc с помощью filter actions.

 

Цель перехода с pfifo на sfq - справедливое разделение полосы между потоками. Например начинаем качать торренты, упираемся в полку и с pfifo yandex.ru уже не откроешь или очень очень медленно.

 

Я понимаю, что sfq сложнее

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


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

С sfq всё хорошо, кроме одного, максимальный буфер всего 127 пакетов

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


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

А можете подсказать примеры "проверенных" процессоров?

Интел, чем свежее семейство тем лучше. Зион или десктопный - без разницы, ЕСС не нужно в принципе на роутере, а других преимуществ у одиночного зиона нет.

 

Цель перехода с pfifo на sfq - справедливое разделение полосы между потоками. Например начинаем качать торренты, упираемся в полку и с pfifo yandex.ru уже не откроешь или очень очень медленно.

Так отделите мухи от котлет, поставьте везде sfq или pfifo, и тогда уж делайте выводы о производительности шейпера.

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


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

Цель перехода с pfifo на sfq - справедливое разделение полосы между потоками. Например начинаем качать торренты, упираемся в полку и с pfifo yandex.ru уже не откроешь или очень очень медленно.

 

Я понимаю, что sfq сложнее

На мой взгляд, приоритизацию типов трафика лучше делать на пренастроенном роутере, который юзер покупает или получает бесплатно при заключении договора с минимальным сроком на несколько лет. Такая возможность есть, к примеру, в прошивке dd-wrt. При желании и умении юзер сам может создавать правила приоритизации, если его что-то не устраивает. Иначе все это выливается в дополнительные технические проблемы на стороне провайдера.

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

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


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

просто пропустить tcp ack мимо шейпера в первую очередь не вариант?

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


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

Как вариант, можно настроить приоритизацию трафика (по портам, по флагам TCP и прочим признакам) на бордере или на какой-то отдельной машине за шейпером. Создавать такие правила внутри каждого класса весьма накладно.

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


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

а внутри каждого и не надо - все ack'и без полезной нагрузки в один отдельный класс и пусть идут в первую очередь

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


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

Есть проблема с шейпером tbf.

Не шейпит нормально. Скорость на закачку очень оочень маленькая.

У меня стоит accel-ppp которий записивает правила.

Все правила пишуться правильно. Но скорость низкая.

А если удалить правило і поставить правило с большим mtu всьо начинает работать нармальна.

accel-ppp не нашол метода ставить большой mtu. Да і думаю что ето не нормально.

С такими параметрами у меня скорость режит нормально

tc q a dev ppp418 root tbf rate 50Mbit burst 625kb latency 5ms mtu 5000

Стоит Debian 7.

Подскажите в чьом беда. Буду примного благодарен.

 

Посмотри, какие оффлоады включены на сетевушках. Отключи лишние.

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


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

Господа, готовлю заказ на сервер доступа (pptp, l2tp, routing) со следующей конфигурацией:

 

M/b: Intel DH87RL (OEM) LGA1150 < H87> PCI-E DVI+HDMI+DP GbLAN SATA RAID MicroATX 4DDR-III

CPU: Intel Core i7-4771 BOX 3.5 ГГц / 4core / SVGA HD Graphics 4600 / 1+8Мб / 84 Вт / 5 ГТ / с LGA1150

RAM: Kingmax DDR-III DIMM 2Gb < PC3-12800> (2 шт.)

NIC: Intel 82576 (2 шт., в бондинг, 10G портов нету).

 

Взглянув со всей высоты своего опыта скажите, чего я от этого могу ожидать? Пойдет или что-то лучше поменять?

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


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

i7-4820K наверное поинтересней будет, 4 канала памяти, 10мб кэша...

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


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

i7-4820K наверное поинтересней будет, 4 канала памяти, 10мб кэша...

4 канала реально не нужны, профита с них не будет. 10 метров кеша по сравнению с 8м - не факт, что даст существенный прирост, особенно если не будет FV приниматься тазиком.

 

А вообще - вместо i7 вполне можно ставить i5. От гипертрейдинга профита особо нет. Да и 2+2 гига трафика данная система должна легко пережевать (если ессно не городить портянки правил файрвола/классификатора трафика).

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


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

4 канала реально не нужны, профита с них не будет. 10 метров кеша по сравнению с 8м - не факт, что даст существенный прирост, особенно если не будет FV приниматься тазиком.

 

Who knows. Никто не пробовал же, наверняка :)

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


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

M/b: Intel DH87RL (OEM) LGA1150 < H87> PCI-E DVI+HDMI+DP GbLAN SATA RAID MicroATX 4DDR-III

...

NIC: Intel 82576 (2 шт., в бондинг, 10G портов нету).

Карты Intel 82576 оснащены разъемом PCI-E x4, а на DH87RL есть только один x16 и три x1. Не оптимально как-то.

 

Лучше, наверное, INTEL DH87MC (RTL) LGA1150 <H87> PCI-E DVI+HDMI+DP GbLAN SATA RAID ATX 4DDR-III взять - два PCI-E x16

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

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


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

M/b: Intel DH87RL (OEM) LGA1150 < H87> PCI-E DVI+HDMI+DP GbLAN SATA RAID MicroATX 4DDR-III

...

NIC: Intel 82576 (2 шт., в бондинг, 10G портов нету).

Карты Intel 82576 оснащены разъемом PCI-E x4, а на DH87RL есть только один x16 и три x1. Не оптимально как-то.

 

Лучше, наверное, INTEL DH87MC (RTL) LGA1150 <H87> PCI-E DVI+HDMI+DP GbLAN SATA RAID ATX 4DDR-III взять - два PCI-E x16

 

Оуу, да, спасибо, чуть не лоханулся.

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


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

Никто не пробовал же, наверняка :)

Народ роде как тестил лга1366. Разницы между 2 и 3 каналами памяти не заметили...

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


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

Господа, кто нибудь переходил с Centos 5 (2.6.18) на Centos 6 (3.10.17) с htb шейпером?

Что они такое поломали/сменили?

В пятерке скрипт генерации и применения правил отрабатывал за несколько секунд, в шестерке тупит больше минуты (объем генерируемых правил примерно 1Мбайт). Скорость резать стал тоже неправильно.

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


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

У меня одни и те же скрипты работают на fedora 8(2.6.32), centos 5.3(2.6.18) и centos 6.4(3.10.4) - никакой разницы.

Скорость применения зависит от числа интерфейсов(тех же ppp или vlan) в системе, не менялось их число?

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


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

Нет, поменялось ядро. Решили взять свежайшее при обновлении :)

Откат с 3.10.18 до 2.6.32 решил всю проблему.

А заключается она в работе с ifb, ipt_netflow точнее упирании в производительность машины на данном ядре. Слишком много копирований данных в памяти.

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


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

Люди, а бондинг сильно грузит систему при большом трафике? Интересует 802.3ad L2+3

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


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

Люди, а бондинг сильно грузит систему при большом трафике? Интересует 802.3ad L2+3

 

Как по моим ощущениям - совсем не ощутимо.

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

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


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

Помогите советом.

Дано: старенький xeon + 3 стареньких NIC (по одной queue на порт)

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

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

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


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

Join the conversation

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

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

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

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

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

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

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