Stargazer грузит процессор на 100%

[speedfire87 15]

Доброго времени суток, может кто подскажет проблема в следующем, как то начались большие пинги на сервер запускаю htop смотрю а "Stargazer v 2.406-rc1 Module: 'ipq_cap v.1.2" отжигает грузит второе ядро процессора на 100% и естественно тупит вся машина, что можно с этим сделать? Процессор amd athlon dual core 2,4 1024 cache L2,67-юзеров,примерно 40 онлайн, база данных mysql, 2 сетивые 100mbit.

[Foster 0]

Доброго времени суток, может кто подскажет проблема в следующем, как то начались большие пинги на сервер запускаю htop смотрю а Stargazer v 2.406-rc1 отжигает грузит второе ядро процессора на 100% и естественно тупит вся машина, что можно с этим сделать? Процессор amd athlon dual core 2,4 1024 cache L2

 

еще бы указал что считает и как.

Был подобный вопрос, но там считалось всё, а трафик бегал в районе 40мегабит, перевел на ip_queue

[speedfire87 15]

еще бы указал что считает и как.

Был подобный вопрос, но там считалось всё, а трафик бегал в районе 40мегабит, перевел на ip_queue

 

Module: 'ipq_cap v.1.2'."

[madf 279]

Попробуй релиз вместо rc1.

Сколько пользователей обслуживает? Какое хранилище используется?

[speedfire87 15]

Попробуй релиз вместо rc1.

Сколько пользователей обслуживает? Какое хранилище используется?

67-юзеров,примерно 40 онлайн, база данных mysql, 2 сетивые 100mbit.

[madf 279]

Попробуй релиз вместо rc1.

Сколько пользователей обслуживает? Какое хранилище используется?

67-юзеров,примерно 40 онлайн, база данных mysql, 2 сетивые2 сетивые 100mbit.

Может DoS'ят?

[nightfly 1 221]

а не rl ли?

[stvol 4]

а не rl ли?

А что Риалтек начинает подглючивать при таком колве пользователей?

[nightfly 1 221]

риалтек начинает подглючивать даже будучи лежащим в ящике стола.

 

xl/em only!

[madf 279]

Дело в том что я такое поведение Stargazer наблюдал лично 1 раз (правда на 1600/4000 пользователях) и один раз мне об этом наши админы сообщили.

К сожалению, в первый раз я не додумался к нему подцепиться gdb чтобы посмотреть что там происходит, а во второй раз это вообще на выходных было. Теперь жду третьего раза.

Хотя на самом деле это может быть и не вина Stargazer'а - на той машине на которой это наблюдалось сыпется винт. Возможно это послужило причиной.

[speedfire87 15]

Проблема заключалсь в cap_ipq ,поставил fprobe с и все нормально.

[Shtorm 0]

Тоже на выходных видел ,

что Stargazer грузит проц на 99.9%

Сегодня утром смотрю 3-20 % загрузка не совсем понятно в чем проблема

 

Правда утром абонентов раза в 3-4 меньше чем вечером ...

На что обратить внимание ??

Что прислать в студию ?

[madf 279]

Тоже на выходных видел ,

что Stargazer грузит проц на 99.9%

Сегодня утром смотрю 3-20 % загрузка не совсем понятно в чем проблема

 

Правда утром абонентов раза в 3-4 меньше чем вечером ...

На что обратить внимание ??

Что прислать в студию ?

Собрать с отладочной информацией (ни в коем случае не делать make install или make install-bin (они делают strip) а раскидать файлы руками).

Дождаться такой загрузки.

Подцепиться к нему gdb и сделать бектрейс всех потоков:

# gdb /path/to/stargazer
(gdb) attach pid
(gdb) thread apply all bt

Полученный выхлоп закинуть мне в почту: faust@stg.dp.ua

 

Проблема заключалсь в cap_ipq ,поставил fprobe с и все нормально.

Вряд ли

[Shtorm 0]

Собрать с отладочной информацией (ни в коем случае не делать make install или make install-bin (они делают strip) а раскидать файлы руками).

 

А как собрать ?

запускал

 

./devbuild

#############################################################################

Building STG 2.4 for Linux

#############################################################################

