Вышло обновление 5-2.1.007 update 4. Changelog отсутствует.

dwemer · Сообщение **dwemer** » Пт ноя 06, 2009 07:16

после обновления до update4 ядро очень долго запускается. В дебаг в это время пишет это:

?Debug &#58; Nov 06 11&#58;56&#58;12 DBCtx&#58; <140260352> SQL SELECT query&#58; SELECT id FROM blocks_info WHERE account_id='1619' AND start_date<='1257479772' AND expire_date>='1257479772' AND is_deleted='0'
?Debug &#58; Nov 06 11&#58;56&#58;13 DBCtx&#58; <140260352> SQL SELECT query&#58; SELECT id FROM blocks_info WHERE account_id='1620' AND start_date<='1257479773' AND expire_date>='1257479773' AND is_deleted='0'
?Debug &#58; Nov 06 11&#58;56&#58;13 DBCtx&#58; <140260352> SQL SELECT query&#58; SELECT id FROM blocks_info WHERE account_id='1621' AND start_date<='1257479773' AND expire_date>='1257479773' AND is_deleted='0'
?Debug &#58; Nov 06 11&#58;56&#58;14 DBCtx&#58; <140260352> SQL SELECT query&#58; SELECT id FROM blocks_info WHERE account_id='1622' AND start_date<='1257479774' AND expire_date>='1257479774' AND is_deleted='0'

С мускулем все в порядке , предыдущие версии ядра запускаются быстро. Непонятно, почему так долго происходит выборка из blocks_info ?
В итоге за 5 минут выбрало только 10% , пришлось убить и вернуться на старую версию.

зы: индексы на месте и соответствуют последнему апдейту

maxxxx · Сообщение **maxxxx** » Пт ноя 06, 2009 07:52

присоединяюсь, предыдущие сборки быстро запускались, update 4 у нас запускается ~ 1-2 минуту, более быстрая загрузка возможно обусловлено малым числом абонентов.

Magnum72

maxxxx писал(а):присоединяюсь, предыдущие сборки быстро запускались, update 4 у нас запускается ~ 1-2 минуту, более быстрая загрузка возможно обусловлено малым числом абонентов.

Я задаваол вопрос разрабам, обещали в 008 серьезно подумать над ускорением запуска, у меня счас минут 15 стартует

detx · Сообщение **detx** » Пт ноя 06, 2009 21:34

Как сказал Lex

Суть я понял. Открытый багртрэкинг и TODO-list. Сделаем как подготовим технические средства.

вот в этом топике
viewtopic.php?t=7254
Наверное просто занимаются этими вопросами, до чайнджлога нету времени.)))
Взять любой опенсорс продукт, там все это присутствует. от простого текстого редактора(vi), файлового менеджера(mc), системы мониторинга (cacti)........., если только нет у челобрека, который наваял скрипт на сотню строчек, и просто туда добавляет что-то новое, а что новое, можно просто открыть посмотреть и все станет ясно.
Хотя зачем сравнивать, то открытый продукт, а то закрытый.

Vans · Сообщение **Vans** » Сб янв 02, 2010 01:28

Скачал сегодня update8 под Gentoo и поставил на новый сервер. Увидел, что этот глюк так и не пофиксили! Архивировались тоже только те же две таблицы как и в начале темы.
А решение похоже простое на 2 минуты. Вот лог:

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

?Debug &#58; Jan 02 01&#58;07&#58;14 RPCConn&#91;SSL&#93;<init@10.172.20.195>&#58; Call&#58; 0x3003 &#40;rpcf_payments_report&#41;
?Debug &#58; Jan 02 01&#58;07&#58;14 RPCConn&#91;SSL&#93;<init@10.172.20.195>&#58; Real Call&#58; 0x3003 &#40;rpcf_payments_report&#41;
?Debug &#58; Jan 02 01&#58;07&#58;14 UTM5 DBA&#58; DBAccess instance created
?Debug &#58; Jan 02 01&#58;07&#58;14 DBA&#58;Ctx&#58; Looking for free context &#40;system=0&#41;
?Debug &#58; Jan 02 01&#58;07&#58;14 DBCtx&#58; <141139272> SQL SELECT query&#58; SELECT archive_id,start_date,end_date FROM archives ORDER BY id
?Debug &#58; Jan 02 01&#58;07&#58;14 UTM5 DBA&#58; archive ID <9> case&#58; start >= per_start && start <= per_end && end >= per_end
?Debug &#58; Jan 02 01&#58;07&#58;14 UTM5 DBA&#58; start&#40;1259614800&#41; < r&#40;1262293199&#41; < end&#40;1262293200&#41;, adding non-archive table into report
?Debug &#58; Jan 02 01&#58;07&#58;14 DBCtx&#58; <141139272> SQL SELECT query&#58; SELECT table_name FROM archives WHERE archive_id='9' AND table_type='7'
?Debug &#58; Jan 02 01&#58;07&#58;14 UTM5 DBA&#58; table payment_transactions not exists in archive_id 9
 ERROR &#58; Jan 02 01&#58;07&#58;14 DBAStringError&#58; table not exists in this archive
