Мониторинг и управление большими запросами

В этой теме описывается, как отслеживать и управлять большими запросами в вашем кластере Selena.

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

Общий подход к обработке больших запросов в Selena выглядит следующим образом:

Установите автоматические меры предосторожности против больших запросов с помощью групп ресурсов и очередей запросов.
Отслеживайте большие запросы в реальном времени и завершайте те, которые обходят меры предосторожности.
Анализируйте журналы аудита и Big Query Logs для изучения паттернов больших запросов и тонкой настройки механизмов предосторожности, которые вы установили ранее.

Эта функция поддерживается начиная с версии 1.5.0.

Установка мер предосторожности против больших запросов

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

Фильтрация больших запросов через группы ресурсов

Группы ресурсов могут автоматически идентифицировать и завершать большие запросы. При создании группы ресурсов вы можете указать верхний лимит времени CPU, использования памяти или количества сканируемых строк, на которые имеет право запрос. Среди всех запросов, которые попадают в группу ресурсов, любые запросы, требующие больше ресурсов, отклоняются и возвращаются с ошибкой. Для получения дополнительной информации и инструкций по группам ресурсов см. Изоляция ресурсов.

Перед созданием групп ресурсов необходимо выполнить следующее утверждение для включения Pipeline Engine, от которого зависит функция Resource Group:

SET GLOBAL enable_pipeline_engine = true;

Следующий пример создает группу ресурсов bigQuery, которая ограничивает верхний лимит времени CPU до 100 секунд, верхний лимит количества сканируемых строк до 100000 и верхний лимит использования памяти до 1073741824 байт (1 ГБ):

CREATE RESOURCE GROUP bigQuery
TO 
    (db='sr_hub')
WITH (
    'cpu_weight' = '10',
    'mem_limit' = '20%',
    'big_query_cpu_second_limit' = '100',
    'big_query_scan_rows_limit' = '100000',
    'big_query_mem_limit' = '1073741824'
);

Если требуемые ресурсы запроса превышают любой из лимитов, запрос не будет выполнен и возвращается с ошибкой. Следующий пример показывает сообщение об ошибке, возвращаемое когда запрос требует слишком много сканируемых строк:

ERROR 1064 (HY000): exceed big query scan_rows limit: current is 4 but limit is 1

Если вы впервые настраиваете группы ресурсов, мы рекомендуем установить относительно высокие лимиты, чтобы они не мешали обычным запросам. Вы можете тонко настроить эти лимиты после того, как получите лучшее понимание паттернов больших запросов.

Снижение перегрузки системы через очереди запросов

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

Выполните следующие утверждения для включения очередей запросов для SELECT запросов:

SET GLOBAL enable_query_queue_select = true;

После включения функции очереди запросов вы можете определить правила для запуска очередей запросов.

Укажите порог параллелизма для запуска очереди запросов.

Следующий пример устанавливает порог параллелизма в 100:
```
SET GLOBAL query_queue_concurrency_limit = 100;
```
Укажите порог соотношения использования памяти для запуска очереди запросов.

Следующий пример устанавливает порог соотношения использования памяти в 0.9:
```
SET GLOBAL query_queue_mem_used_pct_limit = 0.9;
```
Укажите порог соотношения использования CPU для запуска очереди запросов.

Следующий пример устанавливает порог промилле использования CPU (использование CPU * 1000) в 800:
```
SET GLOBAL query_queue_cpu_used_permille_limit = 800;
```

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

Укажите максимальную длину очереди запросов. Когда этот порог достигнут, входящие запросы отклоняются.

Следующий пример устанавливает длину очереди запросов в 100:
```
SET GLOBAL query_queue_max_queued_queries = 100;
```
Укажите максимальный тайм-аут ожидающего запроса в очереди. Когда этот порог достигнут, соответствующий запрос отклоняется.

Следующий пример устанавливает максимальный тайм-аут в 480 секунд:
```
SET GLOBAL query_queue_pending_timeout_second = 480;
```

Вы можете проверить, ожидает ли запрос, используя SHOW PROCESSLIST.

mysql> SHOW PROCESSLIST;
+------+------+---------------------+-------+---------+---------------------+------+-------+-------------------+-----------+
| Id   | User | Host                | Db    | Command | ConnectionStartTime | Time | State | Info              | IsPending |
+------+------+---------------------+-------+---------+---------------------+------+-------+-------------------+-----------+
|    2 | root | xxx.xx.xxx.xx:xxxxx |       | Query   | 2022-11-24 18:08:29 |    0 | OK    | SHOW PROCESSLIST  | false     |
+------+------+---------------------+-------+---------+---------------------+------+-------+-------------------+-----------+

Если IsPending равно true, соответствующий запрос ожидает в очереди запросов.

Мониторинг больших запросов в реальном времени

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

Мониторинг через MySQL клиент

Вы можете просмотреть запросы, которые в настоящее время обрабатываются (current_queries), используя SHOW PROC.

SHOW PROC '/current_queries';

Selena возвращает ID запроса (QueryId), ID соединения (ConnectionId) и потребление ресурсов каждого запроса, включая размер сканированных данных (ScanBytes), количество обработанных строк (ProcessRows), время CPU (CPUCostSeconds), использование памяти (MemoryUsageBytes) и время выполнения (ExecTime).

