Wie behebe ich Probleme bei der Cluster- oder Abfrageleistung in Amazon Redshift?

Kurzbeschreibung

Wenn du Leistungsprobleme in deinem Amazon-Redshift-Cluster feststellst, ergreife folgende Maßnahmen:

• Überwache die Leistungsmetriken des Clusters.
• Lies die Empfehlungen von Amazon Redshift Advisor.
• Überprüfe die Warnungen zur Abfrageausführung und vergewissere dich, dass keine übermäßige Datenträgerauslastung vorliegt.
• Suche nach Problemen mit Sperren und lang andauernden Sitzungen oder Transaktionen.
• Überprüfe deine Workload Management (WLM)-Konfiguration.
• Überprüfe die Wartung und Leistung der Hardware deines Clusterknotens.

Lösung

Überwachen der Leistungsmetriken deines Clusters

Überprüfe die Leistungsmetriken und -diagramme des Clusters, um die Hauptursache für deinen Leistungsrückgang zu finden. Rufe Leistungsdaten in der Amazon-Redshift-Konsole ab, um die Cluster-Leistung im Zeitverlauf zu sehen.

Ein Anstieg dieser Metriken kann auf eine höhere Arbeitslast und Ressourcenknappheit in deinem Amazon-Redshift-Cluster hinweisen. Weitere Informationen findest du unter Leistungsdaten in Amazon Redshift.

Überprüfe die Aufschlüsselung der Workload-Ausführung in der Amazon Redshift-Konsole, um bestimmte Abfragen und Laufzeiten zu überprüfen. Wenn du beispielsweise feststellst, dass die Abfrageplanung länger dauert, wartet eine Abfrage möglicherweise auf eine Sperre.

Überprüfen der Empfehlungen von Amazon Redshift Advisor

Verwende die Empfehlungen von Amazon Redshift Advisor, um mehr über Verbesserungspotenziale für deinen Cluster zu erfahren. Die Empfehlungen basieren auf gängigen Nutzungsmustern und den bewährten Methoden bei Amazon Redshift.

Überprüfen der Warnungen zur Abfrageausführung und auf übermäßige Datenträgerauslastung

Wenn eine Abfrage ausgeführt wird, registriert Amazon Redshift die Abfrageleistung und zeigt an, ob die Abfrage effizient ausgeführt wird. Wenn die Abfrage als ineffizient identifiziert wird, speichert Amazon Redshift die Abfrage-ID und generiert Empfehlungen zur Verbesserung der Abfrageleistung. Diese Empfehlungen werden in der internen Systemtabelle STL_ALERT_EVENT_LOG protokolliert.

Wenn du eine langsame oder ineffiziente Abfrage feststellst, überprüfe die STL_ALERT_EVENT_LOG-Einträge. Verwende die folgende Abfrage, um Informationen aus der Tabelle STL_ALERT_EVENT_LOG abzurufen:

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;

Diese Abfrage listet Abfrage-IDs, die häufigsten Probleme sowie tatsächlich aufgetretene Probleme bei der Abfrage auf, die auf dem Cluster ausgeführt wird.

Im Folgenden findest du eine Beispielausgabe der Abfrage mit Informationen, die beschreiben, warum die Warnung ausgelöst wurde:

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

Um die Abfrageleistung zu überprüfen, sieh dir die Diagnoseabfragen zur Abfrageoptimierung an. Vergewissere dich, dass deine Abfrageoperationen für eine effiziente Ausführung eingerichtet sind. Beispielsweise sind nicht alle Verknüpfungsoperationen effektiv. Eine verschachtelte Schleifenverknüpfung ist der am wenigsten effektive Verknüpfungstyp. Da verschachtelte Schleifenverknüpfungen die Abfragelaufzeit erheblich erhöhen, solltest du versuchen, verschachtelte Schleifen zu vermeiden.

Um dir bei der Diagnose des Problems zu helfen, identifiziere die Abfragen, die die verschachtelten Schleifen ausführen. Weitere Informationen findest du unter Wie behebe ich Probleme mit hoher oder vollständiger Festplattenauslastung bei Amazon Redshift?

Suchen nach Problemen mit Sperren und lange andauernden Sitzungen oder Transaktionen

Bevor du eine Abfrage auf dem Cluster ausführst, erhält Amazon Redshift möglicherweise Sperren auf Tabellenebene für die Tabellen, die an Abfrageausführungen beteiligt sind. Manchmal scheinen Abfragen nicht zu antworten, oder es gibt eine Spitze in der Abfragelaufzeit. Wenn du eine Spitze in deiner Abfragelaufzeit feststellst, könnte eine Sperre die Ursache sein. Weitere Informationen findest du unter Warum ist meine Zeit für die Planung von Abfragen in Amazon Redshift so hoch?

Wenn deine Tabelle derzeit durch einen anderen Prozess oder eine andere Abfrage gesperrt ist, kann deine Abfrage nicht ausgeführt werden. Infolgedessen wird deine Abfrage nicht in der STV_INFLIGHT-Tabelle angezeigt. Stattdessen wird deine laufende Abfrage in der Tabelle STV_RECENTS angezeigt.

