UTM 5.2.1–007

[Martin]

А вы уверенны что в тетрисе багов нет? Я вот уверен, что они там есть, надо просто поискать.

А в ютме даже искать не надо - они сами вылезают.

По поводу стабильности - над этим ведется работа и она приносит результат. Могу сказать, что сборка, например, 5.2.1-006 на порядок стабильней, чем, к примеру, 5.2.1-005.

а для меня 5.2.1-006 хуже 5.2.1-005. и если бы не ваша дурная политика с ключами, то я бы до сих пор сидел бы на 5-ке

Это сразу видно и по сообщениям на форуме, и по обращениям в службу техподдержки, и по общему впечатлению от общения с клиентами по телефону.

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

[dwemer]

Я уточнил по данным вопросам:
1. Как говорят мне специалисты, скорее всего проблема в нарушении логической целостности БД. Копию базы данных для анализа Вы предоставить отказались, а она необходима.
2. На стенде проблема не воспроизводится, копия базы данных, необходимая для диагностики отсутствует.
3. Должно быть исправлено в последней сборке интерфейса.
4. По поводу падений - падать не должно. Если падает, пишите багрепорт, описывайте в каких случаях падает и присылайте лог-файлы и аварийный дамп памяти процесса.

Я лучше останусь на RC1, но базу раздавать налево направо не буду.
(Соглашение о конфиденциальности запрашивал , не ответили. Уже не надо. )

С RC1 эти проблемы отсутствуют. Это говорит о чем ? О том что проблема скорее всего в последующих сборках, а не в моей базе.

Единственное что сподвигло на попытку с rc1 обновиться дальше - то что он постоянно срет в лог файл. Но с этим можно жить.

[Wishmaster]

Уважаемый Алексей (Lex), уточните пожалуйста одну деталь...

В RC2 было заявлено следующее:

Расширены возможности архивирования крупных таблиц БД. Обновленный список типов архивных таблиц (поле table_type в таблице archives):
discount_transactions_all тип 1,
discount_transactions_iptraffic_all тип 2,
tel_sessions_log тип 3,
tel_sessions_detail тип 4,
dhs_sessions_log тип 5,
dhs_sessions_detail тип 6,
payment_transactions тип 7

В связи с этим вопрос, а таблица

dhs_access_log

по каким причинам не попала в данную схему архивации? Или, если попала, то какой у нее будет тип?

Спасибо!

[Magnum72]

Только у меня при редактировании доп параметров пользователя админка вешается?

[NShut]

я 12го переведу рабочую базу на 007, буду тестером. Переход связан с избавлением от старых некоторых глюков. Согласен что могут и появиться новые, но 007 версию поддерживают думаю лучше шестерки, если от её поддержки вообще не отказались

В защиту авторов: глюки есть всегда и везде. Возьмите любую игру, любой софт. Даже в блокноте если помните есть два бага. Сам как программист знаю, что оттестить программу можно только в массах. На стенде даже у машин двигателя толком проверить не могут.
Ну и к тому же. люди, вы хоть один другой биллинг пробовали?
К тому же сложность базы выявляет другие глюки. Т.е. падение электричества, отказ винта, даже скази в рэйде изредка появляются надписи то синхронизэйшен файлед то еще что, а как думаете что происходит когда mysql пытается записать на диск и думает что ему удалось? не говоря уже про коредампед. хотя тьфу тьфу у меня их давно не было.

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

[serjk]

Только у меня при редактировании доп параметров пользователя админка вешается?

При редактировании доп параметра в Настройках или в Свойствах пользователя? Пока не удалось воспроизвести.

[Lex]

Уважаемый Алексей (Lex), уточните пожалуйста одну деталь...
.....
В связи с этим вопрос, а таблица

dhs_access_log

по каким причинам не попала в данную схему архивации? Или, если попала, то какой у нее будет тип?

Спасибо!

А зачем её архивировать? Биллинг в неё только пишет, но никогда не читает. Я не вижу смысла вводить для этой таблицы отдельный тип.

[Lex]

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

Спасибо за позитивный комментарий.
С документацией действительно проблемы. Сейчас мы её перерабатываем. Я планирую выпустить обновленную документацию к релизу 008.
Кстати, логика работы классификатора в документации подробно описана и с тех пор по сути не менялась.

[Wishmaster]

Уважаемый Алексей (Lex), уточните пожалуйста одну деталь...
.....
В связи с этим вопрос, а таблица

dhs_access_log

по каким причинам не попала в данную схему архивации? Или, если попала, то какой у нее будет тип?

Спасибо!

