Документ описывает методологию выявления узких мест производительности и представляет типовые сценарии настройки производительности как внутри базы данных YMatrix, так и вне её.
Когда SQL-запрос бизнес-приложения замедляется или вы хотите улучшить его производительность, сначала определите характер проблемы на основе наблюдаемых симптомов:
Замедлен ли весь сервер:
Или замедлен только конкретный SQL-запрос:
После выявления медленного SQL-запроса следуйте следующему подходу для диагностики и анализа:
Примечание!
Существует множество способов сбора информации. Здесь мы подробно описываем только 1–2 метода. Вы можете использовать другие знакомые вам команды для сбора и анализа.
| Категория | Информация | Сбор | Анализ |
| Ресурсы сервера | Нагрузка на CPU | YMatrix GUI — «Cluster Management» — «Metrics View»: ∙ Нагрузка на CPU по узлам или используйте команду top: ∙ User CPU (us) ∙ System CPU (sy) ∙ Idle CPU (id) | ∙ При высокой нагрузке на CPU определите, высока ли нагрузка на user CPU или system CPU ∙ Высокая нагрузка на user CPU указывает на процесс, потребляющий избыточные ресурсы CPU; проверьте эффективность кода ∙ Высокая нагрузка на system CPU может указывать на нехватку других ресурсов (дисковый I/O, память, сеть) |
| Память и виртуальная память | YMatrix GUI — «Cluster Management» — «Metrics View»: ∙ Использование памяти по узлам или используйте vmstat для детального просмотра памяти: ∙ si (swap-in: KB/s с swap в RAM) ∙ so (swap-out: KB/s из RAM в swap) | Если si и so постоянно не равны нулю, памяти недостаточно, а активный свопинг снижает производительность | |
| Дисковый I/O (скорость чтения/записи) | YMatrix GUI — «Cluster Management» — «Metrics View»: ∙ Дисковый I/O по узлам или используйте iostat -x: ∙ %util (процент времени, когда происходила активность I/O) ∙ %iowait (процент времени, когда CPU ожидал завершения I/O) | ∙ Производительность зависит от скорости дискового I/O, а не от его ёмкости. Если %util приближается к 100%, система I/O перегружена ∙ Высокий %iowait указывает на узкое место I/O; рассмотрите возможность обновления или замены массива дисков |
|
| Сеть | YMatrix GUI — «Cluster Management» — «Metrics View»: ∙ Скорость приёма/передачи сети по узлам или используйте sar -n DEV 1 2: ∙ rxkB/s (скорость приёма в KB/s) ∙ txkB/s (скорость передачи в KB/s) | Сравните rxkB/s с общей пропускной способностью сети. Если значение близко к максимуму, существует сетевое узкое место | |
| Параметры ядра | Для систем Linux проверьте значения в /proc/sys, например: cat overcommit_memory | Настройка параметров ОС в основном включает корректировку политик использования памяти и увеличение размера swap-пространства для снижения давления на память. Изменяйте параметры ядра, редактируя соответствующие файлы в /proc/sys (изменения вступают в силу немедленно, но не сохраняются после перезагрузки) |
Примечание!
Опции, перечисленные в таблице, не являются обязательными.
| Программная среда | Версия операционной системы | Используйте uname -a | Определите, связана ли проблема с версией ОС |
| Версия YMatrix | Выполните SELECT version(); | Определите, связана ли проблема с версией YMatrix | |
| Информация о кластере | Топология кластера | ∙ YMatrix GUI — «Cluster Management» ∙ Или выполните SELECT * FROM gp_segment_configuration; | Если произошёл failover, один физический узел может содержать больше Segments, что потенциально снижает производительность |
| Информация о базе данных | Структура таблиц | ∙ YMatrix GUI — «Data Tables» ∙ Или используйте команду \d+ | Проверьте, не приводит ли неправильный ключ распределения к серьезному перекосу данных |
| Соответствующие логи | По умолчанию логи YMatrix находятся в $HOME/gpAdminLogs Логи базы данных находятся в соответствующих директориях данных | Проанализируйте логи при необходимости | |
| Медленные запросы | YMatrix GUI — «Query Monitoring»: проверьте заблокированные сессии | Если существуют медленные запросы, определите и проанализируйте их | |
| План запроса | Используйте EXPLAIN SELECT... для просмотра плана выполнения запроса | Если стоимость плана слишком высока, проанализируйте путь и причину | |
| Создание снапшота окружения | Используйте диагностический инструмент minirepro от YMatrix |
Внутренняя настройка базы данных означает оптимизацию отдельных SQL-запросов.
Симптом:
После значительных изменений данных (вставки, удаления) статистика по таблице может устареть. Это может привести к тому, что оптимизатор выберет неоптимальный план запроса из-за неточных оценок, что снизит производительность.
Метод диагностики:
Используйте вывод команды ANALYZE, чтобы проверить точность статистики. Если значение EXPLAIN ANALYZE в плане запроса значительно отклоняется, статистика устарела. Повторно выполните:
=# ANALYZE <tablename>;Симптом:
В некоторых случаях неправильно выбранный ключ распределения приводит к неравномерному распределению данных между несколькими экземплярами MXSegment, вызывая перекос данных. Это вызывает эффект «самого слабого звена» в распределённой архитектуре YMatrix: время выполнения запроса зависит от самого медленного MXSegment плюс время обработки MXMaster.
Метод диагностики:
Выполните следующую команду для проверки распределения данных. Большие различия между MXSegment указывают на перекос:
=# SELECT gp_segment_id, count(*) FROM <tablename> GROUP BY gp_segment_id;Решение:
Если обнаружен перекос данных, рассмотрите возможность изменения ключа распределения для достижения равномерного распределения. Используйте следующие команды:
=# ALTER TABLE <tablename> SET DISTRIBUTED BY(<newcolumn>);
=# ALTER TABLE <tablename> SET WITH (REORGANIZE=true);
=# ANALYZE <tablename>;Примечание!
Выбор ключа распределения при проектировании схемы напрямую влияет на распределение данных и производительность запросов. Изменение ключа после развертывания несёт повышенные риски производительности. Рекомендуем тщательно выбирать ключ при проектировании. См. Лучшие практики YMatrix DDL.
Симптом:
Частые операции UPDATE или DELETE без регулярной очистки данных приводят к раздуванию таблиц.
Решение:
=# DROP TABLE <partition_tablename>;=# VACUUM <tablename>;Подробности см. в разделе Регулярная vacuum-очистка.
=# ALTER TABLE <tablename> SET WITH (REORGANIZE=true);
=# ANALYZE <tablename>;Если ни одна из вышеперечисленных причин не объясняет проблему производительности SQL, проанализируйте план запроса и задайте себе вопросы:
enable_\<operator> в SQL-запросе.WHERE и используйте явный синтаксис 1, чтобы зафиксировать порядок соединений. Также рассмотрите возможность сбора дополнительной статистики по столбцам соединения.JOIN строк, так как сама родительская таблица не содержит данных.Дополнительную информацию о планах запросов см. в разделе Понимание планов запросов.