tawer Posted November 7, 2013 · Report post возвращаясь к посту http://forum.nag.ru/forum/index.php?showtopic=46335&view=findpost&p=894019 отчего то сразу не заметил, но растет значение счетчика rx_no_dma_resources, гугление по данному вопросу однозначного метода борьбы не дало, поделитесь опытом, коллеги. Share this post Link to post Share on other sites
Drzlo007 Posted November 7, 2013 · Report post Здраствуйте. Извените если не в тему. Есть проблема с шейпером tbf. Не шейпит нормально. Скорость на закачку очень оочень маленькая. У меня стоит accel-ppp которий записивает правила. Все правила пишуться правильно. Но скорость низкая. А если удалить правило і поставить правило с большим mtu всьо начинает работать нармальна. accel-ppp не нашол метода ставить большой mtu. Да і думаю что ето не нормально. С такими параметрами у меня скорость режит нормально tc q a dev ppp418 root tbf rate 50Mbit burst 625kb latency 5ms mtu 5000 Стоит Debian 7. Подскажите в чьом беда. Буду примного благодарен. Share this post Link to post Share on other sites
photon Posted November 7, 2013 (edited) · Report post Сервер из предыдущего сообщения... Переделал шейпер 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. Edited November 7, 2013 by photon Share this post Link to post Share on other sites
morfair Posted November 8, 2013 · Report post При выборе процессора на форвардинг (плюс терминация VPN) стоит ли учитывать модель процессора (Intel Core 2 Quad, i5, i7, Xeon и т.д.) или в первую очередь нужно ориентироваться на количество ядер и тактовую частоту для обработки прерываний? Ессно надо смотреть на семейство. Ориентир - минимальная латентность кешей/памяти и производительность ядра. Ну и ядра с гигагерцами ессно тоже не помешают, но при прочих равных - даже в среднепотолочной вычислительной нагрузке модный некогда Е8500 где-то на уровне целерона G1610-1620. На роутинге - думается, у старых процов будет все еще печальнее. А можете подсказать примеры "проверенных" процессоров? Share this post Link to post Share on other sites
Painter Posted November 8, 2013 · Report post Сервер из предыдущего сообщения... Переделал шейпер 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 сложнее Share this post Link to post Share on other sites
s.lobanov Posted November 8, 2013 · Report post С sfq всё хорошо, кроме одного, максимальный буфер всего 127 пакетов Share this post Link to post Share on other sites
NiTr0 Posted November 8, 2013 · Report post А можете подсказать примеры "проверенных" процессоров? Интел, чем свежее семейство тем лучше. Зион или десктопный - без разницы, ЕСС не нужно в принципе на роутере, а других преимуществ у одиночного зиона нет. Цель перехода с pfifo на sfq - справедливое разделение полосы между потоками. Например начинаем качать торренты, упираемся в полку и с pfifo yandex.ru уже не откроешь или очень очень медленно. Так отделите мухи от котлет, поставьте везде sfq или pfifo, и тогда уж делайте выводы о производительности шейпера. Share this post Link to post Share on other sites
photon Posted November 8, 2013 (edited) · Report post Цель перехода с pfifo на sfq - справедливое разделение полосы между потоками. Например начинаем качать торренты, упираемся в полку и с pfifo yandex.ru уже не откроешь или очень очень медленно. Я понимаю, что sfq сложнее На мой взгляд, приоритизацию типов трафика лучше делать на пренастроенном роутере, который юзер покупает или получает бесплатно при заключении договора с минимальным сроком на несколько лет. Такая возможность есть, к примеру, в прошивке dd-wrt. При желании и умении юзер сам может создавать правила приоритизации, если его что-то не устраивает. Иначе все это выливается в дополнительные технические проблемы на стороне провайдера. Edited November 8, 2013 by photon Share this post Link to post Share on other sites
vitalyb Posted November 8, 2013 · Report post просто пропустить tcp ack мимо шейпера в первую очередь не вариант? Share this post Link to post Share on other sites
photon Posted November 8, 2013 · Report post Как вариант, можно настроить приоритизацию трафика (по портам, по флагам TCP и прочим признакам) на бордере или на какой-то отдельной машине за шейпером. Создавать такие правила внутри каждого класса весьма накладно. Share this post Link to post Share on other sites
vitalyb Posted November 8, 2013 · Report post а внутри каждого и не надо - все ack'и без полезной нагрузки в один отдельный класс и пусть идут в первую очередь Share this post Link to post Share on other sites
evil-man Posted November 9, 2013 · Report post Есть проблема с шейпером tbf. Не шейпит нормально. Скорость на закачку очень оочень маленькая. У меня стоит accel-ppp которий записивает правила. Все правила пишуться правильно. Но скорость низкая. А если удалить правило і поставить правило с большим mtu всьо начинает работать нармальна. accel-ppp не нашол метода ставить большой mtu. Да і думаю что ето не нормально. С такими параметрами у меня скорость режит нормально tc q a dev ppp418 root tbf rate 50Mbit burst 625kb latency 5ms mtu 5000 Стоит Debian 7. Подскажите в чьом беда. Буду примного благодарен. Посмотри, какие оффлоады включены на сетевушках. Отключи лишние. Share this post Link to post Share on other sites
morfair Posted November 11, 2013 · Report post Господа, готовлю заказ на сервер доступа (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 портов нету). Взглянув со всей высоты своего опыта скажите, чего я от этого могу ожидать? Пойдет или что-то лучше поменять? Share this post Link to post Share on other sites
DVM-Avgoor Posted November 11, 2013 · Report post i7-4820K наверное поинтересней будет, 4 канала памяти, 10мб кэша... Share this post Link to post Share on other sites
NiTr0 Posted November 11, 2013 · Report post i7-4820K наверное поинтересней будет, 4 канала памяти, 10мб кэша... 4 канала реально не нужны, профита с них не будет. 10 метров кеша по сравнению с 8м - не факт, что даст существенный прирост, особенно если не будет FV приниматься тазиком. А вообще - вместо i7 вполне можно ставить i5. От гипертрейдинга профита особо нет. Да и 2+2 гига трафика данная система должна легко пережевать (если ессно не городить портянки правил файрвола/классификатора трафика). Share this post Link to post Share on other sites
DVM-Avgoor Posted November 11, 2013 · Report post 4 канала реально не нужны, профита с них не будет. 10 метров кеша по сравнению с 8м - не факт, что даст существенный прирост, особенно если не будет FV приниматься тазиком. Who knows. Никто не пробовал же, наверняка :) Share this post Link to post Share on other sites
legioner0 Posted November 12, 2013 (edited) · Report post 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 Edited November 12, 2013 by legioner0 Share this post Link to post Share on other sites
morfair Posted November 12, 2013 · Report post 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 Оуу, да, спасибо, чуть не лоханулся. Share this post Link to post Share on other sites
NiTr0 Posted November 12, 2013 · Report post Никто не пробовал же, наверняка :) Народ роде как тестил лга1366. Разницы между 2 и 3 каналами памяти не заметили... Share this post Link to post Share on other sites
BiWiS Posted November 16, 2013 · Report post Господа, кто нибудь переходил с Centos 5 (2.6.18) на Centos 6 (3.10.17) с htb шейпером? Что они такое поломали/сменили? В пятерке скрипт генерации и применения правил отрабатывал за несколько секунд, в шестерке тупит больше минуты (объем генерируемых правил примерно 1Мбайт). Скорость резать стал тоже неправильно. Share this post Link to post Share on other sites
kayot Posted November 16, 2013 · Report post У меня одни и те же скрипты работают на fedora 8(2.6.32), centos 5.3(2.6.18) и centos 6.4(3.10.4) - никакой разницы. Скорость применения зависит от числа интерфейсов(тех же ppp или vlan) в системе, не менялось их число? Share this post Link to post Share on other sites
BiWiS Posted November 16, 2013 · Report post Нет, поменялось ядро. Решили взять свежайшее при обновлении :) Откат с 3.10.18 до 2.6.32 решил всю проблему. А заключается она в работе с ifb, ipt_netflow точнее упирании в производительность машины на данном ядре. Слишком много копирований данных в памяти. Share this post Link to post Share on other sites
morfair Posted November 17, 2013 · Report post Люди, а бондинг сильно грузит систему при большом трафике? Интересует 802.3ad L2+3 Share this post Link to post Share on other sites
heap Posted November 18, 2013 (edited) · Report post Люди, а бондинг сильно грузит систему при большом трафике? Интересует 802.3ad L2+3 Как по моим ощущениям - совсем не ощутимо. Edited November 18, 2013 by heap Share this post Link to post Share on other sites
kaktak Posted November 19, 2013 (edited) · Report post Помогите советом. Дано: старенький xeon + 3 стареньких NIC (по одной queue на порт) Что будет эффективнее в таком случае? Прибивать сетевки к ядрам (тогда одно ядро простаивает, а остальные довольно сильно загружены в пиках) или размазывать прерывания от каждой сетевки на все 4-е ядра (в этом случае визуально нагрузка размазывается, но не совсем понятно, что там с локами и т.д.)? Edited November 19, 2013 by kaktak Share this post Link to post Share on other sites
