Comment puis-je résoudre les problème de performance des clusters ou des requêtes dans Amazon Redshift ?

Brève description

Si vous rencontrez des problèmes de performance dans votre cluster Amazon Redshift, procédez comme suit :

• Surveillez les indicateurs de performance de votre cluster.
• Consultez les recommandations d’Amazon Redshift Advisor.
• Passez en revue les alertes relatives à l’exécution des requêtes et à l’utilisation excessive du disque.
• Vérifiez les problèmes de verrouillage et les sessions ou transactions de longue durée.
• Vérifiez la configuration de votre gestion de la charge de travail (WLM).
• Vérifiez la maintenance matérielle et les performances de votre nœud de cluster.

Résolution

Surveiller les indicateurs de performance de votre cluster

Passez en revue les indicateurs et les graphiques de performance de votre cluster afin d’identifier la cause première de la dégradation des performances. Consultez les données de performance dans la console Amazon Redshift pour comparer les performances du cluster au fil du temps.

Une augmentation de ces indicateurs peut indiquer une augmentation de la charge de travail et des conflits de ressources sur votre cluster Amazon Redshift. Pour en savoir plus, consultez la section Surveillance d’Amazon Redshift à l’aide de métriques CloudWatch.

Consultez la répartition de l’exécution de la charge de travail dans la console Amazon Redshift pour passer en revue les requêtes et les exécutions spécifiques. Par exemple, si vous constatez une augmentation du temps de planification des requêtes, il se peut qu’une requête soit en attente d’un verrou.

Consulter les recommandations d’Amazon Redshift Advisor

Utilisez les recommandations d’Amazon Redshift Advisor pour en savoir plus sur les améliorations potentielles à apporter à votre cluster. Les recommandations sont basées sur les modèles d’utilisation courants et les meilleures pratiques d’Amazon Redshift.

Passer en revue les alertes relatives à l’exécution des requêtes et à l’utilisation excessive du disque

Lors de l’exécution d’une requête, Amazon Redshift note les performances de la requête et indique si la requête s’exécute efficacement. Si la requête est identifiée comme inefficace, Amazon Redshift note son ID et fournit des recommandations pour en améliorer les performances. Ces recommandations sont enregistrées dans la table système interne STL_ALERT_EVENT_LOG.

Si vous rencontrez une requête lente ou inefficace, vérifiez les entrées STL_ALERT_EVENT_LOG. Pour récupérer les informations de la table STL_ALERT_EVENT_LOG, exécutez la requête suivante :

SELECT TRIM(s.perm_table_name) AS TABLE    , (SUM(ABS(DATEDIFF(SECONDS, Coalesce(b.starttime, d.starttime, s.starttime), CASE
            WHEN COALESCE(b.endtime, d.endtime, s.endtime) > COALESCE(b.starttime, d.starttime, s.starttime)
            THEN COALESCE(b.endtime, d.endtime, s.endtime)
        ELSE COALESCE(b.starttime, d.starttime, s.starttime)
    END))) / 60)::NUMERIC(24, 0) AS minutes
    , SUM(COALESCE(b.ROWS, d.ROWS, s.ROWS)) AS ROWS
    , TRIM(SPLIT_PART(l.event, ':', 1)) AS event
    , SUBSTRING(TRIM(l.solution), 1, 60) AS solution
    , MAX(l.QUERY) AS sample_query
    , COUNT(DISTINCT l.QUERY)
FROM STL_ALERT_EVENT_LOG AS l
LEFT JOIN stl_scan AS s
    ON s.QUERY = l.QUERY AND s.slice = l.slice AND s.segment = l.segment
LEFT JOIN stl_dist AS d
    ON d.QUERY = l.QUERY AND d.slice = l.slice AND d.segment = l.segment
LEFT JOIN stl_bcast AS b
    ON b.QUERY = l.QUERY AND b.slice = l.slice AND b.segment = l.segment
WHERE l.userid > 1 AND l.event_time >= DATEADD(DAY, -7, CURRENT_DATE)
GROUP BY 1, 4, 5
ORDER BY 2 DESC, 6 DESC;

La requête répertorie les ID de requête ainsi que les problèmes et occurrences de problèmes les plus courants pour la requête exécutée sur le cluster.

Voici un exemple de sortie de la requête et des informations qui décrivent pourquoi l’alerte a été déclenchée :

table | minutes | rows |               event                |                        solution                        | sample_query | count-------+---------+------+------------------------------------+--------------------------------------------------------+--------------+-------
NULL  |    NULL | NULL | Nested Loop Join in the query plan | Review the join predicates to avoid Cartesian products |      1080906 |     2

Pour examiner les performances des requêtes, consultez les requêtes de diagnostic pour le réglage des requêtes. Assurez-vous que vos opérations de requête sont conçues pour fonctionner efficacement. Par exemple, les opérations de jointure ne sont pas toutes efficaces. Une jointure en boucle imbriquée est le type de jointure le moins efficace. Étant donné que les jointures de boucles imbriquées augmentent considérablement le temps d’exécution des requêtes, essayez d’éviter les boucles imbriquées.

