nuclearcat Опубликовано 6 января, 2009 · Жалоба Вы обозначьте лучше задачу, тогда подумаем как ее решить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boombastic Опубликовано 7 января, 2009 · Жалоба ip route add table 200 1.2.3.0/24 dev eth0ip route add table 200 default via 1.2.3.4 Т.е. отдельная таблица, 200 В таблицу можно классифицировать по src, dst адресу, tos, fwmark, входящему устройству, 2 nuclearcat, я хотел уточнить, как классифицировать трафик в нужную таблицу по входящему устройству? iptables -t mangle -i ethXXX -j MARK --set-mark YYYY и потом ip rule блабла fwmark ? или каким-то образом в ip rule можно сразу классифицировать по inbound interface? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 7 января, 2009 · Жалоба Гораздо проще ip rule add dev ethX table 200 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 7 января, 2009 · Жалоба Вот нашел интересную статью. http://www.opennet.ru/docs/RUS/GigabitEthernet/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 7 января, 2009 · Жалоба В этой статье мусолится собственно участие генератора и приемника траффика, но не транзитного роутера. Хотя дельных советов много. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 8 января, 2009 · Жалоба 2Sonne: Хорошая статья для тех, кто первый раз столкнулся с проблемой перегрузки роутера. Дает понять общие принципы функционирования и базовые настройки, хотя конкретные ситуации не разбираются, что плохо. Но почитать стоит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 9 января, 2009 · Жалоба 2nuclearcat: А Вы пробовали повышать HZ ядра выше, чем 1000? Если да, то каковы последствия, побочные эффекты и есть ли смысл в данном контексте? Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 10 января, 2009 · Жалоба Dark_Angel: Меня самого этот вопрос волнует :-) Пока еще не экспериментировал Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 13 января, 2009 (изменено) · Жалоба Видел, кстати на многих форумах вопрос без ответа, как проверить, работает ли NAPI в драйвере. Может кто не знает: Это видно по команде "vmstat 1" , когда количество прерываний резко меньше переключений контекста, скажем в 2-3 и более раз. При этом ksoftirqd немного подъедает процессорное время. 0.1 - 1 %. На RTT, а так же на скорость работы машины не влияет. Единственное что беспокоит, так это то что при большом количестве переключений контекста машина всеравно загнется. Пока данный порог не известен. Такая картина наблюдается на 2.4. Еще бывает видно, когда количество прерываний резко падает, к примеру, на порядок, при этом количество пакетов только растет. На 2.6 ядре несмотря на работу NAPI перключений контекста бывает меньше чем прерываний. Если чесно, я вообще не понимаю, почему и как такое может быть. Ведь каждое прерывание - это гарантировано 1, 2 переключение контекста. Ну в основном их либо примерно равно количество, либо немного больше в 2.6 Ваше мнение, почему так обстоит дело с 2.6 и 2.4 ядрами? Изменено 13 января, 2009 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a_andry Опубликовано 13 января, 2009 · Жалоба > Еще бывает видно, когда количество прерываний резко падает, к примеру, на порядок, при этом количество пакетов только растет. Сетевые интелы? Там при использовании NAPI есть несколько режимов, посмотрите в документации к модулю около InterruptThrottleRate. Может оно. Кстате кто нибудь использует I/O AT и/или DCA интеловские и с какими успехами? Буквально сегодня подняли эту радость, вроде и работает но изменений по загрузке не видно ( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 14 января, 2009 · Жалоба Кстати, хотел узнать. Можно ли на живом адаптере менять параметры драйвера, без его выгрузки? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a_andry Опубликовано 14 января, 2009 · Жалоба Можно то, что ethtool держит. Остальное специфичное для разных модулей наверно нет. Во всяком случая я не знаю как )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 14 января, 2009 (изменено) · Жалоба Поделюсь интересным наблюдением. Не знаю на сколько будет интересно, т.к. буду описывать для 2.4, но помогает немного понять природу захлебывания машины от pps. Ситуация: Роутер. 2.4 ( HZ = 1000 ) . Core Quad 2.4. Спустя какое-то время после старта ( 15 дней ) при прохождении такого же трафика как обычно ( 20-30 Kpps / 150 - 200 Мбит ) начинает тупить. i/s опускается до примерно 1К, cs/s ~= 50 K. Трафик падает до 10-15 Kpps, пинг подымется, но при этом машина из softirq выйти не может. Наш любимый ksoftirqd в топе на 100%. На машине есть fprobe, которая вводит интерфейс в промиск мод. Именно это дает такое cs/s. Если убрать fprobe машина начинает рисовать 100-200 cs/s. Если машине удается выйти из softirq - на это бывает нужно несколько десятков секунд, то драйвер начинает медленно подымать количество прерываний и пинг падает. 90% что дело в данной ситуации за fprobe и его promisc mode, потому как рядом стоит такая же машина, прожовывает этот же трафик. Там 2.6 ( HZ = 1000 ). И ей от этого трафика ни холодно ни жарко. Кроме того занимается еще и pptp терминацией от чего пакетов только больше. Все отличие, в том, что fprobe там нет. Следовательно вопрос: знает ли кто-то способ снять cisco netflow без ввода интерфейса в промиск мод и без этой самой cisco :) ? Как вариант я попробую еще поставить в драйвере InterruptThrottleRate=10000, жестко, потому как есть подозрение, что NAPI при входе в жесткий softirq начинает тупить. О результатах напишу. Изменено 14 января, 2009 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a_andry Опубликовано 14 января, 2009 · Жалоба Ipt-netflow вроде как designed for Linux router with heavy network load (http://sourceforge.net/projects/ipt-netflow/), может поможет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 14 января, 2009 · Жалоба Dark_Angel, зачем fprobe пускать через pcap? оно же умеет через iptables ulog трафик получать, там еще можно настроить отрезку только заголовка и количество одновременно скидываемых пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 14 января, 2009 · Жалоба Через ulog у меня fprobe почему-то получало трафика на 20-30% меньше, чем через pcap, причем точность была выше именно у последнего, судя по замерам, вот его и оставили. Вы такого не замечали? 2a_andry: А Вы пользовались этим? Работает нормально? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a_andry Опубликовано 15 января, 2009 · Жалоба Через ulog у меня fprobe почему-то получало трафика на 20-30% меньше, чем через pcap, причем точность была выше именно у последнего, судя по замерам, вот его и оставили. Вы такого не замечали? 2a_andry: А Вы пользовались этим? Работает нормально? Нет, пока только хотим перейти с ipcad на него. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 15 января, 2009 · Жалоба Я тут еще почитал и решил поставить InterruptThrottleRate=100000, т.е. максимально дискретный таймер. Посмотрим что получится. 2а_andry: Отпишитесь, пожалуйста, когда будут какие-то результаты. Очень интересно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azazello Опубликовано 15 января, 2009 · Жалоба Только fprobe через pcap на 100% скидывает верную инфу. Тестировали всё что смогли найти для linux. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 15 января, 2009 · Жалоба Dark_Angel, pcap и ulog я не сравнивал, к сожалению. Пожалуй, попробую снять суммарный трафик из логов mrtg и сравнить его с данными из биллинга... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 15 января, 2009 (изменено) · Жалоба 2azazello: Согласен, но учетом promisc mode надо подыскать что-то еще. На системах там 200-300 Мбит еще более-менее живет, но на больше - начинает убивать процессор. 2Nic: Напишите результат, пожалуйста. Я постараюсь тоже проверить и выложить результаты, потому как делали эти замеры еще на версии 0.8, если мне не изменяет память. Изменено 15 января, 2009 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yun Опубликовано 15 января, 2009 · Жалоба 2Dark_Angel - ipcad умеет без промиска Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 19 января, 2009 · Жалоба Попутно хотел провести профайлинг. Собрал oprofile, законфигал, запустил. Все по доке. При попытке взять репорт говорит ./opreport error: No sample file found: try running opcontrol --dump or specify a session containing sample files Лог в /var/lib/oprofile/samples/oprofiled.log пишется. При этом в /var/lib/oprofile/samples/current - пусто. Я так понимаю, там должны лежать файлы от демона по сесии. Может кто-то сталкивался с таким? Гугл находит только старые ошибки такого плана в древних билдах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Spectator Опубликовано 21 января, 2009 (изменено) · Жалоба О, наконецто нашел наболевшую тему. Сейчас правда всеми возможными способами пока работает нормально. тфу, тфу. :) Я тут еще почитал и решил поставить InterruptThrottleRate=100000, т.е. максимально дискретный таймер. Посмотрим что получится. Ничего путного с жесткой установкой не выйдет. Все очень сильно зависит от типа трафика. В Вашем случае будет хорошо ходить низколатантный трафик. Остальной просто дропаться. Я перепробывал массу вариантов и dynamic и dynamic conservative и жестко устанавливать кол-во. Самый оптимальный это режим 1. Причем у интела интересный момент в дровах если сетевых несколько то параметр указывается через запятую, но вот незадача если указать только для одной сетевой, то впечатление, что функция вообще не работает. В режиме 1 довольно большой предел по кол-ву генерируемых irq в сек - до 70000. Но бок в том, что если этот зловредный ksoftirqd ставит одно из ядер в полку, переключения на др кол-во прерываний в сек не происходит. Тут в начале темя было сообщение по поводу равномерного распределения прерываний по ядрам. При установке одной из ОС у меня каким то образом так получилось, но это не родные дрова. Оно работает и красиво при небольшом трафике. А вот когда переключаешь через эти сетевые хороший поток, система захлебывается. И это распределение исчезает, когда ставишь родные дрова. Кстати Intel выпустили новую версию дров e1000e в конце ноября 2008. Там пофиксано много багов. Изменено 21 января, 2009 пользователем Spectator Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 21 января, 2009 · Жалоба в e1000e можно этим параметром управлять динамически через ethtool -c Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...