Столкнулся при обновлении в проблемой якобы дедлока, на самом деле это не дед лок а просто лок)
Таблица влочится во время запуска скорее всего связано с тем что много времени обновлялся и при запуске начинаются выполнятся действия отложеной "синхронизации", что приводит в блокировки жизненоважных таблиц для того же запуска и утмка начинает перезапускать соединения с мускулом)
база чуть меньше 4гб
пользователей 800 и 1700 карточных 200 из которых "активны"
если это "нагруженая система" то я сантаклаус).
Решение проблемы - упростить обработку запросов для мускула, т.е. сделать много кеша и кое что еще :
read_buffer_size = ХХ
sort_buffer_size = ХХ
key_buffer=XX
max_allowed_packet = XX
innodb_locks_unsafe_for_binlog (при записи лочит меньше "пространства", но если применяется бинлог для любых целей то может привести к повреждениею, не самих данных а их репликации )
,а теперь хит сезона )
innodb_flush_log_at_trx_commit = 0 (по умолчанию 1)
если 0 - каждую секунду хашит кеш на диск
если 1 - то по каждому запросу на запись
lancelot писал(а):Однозначно если база 20000 надо брать что то серьёзнее.
И пусть это будет даже 300000р стоить..
Не всё то золото что блестит, можно найти на много дешевле, а глюки у всех билингов, уневирсальной программы не возможно создать под все системы в разряде винды или линукса, под конкретную систему надо делать свой релиз тогда и глюков будет меньше.
lancelot писал(а):Однозначно если база 20000 надо брать что то серьёзнее.
И пусть это будет даже 300000р стоить..
Не всё то золото что блестит, можно найти на много дешевле, а глюки у всех билингов, уневирсальной программы не возможно создать под все системы в разряде винды или линукса, под конкретную систему надо делать свой релиз тогда и глюков будет меньше.
тогда продовцам если берутся за сопровождение, то они должны отвечать ценьгой за упущеную выгоду
а то типа купите - ну купили
ну типа давайте опровождение - давайте
а если грлюки и абоненты разбежались, извините мы умываем руки ... так получается
Мда похоже что даже с моими твиками ошибка всеравно возникала причем периодически система восстанавливалась сама.
Вообще как старый пользователь утм не могу не заметить прогресса в плане "мудрых" доработок продукта, но уж очень медленно парни учатся , такое ощущение что билинг продолжают доробоватывать студенты пятых курсов по совместительству.
Мы вместе с переходом с 003 на 005 обновили еще и мускул. В результате перестал работать регистронезависимый поиск. У нас наименование организаций и фамилии хранятся в "название" или же таблица users, full_name. Делаю запрос такой руками:
SELECT * FROM `users` WHERE `full_name` LIKE '%molokanov%'
Тоже находит.
А вот в админке я так искать не могу. Запрос, который использует админка перехватить не удается (при дебаге 3), чтобы проверить. Локаль в базе UTF-8 Unicode. Кто знает, в чем может быть дело?
kaN5300 писал(а):Мы вместе с переходом с 003 на 005 обновили еще и мускул. В результате перестал работать регистронезависимый поиск. У нас наименование организаций и фамилии хранятся в "название" или же таблица users, full_name. Делаю запрос такой руками:
SELECT * FROM `users` WHERE `full_name` LIKE '%molokanov%'
Тоже находит.
А вот в админке я так искать не могу. Запрос, который использует админка перехватить не удается (при дебаге 3), чтобы проверить. Локаль в базе UTF-8 Unicode. Кто знает, в чем может быть дело?
Кажется я что-то пропустил. На http://netup.ru/ нет инфы про 006 =). Интересно, а они в ней (006) сделают разделение таблицы в которой хранится инфа о трафике =).
kaN5300 писал(а):Кажется я что-то пропустил. На http://netup.ru/ нет инфы про 006 =). Интересно, а они в ней (006) сделают разделение таблицы в которой хранится инфа о трафике =).
она выдается пока только по запросу тем у кого техподдержка или сопровождение. Я обновился, пока вроде норм. На счет трафика, я пока не понял, но как сказали, до момента релиза, эта технология реализована не полностью. Т.е. походу, полюбому нужно ждать релиза, где все это будет нормально внедрено.
?Debug : мар 05 18:39:09 UTM5 DBA: Using utm_towlower with wchar support
?Debug : мар 05 18:39:09 UTM5 DBA: Using utm_towlower with wchar support
?Debug : мар 05 18:39:09 UTM5 DBA: User with id <2919> not added to search resul
ts
?Debug : мар 05 18:39:09 UTM5 DBA: Search string <3246> vs <user2792> criteria <
1> what_id <2>
?Debug : мар 05 18:39:09 UTM5 DBA: Using utm_towlower with wchar support
?Debug : мар 05 18:39:09 UTM5 DBA: Using utm_towlower with wchar support
?Debug : мар 05 18:39:09 UTM5 DBA: User with id <2920> not added to search resul
ts
?Debug : мар 05 18:39:09 UTM5 DBA: Search string <3246> vs <user2793> criteria <
1> what_id <2>
?Debug : мар 05 18:39:09 UTM5 DBA: Using utm_towlower with wchar support
?Debug : мар 05 18:39:09 UTM5 DBA: Using utm_towlower with wchar support
?Debug : мар 05 18:39:09 UTM5 DBA: User with id <2921> not added to search resul
ts
mikkey finn писал(а):
Поиск реализуется онанизмом. причем даже не себе.
от поиска по базе давно отказались в силу его скорости. медленный он был.
В 004 верчии ситуация была такая при поиске пользователя сначала делался запрос к базе SELECT * FROM users
а потом из полученных данных ядром выбирались нужные пользователя
Нельзя ли совместить два метода? если в аргументах поиска указаны значения которые есть в таблице users то их учитывать при SELECT?
При смене тарифа следующего расчетного периода (расчетные периоды у каждого свои, ежемесячные), в 00:00 списывыется стоимость нового тарифного плана и стоимость старого тарифного плана. У обоих тарифов тип списания - в начале месяца. В услугах виден только новый тариф. Списывается у всех пользователей. Т.е. это не случайный глюк.
Как я понимаю, это не документированная фича новой сборки, направлена на повышение благосостояния провайдера? Спасибо конечно за заботу. Но как бы от этой фичи избавиться?
Итак почитав тут понял что вовремя очухалить. И покупать этот биллинг не будем! Сейчас идут плотные переговоры с LanBilling и тестирование.
кажется выбор всета ки падет на него.