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

Kurzbeschreibung

Wenn Sie Leistungsprobleme in Ihrem Amazon-Redshift-Cluster feststellen, ergreifen Sie folgende Maßnahmen:

• Überwachen Sie die Leistungsmetriken des Clusters.
• Lesen Sie die Empfehlungen von Amazon Redshift Advisor.
• Überprüfen Sie die Warnungen zur Abfrageausführung und vergewissern Sie sich, dass keine übermäßige Datenträgerauslastung vorliegt.
• Suchen Sie nach Problemen mit Sperren und lang andauernden Sitzungen oder Transaktionen.
• Überprüfen Sie Ihre Workload Management (WLM)-Konfiguration.
• Überprüfen Sie die Wartung und Leistung der Hardware Ihres Clusterknotens.

Lösung

Überwachen der Leistungsmetriken Ihres Clusters

Überprüfen Sie die Leistungsmetriken und -diagramme des Cluster, um die Hauptursache für den Leistungsrückgang zu finden. Rufen Sie 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 Ihrem Amazon-Redshift-Cluster hinweisen. Weitere Informationen finden Sie unter Monitoring Amazon Redshift using CloudWatch metrics.

Verwenden Sie die Aufgliederung der Workload-Ausführung in der Amazon-Redshift-Konsole, um bestimmte Abfragen und Laufzeiten zu überprüfen. Wenn Sie beispielsweise feststellen, dass die Abfrageplanung länger dauert, wartet eine Abfrage möglicherweise auf eine Sperre.

Überprüfen der Empfehlungen von Amazon Redshift Advisor

Verwenden Sie die Empfehlungen von Amazon Redshift Advisor, um mehr über Verbesserungspotenziale für Ihren 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 eine langsame oder ineffiziente Abfrage auftritt, überprüfen Sie die Einträge in STL_ALERT_EVENT_LOG. Verwenden Sie 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 finden Sie 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

Verwenden Sie die Diagnoseabfragen für die Abfrageoptimierung, um die Abfrageleistung zu überprüfen. Vergewissern Sie sich, dass die 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, sollten Sie versuchen, verschachtelte Schleifen zu vermeiden.

Identifizieren Sie die Abfragen, die die verschachtelten Schleifen ausführen, um das Problem zu diagnostizieren. Weitere Informationen finden Sie unter Wie kann ich Probleme mit hoher oder voller Festplattenauslastung mit Amazon Redshift beheben?

Suchen nach Problemen mit Sperren und lange andauernden Sitzungen oder Transaktionen

Bevor Sie eine Abfrage auf dem Cluster ausführen, 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 kommt zu einem Anstieg der Abfragelaufzeit. Wenn Sie eine Spitze in Ihrer Abfragelaufzeit feststellen, könnte eine Sperre die Ursache sein. Weitere Informationen finden Sie unter Warum ist meine Zeit für die Planung von Abfragen in Amazon Redshift so hoch?

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

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

• Verwenden Sie die Tabellen STL_SESSIONS und SVV_TRANSACTIONS, um nach lange andauernden Sitzungen und Transaktionen zu suchen und diese zu beenden.
• Gestalten Sie Ihre Abfragen so, dass Amazon Redshift sie schnell und effizient verarbeiten kann.

Hinweis: Lange andauernde Sitzungen oder Transaktionen wirken sich auch auf den VACUUM-Vorgang zur Rückgewinnung von Speicherplatz aus 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 finden Sie unter Wie kann ich Sperren in Amazon Redshift erkennen und freigeben?

Überprüfen der WLM-Konfiguration

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

Verwenden Sie 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_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;

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

Verwenden Sie 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: Ersetzen Sie 2011-12-20 13:45:00 durch die genaue Uhrzeit und das Datum des Zeitpunkts, den Sie auf Abfragen in der Warteschlange und abgeschlossene Abfragen überprüfen möchten.

Überprüfen der Hardwareleistung des Clusterknotens

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 Ihre Cluster-Leistung ausgewirkt haben, überprüfen Sie die Ereignisse Ihres Amazon-Redshift-Clusters.

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

SELECT COUNT(1) FROM STV_UNDERREPPED_BLOCKS;

Hinweis: Die Dauer des Wiederherstellungsprozesses hängt vom Workload des Clusters ab. Um den Fortschritt des Datenwiederherstellungsprozesses Ihres Clusters zu messen, überprüfen Sie die Blöcke in bestimmten Intervallen.

Um den Zustand eines bestimmten Knotens zu überprüfen, vergleichen Sie 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 obige Ausgabe zeigt, dass Knoten 7 für 6 242 661 Sekunden 19 429 840 046 KB an Daten 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 Ihrer 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üfen Sie das Leistungsdiagramm des Knotens.