Новый биллинг 5.3 протекает и выпадает в осадок

[Infected]

Уважаемые господа, так как у нас закончилась платная поддержка и, соответственно, хотлайн, спешу сообщить вам отличные новости на форуме.

После обновления на UTM 5.3-001-u3 (с 5.2-009) имеем проблемы с самопроизвольным перезапуском ядра, в логах debug.log при этом никаких сообщений об аварии нет:

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

Dec 11 11:33:24 ?Debug : b3ffdb90 StreamConnection: Got message ID 0x1107
Dec 11 11:33:24 ?Debug : b3ffdb90 DBConnectionPool: DBConnectioManager pool [Default]: connection is popped
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnection_mysql&#58; <0x8c7a460> SQL query&#58; UPDATE dhs_sessions_log SET  account_id='479', flags='0', slink_id='70121', last_update_date='1386747204', Acct_Status_Type='3', A
cct_Input_Packets ='667462', Acct_Input_Octets ='83539371', Acct_Input_Gigawords ='0', Acct_Output_Packets ='981176', Acct_Output_Octets ='1176056899', Acct_Output_Gigawords ='0', Acct_Terminate_Cause='0', A
cct_Session_Time ='23608' WHERE id='8747221'
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnection_mysql&#58; <0x8c7a460> SQL query takes 0 sec
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnectionPool&#58; DBConnectionManager pool &#91;Default&#93;&#58; connection is pushed back
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 StreamConnection&#58; Got message ID 0x1107
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnectionPool&#58; DBConnectioManager pool &#91;Default&#93;&#58; connection is popped
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnection_mysql&#58; <0x8c8d6c0> SQL query&#58; UPDATE dhs_sessions_log SET  account_id='1507', flags='0', slink_id='59122', last_update_date='1386747204', Acct_Status_Type='3', 
Acct_Input_Packets ='42749', Acct_Input_Octets ='4111613', Acct_Input_Gigawords ='0', Acct_Output_Packets ='34231', Acct_Output_Octets ='2511354', Acct_Output_Gigawords ='0', Acct_Terminate_Cause='0', Acct_S
ession_Time ='23609' WHERE id='8746943'
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnection_mysql&#58; <0x8c8d6c0> SQL query takes 0 sec
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnectionPool&#58; DBConnectionManager pool &#91;Default&#93;&#58; connection is pushed back
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 StreamConnection&#58; Got message ID 0x1107
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnectionPool&#58; DBConnectioManager pool &#91;Default&#93;&#58; connection is popped
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnection_mysql&#58; <0x8c93b00> SQL query&#58; UPDATE dhs_sessions_log SET  account_id='1967', flags='0', slink_id='75026', last_update_date='1386747204', Acct_Status_Type='3', 
Acct_Input_Packets ='155673', Acct_Input_Octets ='17678780', Acct_Input_Gigawords ='0', Acct_Output_Packets ='353073', Acct_Output_Octets ='420744833', Acct_Output_Gigawords ='0', Acct_Terminate_Cause='0', A
cct_Session_Time ='23608' WHERE id='8746958'
Dec 11 11&#58;33&#58;24 ?Debug &#58; b51f7b90 TransactionHandlerImpl&#58; push&#58; empty transaction ptr &#91;8a1d2480&#93; dropped
Dec 11 11&#58;33&#58;24 ?Debug &#58; b51f7b90 DummyTransactionQueue&#58; commit&#58; 0 transactions
Dec 11 11&#58;33&#58;24 ?Debug &#58; b51f7b90 DBConnectionPool&#58; DBConnectionManager pool &#91;Default&#93;&#58; connection is pushed back
Dec 11 11&#58;33&#58;24 ?Debug &#58; b51f7b90 TransactionHandlerImpl&#58; incoming transaction ptr &#91;8a1d1ec8&#93; is done
Dec 11 11&#58;33&#58;24 ?Debug &#58; b51f7b90 DummyTransactionQueue&#58; rollback&#58; 0 transactions
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnection_mysql&#58; <0x8c93b00> SQL query takes 0 sec
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 DBConnectionPool&#58; DBConnectionManager pool &#91;Default&#93;&#58; connection is pushed back
Dec 11 11&#58;33&#58;24 ?Debug &#58; b3ffdb90 StreamConnection&#58; Got message ID 0x1107

тут мы получаем "utm5_core process exited ... Check it" и следующая строка