А зачем её архивировать? Биллинг в неё только пишет, но никогда не читает. Я не вижу смысла вводить для этой таблицы отдельный тип.

Сорри. Я этого не знал. Тогда буду просто периодически ее чистить.
А если не секрет, зачем она в принципе, если биллинг ее никогда не читает?

[Lex]

Сорри. Я этого не знал. Тогда буду просто периодически ее чистить.
А если не секрет, зачем она в принципе, если биллинг ее никогда не читает?

Так исторически сложилось.
Если не нужна, в mysql есть engine, называется blackhole, можно для этой таблицы использовать его...
У меня есть желание её объявить устаревшей и в следующих версиях не использовать, но я его сдерживаю, т.к., судя по данному форуму, её кто-то периодически использует...

[Gezm0]

5.2.1-007-release-bsd6
6.2-RELEASE-p12 FreeBSD

Убивает ядро ОС при достижении лимита на процесс. После этого падения запустились 2 копии ядра, второй процесс ядра тоже тёк. Второй процесс убили, остался первый с повисшей нитью, грузит одно из ядер на 100%. Админка к ядру не коннектится. Базу не дам.

#0 0x8861b537 in pthread_testcancel () from /lib/libpthread.so.2
#1 0x8860a89a in sigaction () from /lib/libpthread.so.2
#2 0x8860488d in pthread_kill () from /lib/libpthread.so.2
#3 0x88604256 in raise () from /lib/libpthread.so.2
#4 0x887cfb58 in abort () from /lib/libc.so.6
#5 0x88690297 in __gnu_cxx::__verbose_terminate_handler ()
from /usr/lib/libstdc++.so.5
#6 0x8869449c in __cxxabiv1::__terminate () from /usr/lib/libstdc++.so.5
#7 0x886944d4 in std::terminate () from /usr/lib/libstdc++.so.5
#8 0x886944e8 in __cxxabiv1::__unexpected () from /usr/lib/libstdc++.so.5
#9 0x88694db2 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5
#10 0x083b726d in UTM::DBACtx_mysql::_sql_select ()
#11 0x08210385 in UTM::DBACtx::sql_select ()
#12 0x08210406 in UTM::DBAClass::sql_select ()
#13 0x0820b3cb in UTM::DBAccess::raw_sql_select ()
#14 0x08225eae in UTM::DBAccess::get_all_users_full_data ()
#15 0x08307b21 in UTM::DBAccess::search_users_query_new ()
#16 0x8898bf8f in rpcf_search_users_new ()
from /netup/utm5/lib/utm5_core/liburfa-std.so
#17 0x08372e98 in UTM::RPCConn::process ()
#18 0x0836a99e in UTM::__rpcconn_wrapper ()
#19 0x8860c3a5 in pthread_create () from /lib/libpthread.so.2
#20 0x887bb117 in _ctx_start () from /lib/libc.so.6

[Gezm0]

В релизе билда 007 под freebsd6 в debug.log валится огромное количество информации. Уровнем логгирования объём этой информации не уменьшается. Это создаёт излишнюю нагрузку на дисковую подсистему и процессор (при ротации этого мусора). Есть ли какой-либо вариант повысить информативность дебага путём уборки из него избыточной бесполезной информации или вообще избавиться от него? Например, отправить дебаг в /dev/null.

[Lex]

В релизе билда 007 под freebsd6 в debug.log валится огромное количество информации. Уровнем логгирования объём этой информации не уменьшается. Это создаёт излишнюю нагрузку на дисковую подсистему и процессор (при ротации этого мусора). Есть ли какой-либо вариант повысить информативность дебага путём уборки из него избыточной бесполезной информации или вообще избавиться от него? Например, отправить дебаг в /dev/null.

Я отвечал на этот вопрос неоднократно. Рекомендую воспользоваться поиском.

[Gezm0]

В релизе билда 007 под freebsd6 в debug.log валится огромное количество информации. Уровнем логгирования объём этой информации не уменьшается. Это создаёт излишнюю нагрузку на дисковую подсистему и процессор (при ротации этого мусора). Есть ли какой-либо вариант повысить информативность дебага путём уборки из него избыточной бесполезной информации или вообще избавиться от него? Например, отправить дебаг в /dev/null.

Я отвечал на этот вопрос неоднократно. Рекомендую воспользоваться поиском.

Спасибо за ответ. Если у вас нет возможности починить уровень логгирования, будем писать в /dev/null.

[Magnum72]

У меня админка новая существенно тормозит при редактировании и сохранинии пользователя, раза в три медленней чем старая админка. Поправите?