Manchmal kann eine lange andauernde Transaktion dazu führen, dass eine Abfrage nicht mehr reagiert. Ergreife die folgenden Maßnahmen, um zu verhindern, dass lange andauernde Sitzungen oder Transaktionen deine Abfrageleistung beeinträchtigen:

• Verwende die STL_SESSIONS- und SVV_TRANSACTIONS-Tabellen, um nach lang andauernden Sitzungen und Transaktionen zu suchen und sie dann zu beenden.
• Gestalte deine Abfragen so, dass Amazon Redshift sie schnell und effizient verarbeiten kann.

Hinweis: Lange andauernde Sitzungen oder Transaktionen beeinträchtigen auch den VACUUM-Vorgang zur Freigabe von Speicherplatz und führen zu einer höheren Anzahl von Ghost-Zeilen oder nicht festgeschriebenen Zeilen. Ghost-Zeilen, die von Abfragen gescannt werden, können die Abfrageleistung beeinträchtigen.

Weitere Informationen findest du unter Wie kann ich Sperren in Amazon Redshift erkennen und freigeben?

Überprüfen der WLM-Konfiguration

Abhängig von deiner WLM-Konfiguration kann eine Abfrage sofort ausgeführt werden oder einige Zeit in der Warteschlange stehen. Minimiere die Dauer, für die eine Abfrage in der Warteschlange steht, bevor sie ausgeführt wird. Um deine Warteschlangen zu definieren, überprüfe deine WLM-Speicherzuweisung.

Verwende die folgende Abfrage, um die WLM-Warteschlangen eines Clusters über einige Tage zu überprüfen:

SELECT \*, pct\_compile\_time + pct\_wlm\_queue\_time + pct\_exec\_only\_time + pct\_commit\_queue\_time + pct\_commit\_time AS total\_pcnt FROM   
(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;

Diese Abfrage enthält die Gesamtzahl der Transaktionen (xid), die Laufzeit, die Zeit in der Warteschlange und Details zur Commit-Warteschlange. Überprüfe die Details der Commit-Warteschlange, um festzustellen, ob sich häufige Commits auf die Workload-Leistung auswirken.

Verwende die folgende Abfrage, um die Details von Abfragen zu überprüfen, die zu einem bestimmten Zeitpunkt ausgeführt werden:

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;

Hinweis: Ersetze 2011-12-20 13:45:00 durch die bestimmte Uhrzeit und das Datum, zu denen du nach in die Warteschlange gestellten und abgeschlossenen Abfragen suchen möchtest.

Überprüfen der Hardwareleistung des Clusterknotens

Hinweis: Die folgenden Informationen gelten für DC2- und DS2-Knotentypen.

Wenn ein Knoten während eines Cluster-Wartungsfensters ausgetauscht wurde, ist der Cluster möglicherweise in Kürze verfügbar. Es kann jedoch einige Zeit dauern, bis die Daten auf dem ersetzten Knoten wiederhergestellt sind. Während dieses Vorgangs kann die Cluster-Leistung abnehmen.

Um die Ereignisse zu identifizieren, die sich auf deine Cluster-Leistung ausgewirkt haben, überprüfe deine Amazon-Redshift-Cluster-Ereignisse.

Verwende die Tabelle STV_UNDERREPPED_BLOCKS, um die Datenwiederherstellung zu überwachen. Führe die folgende Abfrage aus, um die Blöcke abzurufen, die eine Datenwiederherstellung erfordern:

SELECT COUNT(1) FROM STV_UNDERREPPED_BLOCKS;

Hinweis: Die Dauer des Datenwiederherstellungsprozesses hängt von der Cluster-Workload ab. Um den Fortschritt des Datenwiederherstellungsprozesses deines Clusters zu messen, überprüfe die Blöcke in bestimmten Intervallen.

Um den Zustand eines bestimmten Knotens zu überprüfen, vergleiche seine Leistung anhand folgender Abfrage mit derjenigen anderer Knoten:

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
);

Beispiel für eine Abfrageausgabe:

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

Hinweis: Die vorherige Ausgabe zeigt, dass Knoten 7 19429840046 KB an Daten für 6242661 Sekunden verarbeitet hat. Damit ist dieser Knoten deutlich langsamer als die anderen.

Das Verhältnis zwischen der Anzahl der Zeilen in der Spalte sum_rows und der Anzahl der verarbeiteten Byte in der Spalte kb ist ungefähr gleich. Abhängig von deiner Hardwareleistung entspricht die Anzahl der Zeilen in der Spalte kb_s ebenfalls in etwa der Anzahl der Zeilen in der Spalte sum_rows. Wenn ein Knoten über einen bestimmten Zeitraum weniger Daten verarbeitet, liegt möglicherweise ein Hardwareproblem vor. Um zu überprüfen, ob ein Hardwareproblem vorliegt, überprüfe das Leistungsdiagramm des Knotens.