[nuclearcat]

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

 

[boombastic]

ip route add table 200 1.2.3.0/24 dev eth0

ip 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?

[nuclearcat]

Гораздо проще

 

ip rule add dev ethX table 200

 

[Sonne]

Вот нашел интересную статью.

 

http://www.opennet.ru/docs/RUS/GigabitEthernet/

[nuclearcat]

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

[Dark_Angel]

2Sonne: Хорошая статья для тех, кто первый раз столкнулся с проблемой перегрузки роутера. Дает понять общие принципы функционирования и базовые настройки, хотя конкретные ситуации не разбираются, что плохо. Но почитать стоит.

[Dark_Angel]

2nuclearcat: А Вы пробовали повышать HZ ядра выше, чем 1000? Если да, то каковы последствия, побочные эффекты и есть ли смысл в данном контексте? Спасибо.

[nuclearcat]

Dark_Angel: Меня самого этот вопрос волнует :-) Пока еще не экспериментировал

[Dark_Angel]

Видел, кстати на многих форумах вопрос без ответа, как проверить, работает ли 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

[a_andry]

> Еще бывает видно, когда количество прерываний резко падает, к примеру, на порядок, при этом количество пакетов только растет.

 

Сетевые интелы? Там при использовании NAPI есть несколько режимов, посмотрите в документации к модулю около InterruptThrottleRate. Может оно.

 

Кстате кто нибудь использует I/O AT и/или DCA интеловские и с какими успехами? Буквально сегодня подняли эту радость, вроде и работает но изменений по загрузке не видно (

 

[Dark_Angel]

Кстати, хотел узнать. Можно ли на живом адаптере менять параметры драйвера, без его выгрузки?

[a_andry]

Можно то, что ethtool держит. Остальное специфичное для разных модулей наверно нет. Во всяком случая я не знаю как ))

[Dark_Angel]

Поделюсь интересным наблюдением. Не знаю на сколько будет интересно, т.к. буду описывать для 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

[a_andry]

Ipt-netflow вроде как designed for Linux router with heavy network load (http://sourceforge.net/projects/ipt-netflow/), может поможет.

 

[Nic]

Dark_Angel, зачем fprobe пускать через pcap? оно же умеет через iptables ulog трафик получать, там еще можно настроить отрезку только заголовка и количество одновременно скидываемых пакетов.

[Dark_Angel]

Через ulog у меня fprobe почему-то получало трафика на 20-30% меньше, чем через pcap, причем точность была выше именно у последнего, судя по замерам, вот его и оставили. Вы такого не замечали?

 

2a_andry: А Вы пользовались этим? Работает нормально?

[a_andry]

Через ulog у меня fprobe почему-то получало трафика на 20-30% меньше, чем через pcap, причем точность была выше именно у последнего, судя по замерам, вот его и оставили. Вы такого не замечали?

 

2a_andry: А Вы пользовались этим? Работает нормально?

Нет, пока только хотим перейти с ipcad на него.

 

[Dark_Angel]

Я тут еще почитал и решил поставить InterruptThrottleRate=100000, т.е. максимально дискретный таймер. Посмотрим что получится.

 

2а_andry: Отпишитесь, пожалуйста, когда будут какие-то результаты. Очень интересно.

[azazello]

Только fprobe через pcap на 100% скидывает верную инфу. Тестировали всё что смогли найти для linux.

[Nic]

Dark_Angel, pcap и ulog я не сравнивал, к сожалению. Пожалуй, попробую снять суммарный трафик из логов mrtg и сравнить его с данными из биллинга...

[Dark_Angel]

2azazello: Согласен, но учетом promisc mode надо подыскать что-то еще. На системах там 200-300 Мбит еще более-менее живет, но на больше - начинает убивать процессор.

 

2Nic: Напишите результат, пожалуйста. Я постараюсь тоже проверить и выложить результаты, потому как делали эти замеры еще на версии 0.8, если мне не изменяет память.

Изменено 15 января, 2009 пользователем Dark_Angel

[yun]

2Dark_Angel - ipcad умеет без промиска

[Dark_Angel]

Попутно хотел провести профайлинг. Собрал 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 - пусто. Я так понимаю, там должны лежать файлы от демона по сесии.

 

Может кто-то сталкивался с таким? Гугл находит только старые ошибки такого плана в древних билдах.

[Spectator]

О, наконецто нашел наболевшую тему.

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

 

Я тут еще почитал и решил поставить InterruptThrottleRate=100000, т.е. максимально дискретный таймер. Посмотрим что получится.

Ничего путного с жесткой установкой не выйдет.

Все очень сильно зависит от типа трафика.

В Вашем случае будет хорошо ходить низколатантный трафик. Остальной просто дропаться.

Я перепробывал массу вариантов и dynamic и dynamic conservative и жестко устанавливать кол-во.

Самый оптимальный это режим 1.

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

В режиме 1 довольно большой предел по кол-ву генерируемых irq в сек - до 70000.

Но бок в том, что если этот зловредный ksoftirqd ставит одно из ядер в полку, переключения на др кол-во прерываний в сек не происходит.

 

Тут в начале темя было сообщение по поводу равномерного распределения прерываний по ядрам.

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

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

И это распределение исчезает, когда ставишь родные дрова.

 

Кстати Intel выпустили новую версию дров e1000e в конце ноября 2008. Там пофиксано много багов.

Изменено 21 января, 2009 пользователем Spectator

[nuclearcat]

в e1000e можно этим параметром управлять динамически через ethtool -c