?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; Obtained 10 stack frames.
?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /netup/utm5/bin/utm5_core&#40;_Z15print_backtracev+0x23&#41; &#91;0x842ac33&#93;

?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /netup/utm5/bin/utm5_core&#40;_ZN3UTM8DBAErrorC2ERKSsS2_b+0x89&#41; &#91;0x8208409&#93;

?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /netup/utm5/bin/utm5_core&#40;_ZN3UTM14DBAStringErrorC1ESs+0x4e&#41; &#91;0x827a9fe&#93;

?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /netup/utm5/bin/utm5_core&#40;_ZN3UTM8DBAccess22get_archive_table_nameEiNS_15archive_table_tERSs+0x21d&#41; &#91;0x827308d&#93;

?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /netup/utm5/bin/utm5_core&#40;_ZN3UTM8DBAccess24reports_account_paymentsEiilliPNS_21AccountPaymentsReportE+0x16d&#41; &#91;0x827a09d&#93;

?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /netup/utm5/lib/utm5_core/liburfa-reports.so&#40;_Z20rpcf_payments_reportPv+0x654&#41; &#91;0xf39edec4&#93;

?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /netup/utm5/bin/utm5_core&#40;_ZN3UTM7RPCConn7processEv+0x6c2&#41; &#91;0x83baf22&#93;

?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /netup/utm5/bin/utm5_core&#40;_ZN3UTM17__rpcconn_wrapperEPv+0x141&#41; &#91;0x83b0bb1&#93;

?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /lib32/libpthread.so.0 &#91;0xf75d813f&#93;

?Trace &#58; Jan 02 01&#58;07&#58;14 trace&#58; /lib32/libc.so.6&#40;clone+0x5e&#41; &#91;0xf7428cfe&#93;

?Debug &#58; Jan 02 01&#58;07&#58;14 DBCtx&#58; <141139272> SQL SELECT query&#58; SELECT id, payment_incurrency, currency_id, currency_rate, payment_absolute,actual_date, payment_enter_date, method
, who_receive, comments_for_user, comments_for_admins, account_id, payment_ext_number, burn_time FROM payment_transactions WHERE payment_enter_date>='1262293199' AND payment_ent
er_date<='1262293200' ORDER BY payment_enter_date DESC
?Debug &#58; Jan 02 01&#58;07&#58;14 DBA&#58;Ctx&#58; Pushing back free context &#40;system=0&#41;
-Stats &#58; Jan 02 01&#58;07&#58;14 UTM5 DBA&#58;      Stats&#58; Uptime&#58; 00&#58;00&#58;00. Events&#58; 0; Errors&#58; 0
?Debug &#58; Jan 02 01&#58;07&#58;14 RPCConn&#91;SSL&#93;<init@10.172.20.195>&#58; Call 0x3003 &#40;rpcf_payments_report&#41; finished...

Вот в этом запросе:

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

?Debug &#58; Jan 02 01&#58;07&#58;14 DBCtx&#58; <141139272> SQL SELECT query&#58; SELECT archive_id,start_date,end_date FROM archives ORDER BY id

нужно добавить:

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

WHERE table_type='7'

чтобы биллинг не пытался искать архив платежей, если они и не архивировались.

Ну как-то так...

Или зачем тогда в лог вываливать

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

ERROR &#58; Jan 02 01&#58;07&#58;14 DBAStringError&#58; table not exists in this archive

Ведь если ее там нет это может быть и не ошибка? И сделать так чтоб ничего не "рушилось" при таком раскладе.

Система

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

Linux billing 2.6.31-gentoo-r6 #5 SMP Wed Dec 30 17&#58;34&#58;37 MSK 2009 x86_64 Intel&#40;R&#41; Xeon&#40;R&#41; CPU E5520 @ 2.27GHz GenuineIntel GNU/Linux

alexus · Сообщение **alexus** » Сб янв 02, 2010 01:42

Работа тех поддержки как всегдана высоте, в ведь 007 версию за деньги люди приобретают!!