Checking endianess... Little Endian

Checking for -lexpat... yes

Checking for -lfbclient... no

Checking for mysql_config... no

Checking for -lmysqlclient... no

Checking for pg_config... yes

Checking for pg_config --includedir... [/usr/include/pgsql]

Checking for pg_config --libdir... [/usr/lib]

 

Debug build. Type make explicitly

 

И на єтом все кончилось , бинарников не создалось никаких

[madf 279]

Собрать с отладочной информацией (ни в коем случае не делать make install или make install-bin (они делают strip) а раскидать файлы руками).

 

А как собрать ?

запускал

 

./devbuild

#############################################################################

Building STG 2.4 for Linux

#############################################################################

Checking endianess... Little Endian

Checking for -lexpat... yes

Checking for -lfbclient... no

Checking for mysql_config... no

Checking for -lmysqlclient... no

Checking for pg_config... yes

Checking for pg_config --includedir... [/usr/include/pgsql]

Checking for pg_config --libdir... [/usr/lib]

 

Debug build. Type make explicitly

 

И на єтом все кончилось , бинарников не создалось никаких

 

Естественно. "Type make explicitly" говорит о том что нужно явно запустить make

Но за выхлоп build спасибо, пригодится при анализе

[Shtorm 0]

Все собрал , вечером попробую провернуть операцию

Пока все тихо скачет от 15 до 50 %

 

жду момента ...

[yKpon 8]

обнаружена аналогичная проблема, сборка стг последняя релиз, пробовал через QUEUE и через ACCEPT, разницы никакой. Шкалит не постоянно, временами отпускает

[madf 279]

Я в курсе. Проблема пока не решена.

[rem_lex 2]

когда собирал трафик через cap_ipq тоже наблюдал подобное явления, являлось оно обычно когда чей-то компьютер, зараженный вирусом, начинал извергать лучи поноса спам/сканирования портов/рандомные соединения, вот когда соединений (а точнее полуоткрытых соединений) становилось немереное количество, старгейзер выжирал весь проц

[madf 279]

когда собирал трафик через cap_ipq тоже наблюдал подобное явления, являлось оно обычно когда чей-то компьютер, зараженный вирусом, начинал извергать лучи поноса спам/сканирования портов/рандомные соединения, вот когда соединений (а точнее полуоткрытых соединений) становилось немереное количество, старгейзер выжирал весь проц

Нет, тут проблема в другом. Какой-то цикл внутри зацикливается. Безотносительно модуля захвата трафика.

[Dimension 37]

ничего нового нет по теме ?

[madf 279]

Исправлено. Жди релиза.

[Dimension 37]

Класс, ждем как ману небесную..!

[madf 279]

На самом деле был исправлен немного другой баг с похожим эффектом.

А сегодня наблюдал описанную картинку у себя. Суть в следующем: у юзер сидит вирус, который рассылает лучи поноса кучу пакетов с разным source ip. Все эта каша попадает на NetFlow-сенсор и сливается Stargazer'у широким потоком (6 Мбит чисто NetFlow-трафика!). Stargazer прилежно эту кашу разбирает и пытается классифицировать. По определенным причинам, не смотря на то что этот трафик не приписывается ни одному юзеру, он все равно попадает в дерево пакетов. А т.к. адреса постоянно разные - дерево становится большим. И на его построение Stargazer забирает себе весь проц (ну или одно ядро в многоядерных системах). При этом все потоки работают нормально, кроме traffcounter. Т.е. юзеры остаются авторизованными, конфигуратор тоже нормально коннектится и т.д. Т.е. внешне Stargazer остается полностью работоспособным. Одна беда: жрет проц и не считает трафик (в случае cap_ipq и cap_divert - еще и не пропускает).

В 2.407 (даже, наверное, в rc2 уже попадет) я внесу необходимые изменения которые облегчат его участь в таких ситуациях. А пока рекомендую сразу смотреть tcpdump с ключем -e, ловить mac-адрес и высылать группу захвата к пользователю.

[madf 279]

После фильтрования юзера на свитче Stargazer еще минут 20 (судя по сенсорам мониторинга) обрабатывал всю эту кашу пока не успокоился.