Виснет 008_UPD2

Технические вопросы по UTM 5.0
Kristian
Сообщения: 95
Зарегистрирован: Ср мар 04, 2009 21:32

Виснет 008_UPD2

Сообщение Kristian »

Доброе утро.

Обновил биллинг до 008_UPD2.
Система FreeBsd 6.2-RELEASE-p12

Сегодня утром обнаружил, что к нему невозможно подключится админкой (отваливается по таймауту)

debug.log (чистый, но строка Got DynaShapePlugin plugin for event EventProcessShaping/95 повторяется. Никаких ошибок):

Код: Выделить всё

?Debug : Dec 20 09:05:01 090a0400 PluginManagerImpl: Got DynaShapePlugin plugin for event EventProcessShaping/95
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 DBCtx&#58; <140963840> SQL query&#58; UPDATE downloaded SET qnt='1983440176', discounted='0', downed_as_prepaid='0' WHERE download
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 DTAgg&#58; update dtagg_iptraffic for slink_id 1762
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 DBCtx&#58; <140963840> SQL query&#58; UPDATE dtagg_iptraffic SET discounted='0.000000', discounted_without_tax='0.000000', bytes='
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 UTM5 DBA&#58; Charge&#58;0.000000 p.u. for link&#58;1762 account 589
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 DBCtx&#58; <140963840> SQL query&#58; UPDATE accounts SET balance='-1.113' WHERE id = '589'
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 DBCtx&#58; <140963840> SQL query&#58; INSERT INTO discount_transactions_all&#40;account_id,incoming_rest,outgoing_rest,discount,discou
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 UTM5 DBA&#58; Checking for rehash&#58; flags 3, balance -1.113 &#40;old -1.113&#41;, credit 50.000
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 BusLogic&#58; currently blm with code 37 executing
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 BusLogic&#58; BLM&#40;37&#41; pushed &#40;comment&#58; ruh block&#41;
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 DBCtx&#58; <140963840> SQL query&#58; INSERT INTO discount_transactions_iptraffic_all&#40;id,account_id,discount,discount_with_tax,ser
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 DBCtx&#58; <140963840> SQL query&#58; COMMIT
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 DBCtx&#58; DB transaction commit
?Debug &#58; Dec 20 09&#58;05&#58;01 0915fc00 DBA&#58;Ctx&#58; Pushing back free context &#40;system=1&#41;
-Stats &#58; Dec 20 09&#58;05&#58;01 0915fc00 UTM5 DBA&#58;     Stats&#58; Uptime&#58; 00&#58;00&#58;00. Events&#58; 0; Errors&#58; 0
?Debug &#58; Dec 20 09&#58;05&#58;01 090a0400 DBCtx&#58; <140965888> SQL query&#58; COMMIT
?Debug &#58; Dec 20 09&#58;05&#58;01 090fc000 BusLogic&#58; finished unknown
?Debug &#58; Dec 20 09&#58;05&#58;01 090fc000 BusLogic&#58; try to execute 37
?Debug &#58; Dec 20 09&#58;05&#58;01 090fc000 BusLogic&#58; hw_block_handler with code 37
?Debug &#58; Dec 20 09&#58;05&#58;01 090a0400 DBCtx&#58; DB transaction commit
?Debug &#58; Dec 20 09&#58;05&#58;01 090fc000 BusLogic&#58; finished unknown
?Debug &#58; Dec 20 09&#58;05&#58;01 090a0400 TransactionFilter&#58; transaction sent to the internal queue
?Debug &#58; Dec 20 09&#58;05&#58;01 090a0400 TransactionQueueManager&#58; pushing transaction <0x9131b80> into queue <2> &#40;default&#41;
?Debug &#58; Dec 20 09&#58;05&#58;01 090a0400 TransactionHandlerImpl&#58; push&#58; empty transaction ptr <0x09131b80> dropped
?Debug &#58; Dec 20 09&#58;05&#58;01 090a0400 DummyTransactionQueue&#58; commit&#58; 0 transactions
?Debug &#58; Dec 20 09&#58;05&#58;01 090a0400 DBA&#58;Ctx&#58; Pushing back free context &#40;system=1&#41;
?Debug &#58; Dec 20 09&#58;05&#58;01 090a0400 TransactionHandlerImpl&#58; incoming transaction ptr <0x09131d80> done
?Debug &#58; Dec 20 09&#58;05&#58;02 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; timestamp 1292828702 slink_id 1645
?Debug &#58; Dec 20 09&#58;05&#58;02 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; slink_id 1645 tclass_id 30
?Debug &#58; Dec 20 09&#58;05&#58;02 0915fe00 TrafficAggregator&#58; push_charge&#58; slink_id 1645 charge 0.000000
?Debug &#58; Dec 20 09&#58;05&#58;02 0915fc00 UTM5 DBA&#58; DBAccess instance created
?Debug &#58; Dec 20 09&#58;05&#58;02 0915fc00 DBA&#58;Ctx&#58; Looking for free context &#40;system=1&#41;
main.log (за это время нет вообще сообщений, последние привожу):

