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 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.