Pour vous aider à diagnostiquer le problème, identifiez les requêtes qui exécutent les boucles imbriquées. Pour plus d’informations, consultez Comment puis-je résoudre les problèmes liés à une utilisation élevée ou complète du disque avec Amazon Redshift ?

Rechercher la présence éventuelle de problèmes de verrouillage et de sessions ou transactions de longue durée

Avant d’exécuter une requête sur le cluster, Amazon Redshift peut acquérir des verrous au niveau des tables impliquées dans les exécutions de requêtes. Parfois, les requêtes semblent ne pas répondre, ou il y a un pic d’exécution des requêtes. Si vous rencontrez un pic d’exécution de votre requête, il se peut qu’un problème de verrouillage en soit la cause. Pour plus d’informations, consultez Pourquoi le temps de planification de mes requêtes est-il si long dans Amazon Redshift ?

Si votre table est actuellement verrouillée par un autre processus ou une autre requête, votre requête ne peut pas continuer. Par conséquent, votre requête n’apparaît pas dans la table STV_INFLIGHT. Au lieu de cela, votre requête en cours apparaît dans la table STV_RECENTS.

Parfois, une transaction de longue durée peut entraîner l’arrêt de la réponse d’une requête. Prenez les mesures suivantes pour que les sessions ou transactions de longue durée n’affectent pas les performances de vos requêtes :

• Utilisez les STL_SESSIONS et SVV_TRANSACTIONS pour vérifier les sessions et les transactions de longue durée, puis y mettre fin.
• Concevez vos requêtes de manière à ce qu’Amazon Redshift puisse les traiter rapidement et efficacement.

Remarque : les sessions ou transactions de longue durée affectent également l’opération VACUUM visant à récupérer de l’espace disque et entraînent une augmentation du nombre de lignes fantômes ou de lignes non validées. Les lignes fantômes analysées par les requêtes peuvent affecter les performances des requêtes.

Pour plus d’informations, consultez Comment puis-je détecter et désactiver les verrous dans Amazon Redshift ?

Vérifier votre configuration WLM

En fonction de votre configuration WLM, une requête peut commencer à s’exécuter immédiatement ou pendant un certain temps. Réduisez au strict minimum la durée pendant laquelle une requête est mise en file d’attente pour être exécutée. Pour définir vos files d’attente, vérifiez votre allocation de mémoire WLM.

Pour vérifier les files d’attente WLM d’un cluster pendant quelques jours, exécutez la requête suivante :

