Сегодня рассмотрим, какие системные метрики Greenplum необходимо отслеживать администратору кластера и дата-инженеру для оценки работоспособности и эффективности этой СУБД, а также с помощью каких инструментов это сделать.
Мониторинг средствами Greenplum
Прежде всего, стоит отметить, что контролировать Greenplum можно с помощью различных инструментов, включенных в систему или доступных в качестве надстроек. Это применимо и к отдельным компонентам MPP-СУБД, например, благодаря встроенной интеграции Prometheus в Greenplum Streaming Server можно получать метрики времени выполнения для экземпляра gpss-сервера при включенном мониторинге Prometheus для процесса UNIX. После запуска сервера Prometheus метрики интегрированных сервисов доступны на порту 9090 по умолчанию. Чтобы просмотреть показатели для всех сервисов, интегрированных с Prometheus, следует перейти по URL-адресу в http://<prometheus_host>:9090.
В частности, для мониторинга активности и производительности базы данных VMware Greenplum Command Center, дополнительный веб-интерфейс, предоставляет информацию о состоянии кластера, графические инструменты администрирования, мониторинг запросов в реальном времени, а также исторические данные о кластерах и запросах.
Администратор базы данных Greenplum следит за системой, отслеживая проблемные события, такие как выход из строя сегмента или нехватка места на диске на хосте сегмента. Поскольку Greenplum состоит из нескольких экземпляров PostgreSQL (координатора и сегментов), охватывающих несколько компьютеров, то для мониторинга необходимо знать информацию о системе в целом, а также информацию о состоянии отдельных экземпляров. Для этого используется утилита gpstate, о некоторых сценариях использования которой мы писали здесь.
Также администратору Greenplum следует следить за тем, чтобы файловые системы, в которых находятся каталоги данных координатора и сегмента, не заполнялись более чем на 70%. Хотя более наполненный диск не приведет к повреждению данных, это может помешать нормальной работе. А если диск переполнится, сервер базы данных может отключиться. Чтобы этого не произошло, рекомендуется регулярно запускать команды очистки VACUUM/ VACUUM FULL в пользовательских таблицах, чтобы освободить неиспользуемое пространство.
Для проверки оставшегося свободного места (в килобайтах) в файловых системах узла сегмента можно использовать внешнюю таблицу gp_disk_free в административной схеме данных gp_toolkit, сделав следующий запрос:
SELECT * FROM gp_toolkit.gp_disk_free ORDER BY dfsegment;
Вообще административная схема данных gp_toolkit содержит несколько представлений, которые можно использовать для определения использования дискового пространства для распределенной базы данных, схемы, таблицы или индекса базы данных Greenplum. В частности, представление gp_size_of_database содержит общий размер базы данных (в байтах):
SELECT * FROM gp_toolkit.gp_size_of_database ORDER BY sodddatname;
Представления размера таблицы перечисляют таблицу по идентификатору, а не по имени объекта. Чтобы проверить размер таблицы по имени, надо найти имя отношения (relname) в таблице pg_class, например:
SELECT relname AS name, sotdsize AS size, sotdtoastsize AS toast, sotdadditionalsize AS other FROM gp_toolkit.gp_size_of_table_disk as sotd, pg_class WHERE sotd.sotdoid=pg_class.oid ORDER BY relname;
Увидеть общий размер всех индексов в таблице, используйте представление gp_size_of_all_table_indexes, а размер определенного индекса — представление gp_size_of_index. Представления размера индекса перечисляют таблицы и индексы по идентификатору объекта (а не по имени). Чтобы проверить размер индекса по имени, надо найти имя отношения (relname) в таблице pg_class, например:
SELECT soisize, relname as indexname FROM pg_class, gp_toolkit.gp_size_of_index WHERE pg_class.oid=gp_size_of_index.soioid AND pg_class.relkind='i';
Из-за распределенного характера Greenplum данные таблиц разделены по всем сегментам СУБД. Перекосы, т.е. неравномерно распределенные данные могут снизить производительность обработки SQL-запросов, о чем мы писали здесь. Распределение строк таблицы определяется политика ее распределения, установленной во время создания. Проверить перекосы распределения можно также, используя представления административной схемы данных gp_toolkit.
Чтобы обеспечить максимальную производительность, при обработке SQL-запроса все сегменты должны иметь одинаковую рабочую нагрузку. Рабочая нагрузка обработки запросов может быть неравномерной, если политика распределения данных таблицы и предикаты запроса не совпадают. Проверить перекос обработки поможет следующий SQL-запрос:
SELECT gp_segment_id, count(*) FROM <table_name> WHERE <column>='<value>' GROUP BY gp_segment_id;
Это покажет количество строк, возвращаемых сегментом для данного предиката WHERE. Этот запрос завершится ошибкой, если его запустить в реплицированной таблице, поскольку в запросе нельзя сослаться на системный столбец gp_segment_id в реплицированной таблице. Избежать перекоса в план запроса помогут следующие рекомендации:
- убедитесь, что все таблицы фактов проанализированы;
- убедитесь, что анализируется любая заполненная временная таблица, используемая запросом.
Для этого следует запустить команду EXPLAIN ANALYZE, которая объясняет план SQL-запроса. Если при сканировании с многостолбцовыми фильтрами создается больше строк, чем предполагалось, следует установить для параметра конфигурации сервера gp_selectivity_damping_factor значение 2 или выше. Если перекос возникает при присоединении к одной относительно небольшой таблице фактов (менее 5000 строк), можно задать для параметра конфигурации сервера gp_segments_for_planner значение 1. Далее необходимо повторить проверку запроса. Также рекомендуется проверить, соответствуют ли фильтры, примененные в SQL-запросе, ключам распределения базовых таблиц. Если фильтры и ключи распределения совпадают, можно перераспределить базовые таблицы с другими ключами. Если ключи распределения имеют низкую кардинальность, можно переписать запрос с другими соединяемыми столбцами или дополнительными фильтрами для таблиц, чтобы уменьшить количество строк. Эти изменения могут изменить семантику запроса. Подробнее про команды EXPLAIN И лучшие практики ее использования мы писали здесь и здесь.
Также производительность запросов снижается, когда бэкенд Greenplum создает более 64 вложенных транзакций, что приводит к высокой стоимости поиска для проверки видимости. Обычно это случается при переполнение вложенных транзакций в сочетании с длительными транзакциями, что приводит к еще большему количеству запросов. Рекомендуется завершить такие переполненные бэкенды и/или бэкенды с длительными транзакциями, чтобы смягчить проблемы с производительностью. Сделать это поможет запрос к представлению — gp_suboverflowed_backend—, которое работает с пользовательскими функциями. Результат выполнения этого запроса содержит информацию об идентификаторе сегмента и идентификаторе процесса, которые нужны для прекращения работы серверных частей, вызывающих торможение.
Мониторинг c Prometheus, Grafana и другими внешними сервисами
Впрочем, помимо встроенных утилит Greenplum, которые позволяют выполнять административные операции, на практике удобно использовать визуальные дэшборды, которые наглядно отображают все необходимые параметры. Обычно это реализуется с помощью специализированных сервисов мониторинга, таких как база данных временных рядов Prometheus и платформа визуализации Grafana. Связка Prometheus с Grafana сегодня стала стандартом де-факто для мониторинга системных метрик. Prometheus сам собирает метрики из наблюдаемых систем с помощью механизма pull, периодически отправляя запрос к конечной точке метрик, чтобы получить ее последние значения. Эти данные сохраняются как значения ключей, поскольку базы данных временных рядов активно используют эту модель для хранения данных в высокоэффективном формате. Ключ описывает метрику, а значение содержит ее фактическую величину в виде числа. Поскольку Prometheus относится к базам данных временных рядов, это позволяет отслеживать изменения значений системных метрик во времени. Также в базе хранятся различные метаданные в виде меток (labels). База данных Prometheus является источником данных для Grafana, в веб-интерфейсе которой можно настроить и просматривать графики, гистограммы и другие визуализации.
Например, дата-инженеры и администраторы кластера Greenplum в компании GlowByte использовали связку Prometheus + Grafana, чтобы построить собственные дэшборды, которые отображают статус кластера, сегментов и сервисов, сведения о потреблении ресурсов (память, ЦП, диск) на всех хостах, а также список созданных ресурсных групп и расписание их действия, информацию о запущенных сессиях и пользовательской активности. Помимо этого, для удобного мониторинга активных SQL-запросов дата-инженеры GlowByte разработали собственную библиотеку greenplum.metric.hook, которая использует глобальные переменные и запускает цепочки функций. Полученные метрики отправляются в отдельное приложение по протоколу gRPC, собственная спецификация которого позволила использовать разные методы для хранения и обработки данных на любом языке программирования. Исходный код этой библиотеки открыт и находится в GitLab-репозитории компании. Он доступен для скачивания и использования под лицензией Apache 2.0. Также репозиторий содержит исходные коды дэшбордов для Grafana и настроечные файлы для экспорта системных метрик Greenplum в Prometheus.
Узнайте больше подробностей про администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- https://docs.vmware.com/en/VMware-Greenplum/7/greenplum-database/admin_guide-managing-monitor.html
- https://docs.vmware.com/en/VMware-Greenplum-Streaming-Server/1.10/greenplum-streaming-server/prometheus-integ.html
- https://habr.com/ru/companies/glowbyte/articles/711206/
- https://avamk.ru/monitoring-greenplum-sredstvami-prometheus-grafana.html
- https://git.angara.cloud/gbgreenplum/greenplum.monitoring/-/tree/main/