mysql> SHOW PROC '/current_queries';
+--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
| QueryId                              | ConnectionId | Database   | User | ScanBytes | ProcessRows    | CPUCostSeconds | MemoryUsageBytes | ExecTime |
+--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
| 7c56495f-ae8b-11ed-8ebf-00163e00accc | 4            | tpcds_100g | root | 37.88 MB  | 1075769 Rows   | 11.13 Seconds  | 146.70 MB        | 3804     |
| 7d543160-ae8b-11ed-8ebf-00163e00accc | 6            | tpcds_100g | root | 13.02 GB  | 487873176 Rows | 81.23 Seconds  | 6.37 GB          | 2090     |
+--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
2 rows in set (0.01 sec)

Вы можете дополнительно изучить потребление ресурсов запроса на каждом узле BE, указав ID запроса.

SHOW PROC '/current_queries/<QueryId>/hosts';

Selena возвращает размер сканированных данных запроса (ScanBytes), количество сканированных строк (ScanRows), время CPU (CPUCostSeconds) и использование памяти (MemUsageBytes) на каждом узле BE.

mysql> show proc '/current_queries/7c56495f-ae8b-11ed-8ebf-00163e00accc/hosts';
+--------------------+-----------+-------------+----------------+---------------+
| Host               | ScanBytes | ScanRows    | CpuCostSeconds | MemUsageBytes |
+--------------------+-----------+-------------+----------------+---------------+
| 172.26.34.185:8060 | 11.61 MB  | 356252 Rows | 52.93 Seconds  | 51.14 MB      |
| 172.26.34.186:8060 | 14.66 MB  | 362646 Rows | 52.89 Seconds  | 50.44 MB      |
| 172.26.34.187:8060 | 11.60 MB  | 356871 Rows | 52.91 Seconds  | 48.95 MB      |
+--------------------+-----------+-------------+----------------+---------------+
3 rows in set (0.00 sec)

Мониторинг через консоль FE

В дополнение к MySQL клиенту вы можете использовать консоль FE для визуализированного, интерактивного мониторинга.

Перейдите к консоли FE в вашем браузере, используя следующий URL:
```
http://<fe_IP>:<fe_http_port>/system?path=//current_queries
```
Вы можете просмотреть запросы, которые в настоящее время обрабатываются, и их потребление ресурсов на странице System Info.
Нажмите на QueryID запроса.

Вы можете просмотреть подробную, специфичную для узла информацию о потреблении ресурсов на появившейся странице.

Ручное завершение больших запросов

Если какие-либо большие запросы обходят установленные вами меры предосторожности и угрожают доступности системы, вы можете завершить их вручную, используя соответствующий ID соединения в утверждении KILL:

KILL QUERY <ConnectionId>;

Анализ Big Query Logs

Начиная с версии 1.5.0, Selena поддерживает Big Query Logs, которые хранятся в файле fe/log/fe.big_query.log. По сравнению с журналами аудита Selena, Big Query Logs выводят дополнительные три поля:

bigQueryLogCPUSecondThreshold
bigQueryLogScanBytesThreshold
bigQueryLogScanRowsThreshold

Эти три поля соответствуют порогам потребления ресурсов, которые вы определили для определения того, является ли запрос большим запросом.

Для включения Big Query Logs выполните следующее утверждение:

SET GLOBAL enable_big_query_log = true;

После включения Big Query Logs вы можете определить правила для запуска Big Query Logs.

Укажите порог времени CPU для запуска Big Query Logs.

Следующий пример устанавливает порог времени CPU в 600 секунд:
```
SET GLOBAL big_query_log_cpu_second_threshold = 600;
```
Укажите порог размера сканируемых данных для запуска Big Query Logs.

Следующий пример устанавливает порог размера сканируемых данных в 10737418240 байт (10 ГБ):
```
SET GLOBAL big_query_log_scan_bytes_threshold = 10737418240;
```
Укажите порог количества сканируемых строк для запуска Big Query Logs.

Следующий пример устанавливает порог количества сканируемых строк в 1500000000:
```
SET GLOBAL big_query_log_scan_rows_threshold = 1500000000;
```

Тонкая настройка мер предосторожности

Из статистики, полученной от мониторинга в реальном времени и Big Query Logs, вы можете изучить паттерн пропущенных больших запросов (или обычных запросов, которые ошибочно диагностированы как большие запросы) в вашем кластере, а затем оптимизировать настройки для групп ресурсов и очереди запросов.

Если заметная доля больших запросов соответствует определенному SQL паттерну, и вы хотите навсегда запретить этот SQL паттерн, вы можете добавить этот паттерн в SQL Blacklist. Selena отклоняет все запросы, которые соответствуют любым паттернам, указанным в SQL Blacklist, и возвращает ошибку. Для получения дополнительной информации см. Управление SQL Blacklist.

Для включения SQL Blacklist выполните следующее утверждение:

ADMIN SET FRONTEND CONFIG ("enable_sql_blacklist" = "true");

Затем вы можете добавить регулярное выражение, которое представляет SQL паттерн, в SQL Blacklist, используя ADD SQLBLACKLIST.

Следующий пример добавляет COUNT(DISTINCT) в SQL Blacklist:

ADD SQLBLACKLIST "SELECT COUNT(DISTINCT .+) FROM .+";

Установка мер предосторожности против больших запросов​

Фильтрация больших запросов через группы ресурсов​

Снижение перегрузки системы через очереди запросов​

Мониторинг больших запросов в реальном времени​

Мониторинг через MySQL клиент​

Мониторинг через консоль FE​

Ручное завершение больших запросов​

Анализ Big Query Logs​

Тонкая настройка мер предосторожности​