SELECT *, pct_compile_time + pct_wlm_queue_time + pct_exec_only_time + pct_commit_queue_time + pct_commit_time AS total_pcntFROM
(SELECT IQ.*,
   ((IQ.total_compile_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) AS pct_compile_time,
   ((IQ.wlm_queue_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) AS pct_wlm_queue_time,
   ((IQ.exec_only_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) AS pct_exec_only_time,
   ((IQ.commit_queue_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) pct_commit_queue_time,
   ((IQ.commit_time*1.0 / IQ.wlm_start_commit_time)*100)::DECIMAL(5,2) pct_commit_time  
FROM
     (SELECT trunc(d.service_class_start_time) AS DAY,
       d.service_class,
       d.node,
       COUNT(DISTINCT d.xid) AS count_all_xid,
       COUNT(DISTINCT d.xid) -COUNT(DISTINCT c.xid) AS count_readonly_xid,
       COUNT(DISTINCT c.xid) AS count_commit_xid,
       SUM(compile_us) AS total_compile_time,
       SUM(datediff (us,CASE WHEN d.service_class_start_time > compile_start THEN compile_start ELSE d.service_class_start_time END,d.queue_end_time)) AS wlm_queue_time,
       SUM(datediff (us,d.queue_end_time,d.service_class_end_time) - compile_us) AS exec_only_time,
       nvl(SUM(datediff (us,CASE WHEN node > -1 THEN c.startwork ELSE c.startqueue END,c.startwork)),0) commit_queue_time,
       nvl(SUM(datediff (us,c.startwork,c.endtime)),0) commit_time,
       SUM(datediff (us,CASE WHEN d.service_class_start_time > compile_start THEN compile_start ELSE d.service_class_start_time END,d.service_class_end_time) + CASE WHEN c.endtime IS NULL THEN 0 ELSE (datediff (us,CASE WHEN node > -1 THEN c.startwork ELSE c.startqueue END,c.endtime)) END) AS wlm_start_commit_time     
FROM
        (SELECT node, b.*
          FROM (SELECT -1 AS node UNION SELECT node FROM stv_slices) a,
               stl_wlm_query b
         WHERE queue_end_time > '2005-01-01'
           AND exec_start_time > '2005-01-01') d
     LEFT JOIN stl_commit_stats c USING (xid,node)
     JOIN (SELECT query, MIN(starttime) AS compile_start, SUM(datediff (us,starttime,endtime)) AS compile_us
           FROM svl_compile
           GROUP BY 1) e USING (query)
    WHERE d.xid > 0
      AND d.service_class > 4
      AND d.final_state <> 'Evicted'
 GROUP BY trunc(d.service_class_start_time),
          d.service_class,
          d.node
 ORDER BY trunc(d.service_class_start_time),
          d.service_class,
          d.node) IQ)
WHERE node < 0 ORDER BY 1,2,3;

Cette requête fournit le nombre total de transactions ou xid, l’exécution, la durée de la file d’attente et les détails de la file d’attente de validation. Vérifiez les détails de la file de validation pour voir si des validations fréquentes ont une incidence sur les performances de la charge de travail.

Pour vérifier les détails des requêtes en cours d’exécution à un moment donné, exécutez la requête suivante :

select b.userid,b.query,b.service_class,b.slot_count,b.xid,d.pid,d.aborted,a.compile_start,b.service_class_start_time,b.queue_end_time,b.service_class_end_time,c.startqueue as commit_startqueue,c.startwork as commit_startwork,c.endtime as commit_endtime,a.total_compile_time_s,datediff(s,b.service_class_start_time,b.queue_end_time)    as wlm_queue_time_s,datediff(s,b.queue_end_time,b.service_class_end_time) as wlm_exec_time_s,datediff(s, c.startqueue, c.startwork) commit_queue_s,datediff(s, c.startwork, c.endtime) commit_time_s,undo_time_s,numtables_undone,datediff(s,a.compile_start,nvl(c.endtime,b.service_class_end_time))
    total_query_s ,substring(d.querytxt,1,50) as querytext from (select query,min(starttime) as compile_start,max(endtime) as compile_end,sum(datediff(s,starttime,endtime)) as total_compile_time_s from svl_compile group by query) a left join stl_wlm_query
    b using (query) left join (select * from stl_commit_stats where node=-1) c using (xid) left join stl_query d using(query) left join (select xact_id_undone as xid,datediff(s,min(undo_start_ts),max(undo_end_ts)) as undo_time_s,count(distinct table_id)
    numtables_undone from stl_undone group by 1) e on b.xid=e.xid
WHERE '2011-12-20 13:45:00' between compile_start and service_class_end_time;

Remarque : remplacez 2011-12-20 13:45:00 par l’heure et la date spécifiques que vous souhaitez vérifier pour les requêtes en file d’attente et terminées.

Passer en revue les performances matérielles de votre nœud de cluster

Si un nœud a été remplacé pendant une fenêtre de maintenance du cluster, il est possible que ce cluster soit bientôt disponible. Néanmoins, la restauration des données sur le nœud remplacé peut prendre un certain temps. Lors de ce processus, les performances de votre cluster peuvent décliner.

Pour identifier les événements qui ont affecté les performances de votre cluster, consultez les événements de votre cluster Amazon Redshift.

Pour surveiller le processus de restauration des données, utilisez la table STV_UNDERREPPED_BLOCKS. Exécutez la requête suivante pour récupérer les blocs qui requièrent une restauration des données :

SELECT COUNT(1) FROM STV_UNDERREPPED_BLOCKS;

Remarque : la durée du processus de restauration des données est fonction de la charge de travail du cluster. Pour mesurer la progression du processus de restauration des données de votre cluster, vérifiez les blocs à intervalles réguliers.

Pour vérifier l’état d’un nœud spécifique, exécutez la requête suivante pour comparer ses performances à celles d’autres nœuds :

SELECT day  , node
  , elapsed_time_s
  , sum_rows
  , kb
  , kb_s
  , rank() over (partition by day order by kb_s) AS rank
FROM (
  SELECT DATE_TRUNC('day',start_time) AS day
    , node
    , sum(elapsed_time)/1000000 AS elapsed_time_s
    , sum(rows) AS sum_rows
    , sum(bytes)/1024 AS kb
    , (sum(bytes)/1024)/(sum(elapsed_time)/1000000) AS "kb_s"
  FROM svl_query_report r
    , stv_slices AS s
   WHERE r.slice = s.slice
     AND elapsed_time > 1000000
   GROUP BY day
    , node
   ORDER BY day
    , node
);

**Exemple de sortie de requête : **

day    node    elapsed_time_s    sum_rows         kb         kb_s  rank...
4/8/20     0      3390446     686216350489    21570133592    6362    4
4/8/20     2      3842928     729467918084    23701127411    6167    3
4/8/20     3      3178239     706508591176    22022404234    6929    7
4/8/20     5      3805884     834457007483    27278553088    7167    9
4/8/20     7      6242661     433353786914    19429840046    3112    1
4/8/20     8      3376325     761021567190    23802582380    7049    8

Remarque : la sortie précédente montre que le nœud 7 a traité 19 429 840 046 Ko de données pendant 6 242 661 secondes. C’est beaucoup plus lent que les autres nœuds.

Le rapport entre le nombre de lignes de la colonne sum_rows et le nombre d’octets traités dans la colonne kb est à peu près le même. Selon les performances de votre matériel, le nombre de lignes de la colonne kb_s est également à peu près le même que le nombre de lignes de la colonne sum_rows. Si un nœud traite moins de données sur une période donnée, un problème matériel sous-jacent peut en être la cause. Pour vérifier s’il existe un problème matériel sous-jacent, consultez le graphique des performances du nœud.