BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 21 май 2024, 19:04

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 7 ] 
Автор Сообщение
 Заголовок сообщения: Отчет по направлениям, 9гб данных
СообщениеДобавлено: 02 ноя 2017, 14:57 
Не в сети

Зарегистрирован: 26 июл 2010, 21:18
Сообщения: 70
Карма: 0
Добрый день.
Чем больше база данных за месяц тем меньше шансов что загрузится в клиенте отчет по направлениям.
Ставишь и он пару часов работает (судя по нагрузке на сервер и наличию запросов к базе), а потом перестает, безо всяких ошибок.
В итоге бг клиент подвис и отчета нет.
Только с более менее большими клиентами. Например, в данный момент, не получается выгрузить отчет за месяц у клиента с 6.5млн звонков.
За 1 день грузит, но для сверок и счетов это не годится.
Таблица log_session_4_201710 при этом занимает ~9Гб в innoDB.
Понятно, что можно поменять процессор на более быстрый и будет небольшой прирост скорости, но с учетом того что один процесс в mysql - одно ядро - сильно лучше не станет и в скором времени придем к той же ситуации.

Вопрос можно ли как-то оптимизировать базу\биллинг чтобы этот процесс занимал меньше времени, или, хотя бы, не отбивался по таймауту как сейчас и пусть за пол дня, но выдавал данные.
Клиент 7.0.906.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 ноя 2017, 15:22 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Речь идет об отчете в договоре ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 ноя 2017, 15:45 
Не в сети

Зарегистрирован: 26 июл 2010, 21:18
Сообщения: 70
Карма: 0
Да, договор - отчет - направления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 ноя 2017, 16:05 
Не в сети

Зарегистрирован: 26 июл 2010, 21:18
Сообщения: 70
Карма: 0
Вот последний пример считало 2.5 часа, отправляя запросы вида

SELECT dest_code, COUNT( id )
FROM log_session_4_201710
WHERE lid
IN ( 2135 )
AND DAYOFMONTH( session_start ) >=1
AND DAYOFMONTH( session_start ) <=31
AND TYPE =1
AND session_time !=0
AND session_cost !=0
AND dest_code =27122
GROUP BY dest_code

причем dest_code от начала до 95000 считается за неск секунд, а вот дальше долго долго думает над каждым и в конечном итоге прекращает работать где-то на 99ххх. Ошибок нигде в логах нет.
Памяти свободной полно, место есть...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 ноя 2017, 17:15 
Не в сети

Зарегистрирован: 26 июл 2010, 21:18
Сообщения: 70
Карма: 0
Добавлю - от времени не зависит. Прошел час, поставил меньший диапазон, не 1-31 число а 1-15.
Опять перестало считать на dest_code=99ххх.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 ноя 2017, 18:53 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Напишите в helpdesk, дайте доступ, посмотрим на месте.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 10 ноя 2017, 17:11 
Не в сети

Зарегистрирован: 26 июл 2010, 21:18
Сообщения: 70
Карма: 0
Пофикшено через HD.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 7 ] 

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
POWERED_BY
Русская поддержка phpBB
[ Time : 0.048s | 32 Queries | GZIP : On ]