Проблемы с производительностью

• Как выяснить причину снижения производительности в пиках нагрузки?

• Как выяснить причину общего снижения производительности?

• Как выяснить причину долгой загрузки ресурсов?

• Как выяснить причину утилизации ресурса CPU?

• Как выяснить причину утилизации ресурса IO?

• Как выяснить причину утилизации ресурса сети?

• Как выяснить причины блокировок?

• Как оптимизировать проблемные запросы?

Как выяснить причину снижения производительности в пиках нагрузки?Как выяснить причину снижения производительности в пиках нагрузки?

Просмотрите лог медленных запросов:

1. В настройках кластера MySQL® установите значение Long query time больше нуля.
2. В консоли управления на странице кластера выберите вкладку Логи.
3. В левом верхнем углу выберите из выпадающего списка MYSQL_SLOW_QUERY.

Как выяснить причину общего снижения производительности?Как выяснить причину общего снижения производительности?

Проверьте графики мониторинга хостов:

1. Перейдите на страницу каталога и выберите сервис Managed Service for MySQL.
2. Нажмите на имя нужного кластера, затем выберите вкладку Хосты.
3. Перейдите на страницу Мониторинги:
   • Рекомендуется увеличить класс хостов:
     • При стабильно высоком значении Steal графика CPU usage.
     • При стабильно низком значении Free графика Memory usage.
   • При высоком значении iowait графика CPU usage возможно превышение лимитов IOPS дискового хранилища. Рекомендуется увеличить значение как минимум до следующего порога блока размещения или использовать более быстрые диски. Подробнее о лимитах и производительности дисков см. в документации Yandex Compute Cloud.

Почему отстает реплика?Почему отстает реплика?

1. Проверьте, установлено ли параметру slave_rows_search_algorithms значение INDEX_SCAN,HASH_SCAN.
2. Вместо выполнения операции ALTER TABLE над объемными таблицами рекомендуется использовать утилиту pt-online-schema-change из пакета Percona Toolkit — это обеспечит отсутствие блокировок.
3. Если отставание сохраняется, включите параллельную репликацию. Для этого настройте параметры:

   slave_parallel_type=LOGICAL_CLOCK
   slave_parallel_workers=8
   

4. Выполните на реплике команду SHOW SLAVE STATUS;. Если значение параметра Executed_Gtid_Set долго не меняется, убедитесь, что во всех таблицах присутствуют индексы.
5. Если данные пишутся в БД непрерывно и при этом объем оперативной памяти на хосте 8 ГБ или больше, рекомендуется увеличить значение параметра innodb_log_file_size до 1-2 ГБ (изменение параметра происходит с рестартом сервера).

Как выяснить причину долгой загрузки ресурсов?Как выяснить причину долгой загрузки ресурсов?

Проверьте графики мониторинга хостов:

1. Перейдите на страницу каталога и выберите сервис Managed Service for MySQL.
2. Нажмите на имя нужного кластера, затем выберите вкладку Хосты.
3. Перейдите на страницу Мониторинги.
4. Найдите проблемный ресурс: график будет приближаться к границе или выйдет за нее.
5. Выберите другие хосты из выпадающего списка и проверьте их тоже.

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

Как выяснить причину утилизации ресурса CPU?Как выяснить причину утилизации ресурса CPU?

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

1. Выдайте пользователю привилегию PROCESS, выполнив команду CLI:

   yc managed-mysql user update \
       --global-permissions PROCESS <имя_пользователя> \
       --cluster-id <идентификатор_кластера>
   

2. Получите список запросов в базу с наибольшим временем выполнения с помощью запроса:

   SELECT * FROM sys.statement_analysis LIMIT 10;
   

Обратите внимание на запросы с высокими значениями rows_examined, rows_sorted или флагом full_scan — с большой вероятностью именно они потребляют ресурсы CPU. Подробнее см. в документации MySQL®.

Как выяснить причину утилизации ресурса IO?Как выяснить причину утилизации ресурса IO?

Приблизительную информацию о потреблении ресурса IO потоками в MySQL® можно получить с помощью системных представлений. Для доступа к ним потребуется административная привилегия PROCESS уровня кластера.

1. Выдайте пользователю привилегию PROCESS, выполнив команду CLI:

   yc managed-mysql user update \
       --global-permissions PROCESS <имя_пользователя> \
       --cluster-id <идентификатор_кластера>
   

2. Получите список потоков с помощью запроса:

   SELECT   t.name             AS thread_name,
            t.processlist_user AS user,
            t.processlist_info AS query,
            t.processlist_time AS time,
            io.bytes           AS bytes
   FROM     performance_schema.threads t
   JOIN
            (
                     SELECT   thread_id,
                              sum(number_of_bytes) AS bytes
                     FROM     performance_schema.events_waits_history_long
                     WHERE    object_type='FILE'
                     GROUP BY thread_id) io
   ON       t.thread_id = io.thread_id
   ORDER BY io.bytes DESC;
   

Как правило, выше в таблице находятся потоки, обслуживающие буферный пул и репликацию. Такое состояние является нормой.

Как выяснить причину утилизации ресурса сети?Как выяснить причину утилизации ресурса сети?

Повышенную нагрузку на сеть могут вызывать: SELECT, возвращающий большое число записей, INSERT больших объемов данных или UPDATE, изменяющий множество строк. В случае записи изменения будут реплицироваться на хосты-реплики, что вызовет дополнительный трафик.

Приблизительную информацию о потреблении ресурса сети потоками в MySQL® можно получить с помощью системных представлений. Для доступа к ним потребуется административная привилегия PROCESS уровня кластера.

1. Выдайте пользователю привилегию PROCESS, выполнив команду CLI:

   yc managed-mysql user update \
       --global-permissions PROCESS <имя_пользователя> \
       --cluster-id <идентификатор_кластера>
   

2. Получите список потоков с помощью запроса:

   SELECT   t.name                       AS thread_name,
            t.processlist_user           AS user,
            t.processlist_info           AS query,
            t.processlist_time           AS time,
            net.bytes/t.processlist_time AS avg_bytes,
            net.bytes                    AS total_bytes
   FROM     performance_schema.threads t
   JOIN
            (
                     SELECT   thread_id,
                              Sum(variable_value) bytes
                     FROM     performance_schema.status_by_thread
                     WHERE    variable_name IN ('Bytes_sent',
                                                'Bytes_received')
                     GROUP BY thread_id ) net
   ON       t.thread_id = net.thread_id
   WHERE    t.processlist_time IS NOT NULL
   ORDER BY net.bytes DESC;
   

   Этот запрос возвращает статистику с момента запуска потоков, поэтому долгоживущие соединения (например, репликация) будут в нем выше.

Как выяснить причины блокировок?Как выяснить причины блокировок?

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

1. Выдайте пользователю привилегию PROCESS, выполнив команду CLI:

   yc managed-mysql user update \
       --global-permissions PROCESS <имя_пользователя> \
       --cluster-id <идентификатор_кластера>
   

2. Для просмотра блокировок уровня таблиц выполните запрос:

   SELECT * FROM sys.schema_table_lock_waits
   

3. Для просмотра блокировок уровня отдельных строк выполните запрос:

   SELECT * FROM sys.innodb_lock_waits
   

Подробнее см. в документации MySQL®.

Как оптимизировать проблемные запросы?Как оптимизировать проблемные запросы?

Обратитесь к официальной документации MySQL®:

• Использование операции EXPLAIN.
• Оптимизация запросов.
• Оптимизация таблиц.