@vlarkanov

Mysql: почему тормозит\зависает SELECT запрос в Percona XtraDB Cluster?

Есть вот такой запрос.


SELECT DATE(t1.starttime) AS day, sum(t1.sessiontime) AS calltime,
sum(t1.sessionbill) AS cost, count(*) as nbcall,
sum(t1.buycost) AS buy, sum(case when t1.sessiontime>0 then
1 else 0 end) as success_calls
FROM cc_call t1 LEFT OUTER JOIN cc_trunk t3 ON
t1.id_trunk = t3.id_trunk
LEFT OUTER JOIN cc_ratecard t4 ON t1.id_ratecard = t4.id
WHERE t1.starttime >= ('2017-12-1') AND t1.starttime <=
('2017-12-31 23:59:59')
AND (t1.terminatecauseid=1) GROUP BY day ORDER BY day;


На слабенькой виртуалке (2ядра, 2гб) с развернутой копией базы он выполняется менее чем за две минуты.

В боевом кластере
Debian 9, Percona Xtradb Cluster 75.7.19,
2 железных сервера (2*Intel Xeon E5-2650, 196Gb RAM, 2*SSD в RAID1)
+ виртуалка с арбитратором

с запросом происходит вот что. Если выполнять его ночью - выполняется минуты за 3-4. Если выполнять днем, под нагрузкой - выполняется неопределенно долго (сейчас уже около 20 минут висит в статусе Sending data). При этом нагрузка на железо незначительна, проца-памяти-диска сети более чем хватает.

Посоветуйте пожалуйста где искать проблему.
  • Вопрос задан
  • 368 просмотров
Решения вопроса 1
@Sovetnikov
технический директор pulsprodaj.ru
1. Попробуйте запрос не в кластер, а напрямую в один из серверов
2. Посмотрите план выполнения запросов на локальной копии и на боевом, сравните
3. Проверьте блокировки в БД, может транзакции висят

Если данные совершенно одинаковые, то либо статистика собранная настолько кривая (но не думаю), либо дело в сервере (может там память кончается и в своп всё ходит, памяти конечно у вас много но всё же? диск не переполнен? диски вообще живые, без ошибок?)
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@Xilian
Программист 1С, сетевые технологии, SQL
Попробуй WITH (nolock). Возможно просто постоянные записи в таблицу.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы