Инструмент мониторинга в Amazon Redshift

Question

В DB2 у нас есть db2top, которые помогают отслеживать действия базы данных.

Есть ли эквивалент в Amazon Redshift?

Answer 1

Я пробовал pgtop (http://search.cpan.org/dist/pgtop/pgtop), и он действительно работает для Redshift, но я не считаю его особенно полезным, поскольку Redshift не обрабатывает транзакционный трафик. Я обычно использую

select * from SVV_QUERY_INFLIGHT order by query, sequence; 

или

select pid, user_name, starttime, query from stv_recents where status='Running'; 

показать текущую деятельность. Вы можете использовать

select relation::regclass, mode, pid from pg_locks where locktype != 'virtualxid' ; 

для отображения блокировок. Я также хотел

select * from stv_wlm_query_state where queue_time > 0; 

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

select query, step, rows, workmem, label, is_diskbased from svl_query_summary; 

прежде всего потому, что я хочу знать, если запрос, чтобы писать на диск подразумевающее не хватает памяти. Вне использования предупреждений Cloudwatch для использования ЦП и диска регулярный мониторинг для нас более ориентирован на анализ структуры таблицы. Используйте сценарий в http://docs.aws.amazon.com/redshift/latest/dg/c_analyzing-table-design.html, чтобы сделать этот анализ и вакцину и проанализировать регулярно.

Answer 2

Если вы заинтересованы в мониторинге показателей оборудования (CPU, дискового пространства, ввода/вывода IOP/задержки/пропускной способности), их можно просмотреть на консоли cloudwatch, предоставляемой AWS.

AWS также предоставляет панель мониторинга для мониторинга запущенных и выполненных запросов. Однако, по моему опыту, он не показывает, что все они делают проблемы с отладкой довольно сложными. Несколько полезных агрегированные показатели, которые вы можете собирать и хранить могут быть:

1. Запросы обстреляли одного пользователя: Заговор вышеуказанных данные может помочь в кровянистых выделениях аномалий в использовании кластера конкретного пользователем

     SELECT * FROM stv_recents WHERE status = 'Running'; 
   

2. Количество запросов и среднее время, затраченное на состояние очереди/запуска/возвращения: Если среднее время в состоянии «запуска» очень велико в 1 очереди, это может также повлиять на производительность запросов в других очередях. (Это происходит в настройки WLM позволяют только ограничение на использование памяти и использование CPU)

     SELECT * FROM stv_wlm_query_state; 
   

3. Определить плохие запросы: При определении плохо написанных запросов не является простым, пока после его завершения выполнения (по крайней мере в моем опыте) , несколько прокси-серверов могут помочь избавиться от плохих запросов, пока они все еще выполняются. A выше количество дисхитов и строки, транслируемые через узлы, являются такими индикаторами. Этот запрос предоставит следующий запрос.

   SELECT wlm.query AS query_id, 
        wlm.state, 
        wlm.service_class AS queue, 
        CONVERT_TIMEZONE('Asia/Calcutta',wlm.wlm_start_time) AS starttime, 
        wlm.slot_count, 
        pg_user.usename AS username, 
        ex.inner_bcast_count, 
        bcast.bcast_rows, 
        CAST((wlm.exec_time) AS float)/1000000 AS exec_time, 
        CAST((wlm.queue_time) AS float)/1000000 AS queue_time, 
        CAST(SUM(qs.workmem) AS float)/1000000000 AS workmem, 
        SUM(CASE WHEN qs.is_diskbased = 't' THEN 1 ELSE 0 END) AS num_diskhits 
        FROM stv_wlm_query_state wlm 
        LEFT JOIN svv_query_state qs ON qs.query = wlm.query 
        LEFT JOIN pg_user ON qs.userid = pg_user.usesysid 
        LEFT JOIN (SELECT DISTINCT query, 
            SUM(ROWS) AS bcast_rows 
           FROM stl_bcast 
           GROUP BY 1) bcast ON bcast.query = wlm.query 
        LEFT JOIN (SELECT DISTINCT ex.query, 
           COUNT(*) inner_bcast_count 
           FROM stl_explain ex, 
           stv_wlm_query_state wlm 
           WHERE wlm.query = ex.query 
           AND wlm.state = 'Running' 
           AND ex.plannode LIKE ('%%DS_BCAST_INNER%%') 
           GROUP BY 1) ex ON ex.query = wlm.query 
   GROUP BY 1, 
   2, 
   3, 
   4, 
   5, 
   6, 
   7, 
   8, 
   9, 
   10 
   

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

Вы можете проверить RedEye. Для этого потребуется предварительно установленный экземпляр Statsd и MySQL. Инструмент собирает набор показателей по производительности оборудования и запросов и сохраняет их в вышеуказанных базах данных.