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