LINUX.ORG.RU
ФорумAdmin

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

 , ,


1

1

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

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). При этом нагрузка на железо незначительна, проца-памяти-диска сети более чем хватает.

Посоветуйте пожалуйста где искать проблему.

База данных на слабенькой_виртуалке и на боевом_класстере одна и та же (схема, данные)? Может банально индекса не хватает. Версии СУБД совпадают?
Посмотри explain запроса и там и там.
Кластер с партиционированием? Запрос не разбирал, но может там приходится постоянно то один сервер дёргать то другой, и всё висит просто из-за сетевых задержек например

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

База одна и та же, на слабенькой_виртуалке развернут бекап (xtrabackup) того, что крутится в боевом_кластере.

В explain одно и то же. Кластер без партицирования, запрос исполняется на одной ноде.

Обратил внимание, что во время выполнения запроса значительно выросла нагрузка на CPU: в обычном «боевом» режиме суммарная нагрузка составляет около 100-140% (данные согласно atop, нагрузка плавно размазана по ядрам - 16 физическим\32 с учетом гипертрединга), а во время выполнения этого запроса поднимается до 200-240%, причем одно из ядер грузится на 90-100%, а остальные по чуть-чуть. Отмечу, что innodb_thread_concurrency = 32, если это важно. На слабенькой_виртуалке нагрузка на проц возрастает, но до «красной» зоны не доходит ни на одном ядре.

dpronyaev
() автор топика

Не там ищите. За «OUTER» надо удалять «ненужное» еще до рождения. Вот потом и возникают проблемы, одни «спекуляцией» занимаются, а другие «на радостях» код жрущий как не в себя клепают.
OUTER JOIN - надо применять очень осторожно, так же как и вложенные запросы.
Если такой запрос необходим на постоянной основе, то у вас проблема в самом проекте БД. И не ищите черной кошки там где ее нет.

anc ★★★★★
()
Ответ на: комментарий от dpronyaev

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

anc ★★★★★
()
Ответ на: комментарий от anc

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

anonymous
()
Ответ на: комментарий от dpronyaev

Ты только read-uncommited не оставляй, некошерно, и в конечном итоге может привести к разногласному состоянию.

anonymous
()

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

К стати советую перейди на MariaDB

Felgengauer
()
Ответ на: комментарий от anonymous

Такие запросы делаются достаточно редко, так что глобально оставлю дефолтный уровень изоляции repeatable-read (с регулярными запросами проблем нет) - а перед такими вот «тормозными» просто буду выставлять на текущую сессию read-uncommitted.

set session tx_isolation='read-uncommitted'; 
dpronyaev
() автор топика
Ответ на: комментарий от anonymous

Возможно был не правильно понят. Иногда просто злость берет на таких говно пейсателей. Но обобщенная суть проблемы в том что сначала накостыляем что-то, а потом отдельно будем думать как оно должно работать в проде. Джойн тут сработал как «красная тряпка». Сначала мы напишем говно код, а потом мы «внезапно» узнаем что «оно» должно работать у нескольких пользователей, потом так же «внезапно» «вашу мать» да еще и распределенно...

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.