Код: Выделить всё

 Info  &#58; Dec 20 05&#58;03&#58;37 090a0200 RfwPlugin&#58; final command&#58; &#91;shapebez 686 10.0.18.76 32 255.255.255.255 404&#93;
 Info  &#58; Dec 20 05&#58;03&#58;37 090a0200 RfwPlugin&#58; final command&#58; &#91;shapebez 1297 10.0.34.70 32 255.255.255.255 410&#93;
 Info  &#58; Dec 20 05&#58;03&#58;37 090a0200 RfwPlugin&#58; final command&#58; &#91;shapebez 1490 10.0.26.100 32 255.255.255.255 410&#93;
 Info  &#58; Dec 20 05&#58;03&#58;41 09156e00 StreamConnection&#58; Connection thread started. Peer 172.16.1.2&#58;49135
 Info  &#58; Dec 20 05&#58;03&#58;41 09156e00 StreamConnection&#58; Authorized user <init> from <172.16.1.2>
 Info  &#58; Dec 20 05&#58;03&#58;41 09156e00 StreamRfw&#58; Firewall with name <172.16.1.2> is alive, dropping new connection
 Info  &#58; Dec 20 05&#58;03&#58;46 09156e00 StreamConnection&#58; Connection from 172.16.1.2&#58;49135 closed
Вопрос. возможно у меня исчерпывается лимит на RPC подключения ?

Если кто знает, подскажите рекомендуемые значения SYSCTL параметров для сервера на котором крутится ядро и база с UTM5.

были бы ошибки в логах, было бы проще .... а так ... даже не понимаю куда копать.

Pulse
Сообщения: 945
Зарегистрирован: Вт окт 03, 2006 12:58

Сообщение Pulse »

wintray используете? у меня такое было в логах Unable create thread. Увеличивал
kern.threads.max_threads_per_proc:
kern.threads.max_groups_per_proc:

но кажется не сильно помогает, потому что теперь у меня почему-то в мускуле Too many conections. Делаю вывод, что достигнут предел железа. Надо разносить мускул и ядро.

Kristian
Сообщения: 95
Зарегистрирован: Ср мар 04, 2009 21:32

Сообщение Kristian »

У меня в логах таких записей нет.
Думаете все равно стоит увеличить значение этих параметров ?

Kristian
Сообщения: 95
Зарегистрирован: Ср мар 04, 2009 21:32

Сообщение Kristian »

Прописал

Код: Выделить всё

kern.threads.max_threads_per_proc=6000
kern.threads.max_groups_per_proc=6000

Надеюсь поможет.

Может у кого то еще какие мысли будут.
Интересно, что в этот момент (когда подвисло ядро) у меня как раз передергивался RFW на удаленном NASe.

После передергивания лог main.log перестал писаться и насколько я понимаю пропала возможность подключится через админку либо винтрей.
В то же время debug продолжал писаться и в нем есть строки

Код: Выделить всё

FW@172.16.1.2&#58; ping reply received
Типа с РФВ ядро работать продолжает.....
мистика какая то ...

kirush
Сообщения: 699
Зарегистрирован: Пт фев 04, 2005 13:58

Сообщение kirush »

Посмотрите не связаны ли подвисания с закрытием расчетного периода?

Kristian
Сообщения: 95
Зарегистрирован: Ср мар 04, 2009 21:32

Сообщение Kristian »

Посмотрел, те расчетные периоды, что есть в базе начинаются в 00:00 и заканчиваются в 00:00 часов.

А ядро подвисло в 5 утра.
Возможно я не там смотрю ?
В логах в это время правда есть кое что интересное на мой взгляд. Что бы оно значило ?

Код: Выделить всё

