bos9 Опубликовано 9 февраля, 2011 · Жалоба хочу убедиться, что не туплю... Есть маршрутизатор на linux, для подсчёта трафика на нем установлен агент биллинга (lanbilling 1.9), который работает с удалённой базой mysql. Заголовки отправляются в юзерспейс тремя правилами: iptables -t filter -A FORWARD -j ULOG --ulog-cprange 100 --ulog-nlgroup 1 iptables -t filter -A INPUT -j ULOG --ulog-cprange 100 --ulog-nlgroup 1 iptables -t filter -A OUTPUT -j ULOG --ulog-cprange 100 --ulog-nlgroup 1 последние два правила для подсчёта локального трафика самого сервера (не знаю к чему это, но так было до меня). Так вот, если эти два последних правила убрать, то агент биллинга жрет проц ощутимо меньше. Мои мысли по этому поводу сводятся к тому, что обработанные заголовки агент передает удалённой базе данных и так как это самый что ни на есть OUTPUT, то этот трафик опять попадает агенту и так до бесконечности... ничего не перепутал? ) И попутно второй вопрос. Снизится ли нагрузка, если пакеты в юзерспейс отправлять "кучками", используя ключ --ulog-qthreshold ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 9 февраля, 2011 · Жалоба Какой смысл на маршрутизаторе обсчитывать INPUT и OUTPUT на внутренних интерфейсах? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 10 февраля, 2011 · Жалоба Какой смысл на маршрутизаторе обсчитывать INPUT и OUTPUT на внутренних интерфейсах? ну я ж написал, что это до меня было ) я так сказать на все готовенькое пришёл - теперь разбираюсь ) кстати на бордере за месяц прилично входящего трафика набегает... BGP full view может на 27 гигов в месяц заливать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 11 февраля, 2011 · Жалоба INPUT - OUTPUT лучше убрать, т.к. это все же маршрутизатор вроде как. Пакеты лучше отправлять "кучками", но на сколько это снизит нагрузку в вашем случае сказать не могу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 15 февраля, 2011 · Жалоба и ещё на ipt_NETFLOW перейдите Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 15 февраля, 2011 · Жалоба и ещё на ipt_NETFLOW перейдите сравнивали с ulog? меньше ресурсов жрет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 15 февраля, 2011 · Жалоба и ещё на ipt_NETFLOW перейдите сравнивали с ulog? меньше ресурсов жрет? Существенно меньше, т.к. работает целиком в ядре. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 16 февраля, 2011 · Жалоба ulog ulog'ом, но ресурсопожираемость зависит от того как и чем потом эти данные собираются, куда посылаются и как дальше обрабатываются. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 16 февраля, 2011 · Жалоба ulog ulog'ом, но ресурсопожираемость зависит от того как и чем потом эти данные собираются, куда посылаются и как дальше обрабатываются. согласен, но в случае с ulog'ом "то чем данные собираются" - это процесс в юзерспейсе этого же маршрутизатора, а в случае с netflow коллектор может быть, где угодно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...