Всем доброго дня!
Не могу разобраться с сложившейся ситуацией, есть utm 5-2-1.007, порядка 25000 абонентов активных с услугой передачи ip трафика и еще 25000 абонентов с услугой абон платой за разные сервисы.
2 раза в месяца ведется архивирование таблиц, скорость работы вполне устраивает.
Из сервисов работают: платежная система, web, rfw. radius работает сторонний и независимо. netflow отдают сервера nas.
НО: после 13 часов дня, когда начинает рости трафик ядро начинает сжирать память и как только переваливает 3гб на процесс utm5_core ядро без ошибок в debug.log падает. и рестартует автоматом. Все бы ничего, но процесс запуска занимает порядка 5 минут, а именно проверка service links, а в этот момент соответственно теряем рабочее время операторов и портим нервы клиентов.
Причем промежуток времени между рестартами прямопорционален нагрзке трафика. к часам 19-20 рестарт происходит раз в 30 минут.
Так же было и на билде 006.
Может быть кто то сталкивался с такой проблемой?!
Падает ядро utm5 при превышении 3гб памяти на процесс
Переполняется память данными Netflow.
У самого так же падает.
Тут либо снижать точность либо не учитывать какой-либо трафик. Например, трафик абонентов на безлимитных тарифах в сыром виде где-то отдельно накапливать (для разборов полетов).
А так - ждем билда 008. Там вроде пишут что провели оптимизацию алгоритма обработки трафика для снижения использования памяти при больших нагрузках.
Вот тут http://www.netup.ru/UTM5/news.php?news=212 пункт 2.
У самого так же падает.
Тут либо снижать точность либо не учитывать какой-либо трафик. Например, трафик абонентов на безлимитных тарифах в сыром виде где-то отдельно накапливать (для разборов полетов).
А так - ждем билда 008. Там вроде пишут что провели оптимизацию алгоритма обработки трафика для снижения использования памяти при больших нагрузках.
Вот тут http://www.netup.ru/UTM5/news.php?news=212 пункт 2.
Re: Падает ядро utm5 при превышении 3гб памяти на процесс
Сталкивались, проблема собственно в том что ядро 32 битное и больше 3 гиг памяти занять не может, как вариант решения уменьшить количество хранимого трафика в памяти в момент аггрегации, например перестать отправлять на биллинг трафик от анлимщиков, или вырезать из трафика бесплатные сети, поигратся с настройками нетфлоу на роутерах, или с настройками аггрегации в биллинге.shtepsel писал(а):Всем доброго дня!
Не могу разобраться с сложившейся ситуацией, есть utm 5-2-1.007, порядка 25000 абонентов активных с услугой передачи ip трафика и еще 25000 абонентов с услугой абон платой за разные сервисы.
2 раза в месяца ведется архивирование таблиц, скорость работы вполне устраивает.
Из сервисов работают: платежная система, web, rfw. radius работает сторонний и независимо. netflow отдают сервера nas.
НО: после 13 часов дня, когда начинает рости трафик ядро начинает сжирать память и как только переваливает 3гб на процесс utm5_core ядро без ошибок в debug.log падает. и рестартует автоматом. Все бы ничего, но процесс запуска занимает порядка 5 минут, а именно проверка service links, а в этот момент соответственно теряем рабочее время операторов и портим нервы клиентов.
Причем промежуток времени между рестартами прямопорционален нагрзке трафика. к часам 19-20 рестарт происходит раз в 30 минут.
Так же было и на билде 006.
Может быть кто то сталкивался с такой проблемой?!
Re: Падает ядро utm5 при превышении 3гб памяти на процесс
Честно говоря тоже пришли к такому умозаключению. Хотим попробовать перенести на 8ю 64бита. Уменьшить кол-во трафика хранимого в момент агрегации не выход если по хорошему. Анлимщики это 90% абонентов, тем более что тариф лимитных уже больше и нетMagnum72 писал(а):Сталкивались, проблема собственно в том что ядро 32 битное и больше 3 гиг памяти занять не может, как вариант решения уменьшить количество хранимого трафика в памяти в момент аггрегации, например перестать отправлять на биллинг трафик от анлимщиков, или вырезать из трафика бесплатные сети, поигратся с настройками нетфлоу на роутерах, или с настройками аггрегации в биллинге.shtepsel писал(а):Всем доброго дня!
Не могу разобраться с сложившейся ситуацией, есть utm 5-2-1.007, порядка 25000 абонентов активных с услугой передачи ip трафика и еще 25000 абонентов с услугой абон платой за разные сервисы.
2 раза в месяца ведется архивирование таблиц, скорость работы вполне устраивает.
Из сервисов работают: платежная система, web, rfw. radius работает сторонний и независимо. netflow отдают сервера nas.
НО: после 13 часов дня, когда начинает рости трафик ядро начинает сжирать память и как только переваливает 3гб на процесс utm5_core ядро без ошибок в debug.log падает. и рестартует автоматом. Все бы ничего, но процесс запуска занимает порядка 5 минут, а именно проверка service links, а в этот момент соответственно теряем рабочее время операторов и портим нервы клиентов.
Причем промежуток времени между рестартами прямопорционален нагрзке трафика. к часам 19-20 рестарт происходит раз в 30 минут.
Так же было и на билде 006.
Может быть кто то сталкивался с такой проблемой?!
Игры с настройками агрегации в биллинги дают результат +-10 минут интервал падения ядра.
А вы не обкатывали 7 билд на 64 битной системе?
Re: Падает ядро utm5 при превышении 3гб памяти на процесс
У меня и стоит на 64 битной федоре 12, проблема в том что ядро биллинг 32 битное, поэтому и получается что у меня на серваке почти все под мускул 64 зарезервированно.shtepsel писал(а):Честно говоря тоже пришли к такому умозаключению. Хотим попробовать перенести на 8ю 64бита. Уменьшить кол-во трафика хранимого в момент агрегации не выход если по хорошему. Анлимщики это 90% абонентов, тем более что тариф лимитных уже больше и нетMagnum72 писал(а):Сталкивались, проблема собственно в том что ядро 32 битное и больше 3 гиг памяти занять не может, как вариант решения уменьшить количество хранимого трафика в памяти в момент аггрегации, например перестать отправлять на биллинг трафик от анлимщиков, или вырезать из трафика бесплатные сети, поигратся с настройками нетфлоу на роутерах, или с настройками аггрегации в биллинге.shtepsel писал(а):Всем доброго дня!
Не могу разобраться с сложившейся ситуацией, есть utm 5-2-1.007, порядка 25000 абонентов активных с услугой передачи ip трафика и еще 25000 абонентов с услугой абон платой за разные сервисы.
2 раза в месяца ведется архивирование таблиц, скорость работы вполне устраивает.
Из сервисов работают: платежная система, web, rfw. radius работает сторонний и независимо. netflow отдают сервера nas.
НО: после 13 часов дня, когда начинает рости трафик ядро начинает сжирать память и как только переваливает 3гб на процесс utm5_core ядро без ошибок в debug.log падает. и рестартует автоматом. Все бы ничего, но процесс запуска занимает порядка 5 минут, а именно проверка service links, а в этот момент соответственно теряем рабочее время операторов и портим нервы клиентов.
Причем промежуток времени между рестартами прямопорционален нагрзке трафика. к часам 19-20 рестарт происходит раз в 30 минут.
Так же было и на билде 006.
Может быть кто то сталкивался с такой проблемой?!
Игры с настройками агрегации в биллинги дают результат +-10 минут интервал падения ядра.
А вы не обкатывали 7 билд на 64 битной системе?
Вот вы мне объясните вам для анлимщиков трафик классифицировать зачем?
По хорошему делается так:
1) Для анлимщиков нетфлоу с интерфейсов брасов не снимается, а для динамического шейпирования можно использовать значения счетчиков, пусть их радиус влупляет в биллинг.
2) Для сорма трафик сливается весь с бордера на другую железку и там уже обрезается, пакуется и складывается своими скриптами. Биллинг то нахрена грузить этой фигней? Да и брасы разгрузите немного.
Re: Падает ядро utm5 при превышении 3гб памяти на процесс
Для анлимщиков трафик необходим только для разгребания запросов от органов. В принципе.Magnum72 писал(а):У меня и стоит на 64 битной федоре 12, проблема в том что ядро биллинг 32 битное, поэтому и получается что у меня на серваке почти все под мускул 64 зарезервированно.shtepsel писал(а):Честно говоря тоже пришли к такому умозаключению. Хотим попробовать перенести на 8ю 64бита. Уменьшить кол-во трафика хранимого в момент агрегации не выход если по хорошему. Анлимщики это 90% абонентов, тем более что тариф лимитных уже больше и нетMagnum72 писал(а):Сталкивались, проблема собственно в том что ядро 32 битное и больше 3 гиг памяти занять не может, как вариант решения уменьшить количество хранимого трафика в памяти в момент аггрегации, например перестать отправлять на биллинг трафик от анлимщиков, или вырезать из трафика бесплатные сети, поигратся с настройками нетфлоу на роутерах, или с настройками аггрегации в биллинге.shtepsel писал(а):Всем доброго дня!
Не могу разобраться с сложившейся ситуацией, есть utm 5-2-1.007, порядка 25000 абонентов активных с услугой передачи ip трафика и еще 25000 абонентов с услугой абон платой за разные сервисы.
2 раза в месяца ведется архивирование таблиц, скорость работы вполне устраивает.
Из сервисов работают: платежная система, web, rfw. radius работает сторонний и независимо. netflow отдают сервера nas.
НО: после 13 часов дня, когда начинает рости трафик ядро начинает сжирать память и как только переваливает 3гб на процесс utm5_core ядро без ошибок в debug.log падает. и рестартует автоматом. Все бы ничего, но процесс запуска занимает порядка 5 минут, а именно проверка service links, а в этот момент соответственно теряем рабочее время операторов и портим нервы клиентов.
Причем промежуток времени между рестартами прямопорционален нагрзке трафика. к часам 19-20 рестарт происходит раз в 30 минут.
Так же было и на билде 006.
Может быть кто то сталкивался с такой проблемой?!
Игры с настройками агрегации в биллинги дают результат +-10 минут интервал падения ядра.
А вы не обкатывали 7 билд на 64 битной системе?
Вот вы мне объясните вам для анлимщиков трафик классифицировать зачем?
По хорошему делается так:
1) Для анлимщиков нетфлоу с интерфейсов брасов не снимается, а для динамического шейпирования можно использовать значения счетчиков, пусть их радиус влупляет в биллинг.
2) Для сорма трафик сливается весь с бордера на другую железку и там уже обрезается, пакуется и складывается своими скриптами. Биллинг то нахрена грузить этой фигней? Да и брасы разгрузите немного.
Мысль конечно увести трафик верная, спору нет. А объемы трафика вы передаете радиусом?
Полностью согласен что ядро должно летать в таком случае. Но тут вижу только неудобство в обработке трафика при запросе на какого нибудь абонента или адресацию.
Re: Падает ядро utm5 при превышении 3гб памяти на процесс
Объемы мы пока вообще никак не передаем, мы динамическим шейпингом переболели года два назад, счас просто незачем, ну разве абонентам друг перед другом хвалиться.shtepsel писал(а): Для анлимщиков трафик необходим только для разгребания запросов от органов. В принципе.
Мысль конечно увести трафик верная, спору нет. А объемы трафика вы передаете радиусом?
Полностью согласен что ядро должно летать в таком случае. Но тут вижу только неудобство в обработке трафика при запросе на какого нибудь абонента или адресацию.
Ну сколько таких запросов 1-2 в месяц, если раскладывать трафик по часам по выборка по IP за определенный промежуток времени не так много времени занимает, тем более сегда можно уточнить временные границы под предлогом оперативности выдачи ответа.
-
Chistiakov_A
- NetUP Team
- Сообщения: 190
- Зарегистрирован: Пн мар 21, 2005 18:30
Мы не делаем 64х-битных сборок проекта UTM5, так как для адекватной его работы придется переписать полсистемы. UTM6 собирается только в 64х битном исполнении. Мы не считаем 64х сырым, это ложное предположение.amix писал(а):Насколько я знаю нетап не делает сборок для 64 битных систем, видимо считают что 64битные архитектуры "сырые" и в продакшене их никто не использует.
-
Chistiakov_A
- NetUP Team
- Сообщения: 190
- Зарегистрирован: Пн мар 21, 2005 18:30
Не стоит драматизировать. О прекращении поддержки UTM5 речи не идет. Если вдруг 32х-битные приложения перестанут работать на современных серверах, тогда это станет вопросом поддержки, а пока это вопрос развития системы.Vans писал(а):Т.е. грубо говоря вы не предполагаете в дальнейшем поддержку 5 версии и предлагаете доплатить 20 килобаксов за 6 версию, а на всех, кто работает с вами начиная со 2 версии Вам наплевать?