?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; timestamp 1292814786 slink_id 4186
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; slink_id 4186 tclass_id 10
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; push_charge&#58; slink_id 4186 charge 0.000000
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; timestamp 1292814786 slink_id 3045
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; slink_id 3045 tclass_id 10
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; push_charge&#58; slink_id 3045 charge 0.000000
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; timestamp 1292814786 slink_id 3045
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; slink_id 3045 tclass_id 20
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; push_charge&#58; slink_id 3045 charge 0.000000
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; timestamp 1292814786 slink_id 4545
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; slink_id 4545 tclass_id 20
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; push_charge&#58; slink_id 4545 charge 0.000000
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; timestamp 1292814786 slink_id 1516
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; slink_id 1516 tclass_id 20
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; push_charge&#58; slink_id 1516 charge 0.000000
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; timestamp 1292814786 slink_id 2106
?Debug &#58; Dec 20 05&#58;13&#58;06 0915fe00 TrafficAggregator&#58; charge_on_timeout&#58; slink_id 2106 tclass_id 10

kirush
Сообщения: 699
Зарегистрирован: Пт фев 04, 2005 13:58

Сообщение kirush »

Была похожая проблема с 008, но там после долгих разборов с сотрудниками Нетапа, была обнаружена проблема в ядре (FreeBSD на тот момент стояла 7.0, с последующим обновлением до 7.3 по их просьбе) УТМа, официально это звучало так:
Суть проблемы заключалась во взаимной блокировке двух потоков внутри ядра UTM5, которая возникала на ОС FreeBSD при закрытии расчетного периода. При этом происходила и блокировка на чтение кэша ядра UTM5. На других платформах такой проблемы не возникало по причине другого принципа работы системного планировщика.
Проблема была успешно ими решена. За что им огромное спасибо, в частности Алексею Буткееву, который занимался решением проблемы.
Несколько дней назад обновился на 9ую версию и наблюдаю тоже самое, пока не совсем понял связано ли это опять с расчетными периодами или нет. Сегодня оформил bugfix, подождем анализа логов и комментариев разработчиков.

Kristian
Сообщения: 95
Зарегистрирован: Ср мар 04, 2009 21:32

Сообщение Kristian »

Хм .... так что ? переползать на 8-ю FreeBsd ? И возможно перестанет виснуть ?

To All ... Может у кого то 8upd2 на FreeBsd работает стабильно ? Скажите какая версия OS.

Pulse
Сообщения: 945
Зарегистрирован: Вт окт 03, 2006 12:58

Сообщение Pulse »

они просто фряшечку не оч любят :) быстрей скажут переходить на линукс, чем обновляться до 8ой.
Кстати, у меня теперь тоже виснет, тока доказать никак не могу, в логах чисто. Просто перестаёт конекты создавать, в процессах висит несколько utm5_urfaclient и utm5_payment_tool, у некоторых админка работает, у некоторых уже не работает, с винтреем тоже самое.
в sockstat | grep 11758 | wc -l совсем не много пишет, около 300.
Щас в хотлайн попробую написать. BSD 6 ваще стоит

Kristian
Сообщения: 95
Зарегистрирован: Ср мар 04, 2009 21:32

Сообщение Kristian »

С одной стороны чувствую себя идиотом, что перенес 8хupd2 на продакшн ..... С другой стороны на сайте это уже релиз. Который рекомендован к использованию.....

АУ НЕТАП. Может дадите рекомендации владельцам cего чуда на FREEBSD ?

Аватара пользователя
Lex
NetUP Team
Сообщения: 623
Зарегистрирован: Ср мар 09, 2005 12:12
Откуда: НетАП
Контактная информация:

Сообщение Lex »

Багрепорт оформляли? Если да, укажите номер заявки.
Если нет, то нужно оформить.
Проблем, приводящих к подобным последствиям, в настоящий момент не зарегистрировано, насколько я знаю.
Описывать подобные проблемы на форуме и ждать исправления бессмысленно.

Pulse
Сообщения: 945
Зарегистрирован: Вт окт 03, 2006 12:58

Сообщение Pulse »

в хотлайне тикет 2010122110000089 жду какие данные нужны...

Аватара пользователя
Lex
NetUP Team
Сообщения: 623
Зарегистрирован: Ср мар 09, 2005 12:12
Откуда: НетАП
Контактная информация:

Сообщение Lex »

Pulse писал(а):в хотлайне тикет 2010122110000089 жду какие данные нужны...
Данные, которые требуются для первоначальной диагностики, запрошены.

Kristian
Сообщения: 95
Зарегистрирован: Ср мар 04, 2009 21:32

Сообщение Kristian »

UP ......

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

kirush
Сообщения: 699
Зарегистрирован: Пт фев 04, 2005 13:58

Сообщение kirush »

откатился с 009u1 на 008u2 проблема с зависаниями пока не потворялась.
uptime 3 дня 14 часов.
Но близится вот другое "страшненькое", в конце месяца стабильно при закрытии расчетных периодов, ядро впадает в core и заново рестартится - посмотрим, что выдаст на этот раз.

Ответить