Dec 11 11&#58;33&#58;55  Info  &#58; b7f6a900 FileAppender&#58; Using '/netup/utm5/log/debug.log' file
Dec 11 11&#58;33&#58;55  Info  &#58; b7f6a900 FileAppender&#58; Using '/netup/utm5/log/main.log' file
Dec 11 11&#58;33&#58;55 ?Debug &#58; b7f6a900 DBConnection_mysql&#58; Connecting to MySQL database
Dec 11 11&#58;33&#58;55 ?Debug &#58; b7f6a900 DBConnection_mysql&#58; Connection parameters username&#58; root; dbname&#58; UTM5 host&#58; localhost
Dec 11 11&#58;33&#58;55 ?Debug &#58; b7f6a900 DBConnection_mysql&#58; Setting database character set to <utf8>
Dec 11 11&#58;33&#58;55 ?Debug &#58; b7f6a900 DBConnection_mysql&#58; MySQL connection opened
Dec 11 11&#58;33&#58;55 ?Debug &#58; b7f6a900 DBConnectionPool&#58; DBConnectionManager pool &#91;Default&#93;&#58; connection is pushed back&#91;/color&#93;

Ядро даже не говорит "давай до свидания", просто уходит по-английски. Если же utm5_core не может выпасть, то начинает есть память с аппетитом примерно 150-200 Мб/сутки. Когда кончается свободная память перестает запускаться админка

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

Dec 02 15:55:19  ERROR : b59fbb90 RPCServer: Unable to create thread: Cannot allocate memory
Dec 02 15:55:20  ERROR : b59fbb90 RPCServer: Unable to create thread: Cannot allocate memory
Dec 02 15:55:42  ERROR : b59fbb90 RPCServer: Unable to create thread: Cannot allocate memory
Dec 02 15:56:05  ERROR : b59fbb90 RPCServer: Unable to create thread: Cannot allocate memory
Dec 02 15:56:06  ERROR : b4bf6b90 RfwPlugin: process_session: slink_id==0
Dec 02 15:56:10  ERROR : b59fbb90 RPCServer: Unable to create thread: Cannot allocate memory
Dec 02 15:57:00  ERROR : b4bf6b90 RfwPlugin: process_session: slink_id==0
Dec 02 15:57:44  ERROR : b4bf6b90 RfwPlugin: process_session: slink_id==0
Dec 02 15:58:00  ERROR : b4bf6b90 RfwPlugin: process_session: slink_id==0
Dec 02 15:58:19  ERROR : b4bf6b90 RfwPlugin: process_session: slink_id==0
Dec 02 15:58:49  ERROR : b59fbb90 RPCServer: Unable to create thread: Cannot allocate memory

и что самое неприятное, часть RADIUS-запросов остается без ответа со стороны биллинга со всеми вытекающими последствиями.

Сервер под управлением CentOS 5.7, 2.6.18-274.17.1.el5PAE, 8Гб ОЗУ. Работало стабильно с 5.2 без всяких нареканий.

Ждем скорейшего выхода обновления, которое конечно же не за горами.

[serjk]

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

По поводу падений - вы не указываете каких-либо данных, по какой причине завершается ядро, а причины всегда есть, например:

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

- segmentation fault (об этом будет сообщение в dmesg, можно так же получить core файл и отправить его нам для анализа, и получить поддержку, даже если платная закончилась)

[Infected]

serjk, подскажите как правильно запустить utm5_core, чтобы появился при падении core-файл, т.к. сейчас такой файл не появляется.

и еще, сегодня пятница, скажите является ли этот день "концом недели" или апдейт ждать в воскресенье?

[serjk]

serjk, подскажите как правильно запустить utm5_core, чтобы появился при падении core-файл, т.к. сейчас такой файл не появляется.

и еще, сегодня пятница, скажите является ли этот день "концом недели" или апдейт ждать в воскресенье?

Чтобы генерировались core файлы, можно поправить скрипт /netup/utm5/bin/safe_utm5_core

Строка 48,

$exec_dir/$utm_exec

заменить на

(ulimit -c unlimited; $exec_dir/$utm_exec)

Файлы будут генерироваться в корне файловой системы.

Похоже обновление только к вечеру начнем делать, так что если проблема не терпит, напишите мне на мейл (мой ник в домене netup.ru), и сообщите, под какую платформу необходим фикс.