Низкая производительность запросов в кластере Galera

Недавно я переместил производственную систему с одного экземпляра MySQL на кластер Galera с тремя узлами. Кажется, все работает нормально, но для запросов SELECT; производительность запросов с момента переезда резко упала, и теперь она невыносима.

У кого-нибудь есть какие-нибудь советы по настройке производительности Galera? Я полный новичок в Galera, и настройка, которую я сделал, вероятно, самая простая из всех.

Это часть Galera файла my.cnf:

# Galera
wsrep_provider        =/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address    ="gcomm:// 213.179.3.90, 213.179.3.91, 213.179.3.92"
wsrep_sst_method    =rsync
wsrep_cluster_name    =galera_cluster
binlog_format        =ROW
default_storage_engine    =InnoDB
innodb_autoinc_lock_mode=2
innodb_locks_unsafe_for_binlog=1

и вот один запрос, который занимает вечность:

SELECT
    r.customerid,
    r.operator,
    r.account,
    CAST(r.requesttype AS char),
    CAST(SUM(r.nofsms) AS char),
    COALESCE(r.subid1, ''),
    COALESCE(r.subid2, ''),
    COALESCE(r.subid3, '')
FROM
    `smspro`.`smspro_cc_result` r
INNER JOIN smspro.smspro_customer sc ON sc.customerid = r.customerid
    AND sc.smsproinvoice = 0
WHERE
    r.status = 0
        AND r.timestamp >= '2016-05-25'
        AND r.timestamp < '2016-06-25'
        AND r.requesttype IN (1 , 2, 4, 5)
GROUP BY r.customerid , r.operator , r.account , r.requesttype , r.subid1 , r.subid2 , r.subid3
ORDER BY r.customerid , r.operator , r.account , r.requesttype , r.subid1 , r.subid2 , r.subid3

И немного статистики

mysql> select count(*) from smspro_cc_result;
+----------+
| count(*) |
+----------+
|  9170870 |
+----------+

mysql> show index from smspro_cc_result;
+------------------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table            | Non_unique | Key_name      | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+------------------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| smspro_cc_result |          0 | PRIMARY       |            1 | smsproid    | A         |     8825169 |     NULL | NULL   |      | BTREE      |         |               |
| smspro_cc_result |          1 | idx_sms_req_1 |            1 | customerid  | A         |       14757 |     NULL | NULL   |      | BTREE      |         |               |
| smspro_cc_result |          1 | idx_sms_req_2 |            1 | timestamp   | A         |     4412584 |     NULL | NULL   |      | BTREE      |         |               |
| smspro_cc_result |          1 | idx_sms_req_3 |            1 | customerid  | A         |       18233 |     NULL | NULL   |      | BTREE      |         |               |
| smspro_cc_result |          1 | idx_sms_req_3 |            2 | msisdn      | A         |     8825169 |     NULL | NULL   |      | BTREE      |         |               |
| smspro_cc_result |          1 | idx_sms_req_3 |            3 | timestamp   | A         |     8825169 |     NULL | NULL   |      | BTREE      |         |               |
| smspro_cc_result |          1 | idx_sms_req_5 |            1 | msisdn      | A         |     8825169 |     NULL | NULL   |      | BTREE      |         |               |
+------------------+------------+---------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

Я что-то забыл или здесь весь справочный материал?


person koenig    schedule 22.08.2016    source источник
comment
Запрос означает SELECT или все запросы?   -  person Michael - sqlbot    schedule 23.08.2016
comment
SELECT - это проблема, насколько я знаю. Вроде нет проблем с системой, генерирующей данные; это отчетность, которая сильно пострадала с точки зрения производительности.   -  person koenig    schedule 26.08.2016
comment
Вы привязаны к процессору или к диску? Эти машины сопоставимы с прежним сервером? ... особенно в отношении производительности диска и памяти, а также типа и количества ядер? Можно ли сравнить innodb_buffer_pool_size?   -  person Michael - sqlbot    schedule 26.08.2016


Ответы (1)


Мои советы.

Если 3 узла географически разбросаны, задержка на COMMIT дорого обходится.

Вы сравниваете с одним сервером? Или настройка репликации? Или что-то другое? Клиент находится на сервере с одним из узлов? Задействован ли балансировщик нагрузки или прокси?

Если вы не перенастроили несколько параметров InnoDB, Galera не будет работать оптимально. Давайте посмотрим ваш файл конфигурации. (Или опубликуйте как SHOW VARIABLES, так и SHOW GLOBAL STATUS плюс размер оперативной памяти.)

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

person Rick James    schedule 22.08.2016
comment
Спасибо за помощь коллеге - person Drew; 23.08.2016
comment
Я сравниваю с одним сервером - я заменил его кластером для избыточности. Все серверы территориально находятся в одном месте (все виртуальные, надо добавить). - person koenig; 23.08.2016
comment
Все виртуальные... что означает... все они работают на одном и том же общем физическом оборудовании, читают и пишут в разные каталоги, но на одном диске? Или три независимых сервера, которые оказались виртуальными машинами? - person Michael - sqlbot; 23.08.2016
comment
Три сервера, которые являются виртуальными. У них есть свой диск, сетевая карта и т.д. - person koenig; 23.08.2016
comment
Это в каком-то Облаке? Та же зона доступности? - person Rick James; 23.08.2016
comment
Вы определили конкретный запрос, который выполняется заметно медленнее? - person Rick James; 23.08.2016
comment
То же самое — мы полагаемся на поставщика, который предоставляет инфраструктуру, поэтому я предполагаю, что все это находится в одном месте (возможно, в одной стойке). - person koenig; 23.08.2016
comment
Будем надеяться, что никто не споткнется о шнур питания этой стойки. По крайней мере, Галера, вероятно, восстановится, когда они вернутся. - person Rick James; 23.08.2016