Wie behebe ich Fehler mit der Cluster- oder Abfrageleistung in Amazon Redshift?

Kurzbeschreibung

Wenn Sie Leistungsprobleme in Ihrem Amazon Redshift-Cluster haben, sollten Sie die folgenden Ansätze in Betracht ziehen:

• Überwachen Sie Ihre Cluster-Leistungskennzahlen.
• Lesen Sie die Empfehlungen von Amazon Redshift Advisor.
• Überprüfen Sie die Warnungen zur Abfrageausführung und die übermäßige Festplattenauslastung.
• Suchen Sie nach Sperrproblemen 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 Sie Ihre Cluster-Leistungskennzahlen

Wenn Sie Leistungsprobleme mit Ihrem Amazon Redshift-Cluster feststellen, überprüfen Sie Ihre Cluster-Leistungskennzahlen und -diagramme. Mithilfe der Cluster-Leistungskennzahlen und -diagramme können Sie die mögliche Ursache für Ihre Leistungsverschlechterung eingrenzen. Sie können Leistungsdaten in der Amazon Redshift-Konsole anzeigen, um die Cluster-Leistung im Laufe der Zeit zu vergleichen.

Ein Anstieg dieser Kennzahlen kann auf eine höhere Arbeitslast und Ressourcenknappheit in Ihrem Amazon Redshift-Cluster hinweisen. Weitere Informationen zur Überwachung von Leistungskennzahlen finden Sie unter Überwachen von Amazon Redshift mithilfe von Amazon CloudWatch-Kennzahlen.

Sehen Sie sich die Aufschlüsselung der Workload-Ausführung in der Amazon Redshift-Konsole an, um bestimmte Abfragen und Ausführungszeiten zu überprüfen. Wenn Sie beispielsweise eine Verlängerung der Abfrageplanungszeit feststellen, kann dies ein Hinweis darauf sein, dass eine Abfrage auf eine Sperre wartet.

Lesen Sie die Empfehlungen von Amazon Redshift Advisor

Der Amazon Redshift Advisor bietet Empfehlungen, wie Sie die Leistung Ihres Amazon Redshift-Clusters verbessern und optimieren können. Amazon Redshift Advisor steht Ihnen in der Amazon Redshift-Konsole kostenlos zur Verfügung. Verwenden Sie die Empfehlungen von Amazon Redshift Advisor, um mehr über mögliche Verbesserungsbereiche für Ihren Cluster zu erfahren. Die Empfehlungen basieren auf gängigen Nutzungsmustern und den bewährten Methoden von Amazon Redshift.

Überprüfen Sie die Warnungen zur Abfrageausführung und die übermäßige Festplattenauslastung

Während der Abfrageausführung notiert Amazon Redshift die Abfrageleistung und gibt an, ob die Abfrage effizient ausgeführt wird. Wenn die Abfrage als ineffizient identifiziert wird, notiert Amazon Redshift die Abfrage-ID und gibt Empfehlungen zur Verbesserung der Abfrageleistung. Diese Empfehlungen werden in STL\ _ALERT\ _EVENT\ _LOG, einer internen Systemtabelle, protokolliert.

Wenn Sie eine langsame oder ineffiziente Abfrage beobachten, überprüfen Sie die STL\ _ALERT\ _EVENT\ _LOG -Einträge. Verwenden Sie die folgende Abfrage, um Informationen aus der STL\ _ALERT\ _EVENT_LOG -Tabelle 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 und die häufigsten Probleme und Probleme bei der auf dem Cluster ausgeführten Abfrage auf.

Hier finden Sie ein Beispiel für die Ausgabe der Abfrage und die Informationen, die beschreiben, warum Ihre 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

Überprüfen Sie die Abfrageleistung, indem Sie die Diagnoseabfragen auf die Abfrageoptimierung überprüfen. Stellen Sie sicher, dass Ihre Abfrageoperationen so konzipiert sind, dass sie effizient ausgeführt werden. Beispielsweise sind nicht alle Join-Operationen wirksam. Ein verschachtelter Schleifenverknüpfung ist der am wenigsten effektive Verknüpfungstyp und muss nach Möglichkeit vermieden werden, da dieser Typ die Abfrageausführungszeit erheblich verlängert.

Identifizieren Sie die Abfragen, die die verschachtelten Schleifen ausführen, um das Problem zu diagnostizieren. Weitere Informationen zur Diagnose häufiger Probleme mit der Festplattenauslastung finden Sie unter Wie kann ich Probleme mit hoher oder vollständiger Festplattenauslastung mit Amazon Redshift beheben?

Suchen Sie nach Sperrproblemen und lang andauernden Sitzungen oder Transaktionen

Bevor eine Abfrage im Cluster ausgeführt wird, müssen möglicherweise Sperren auf Tabellenebene für die Tabellen abgerufen werden, die an der Abfrageausführung beteiligt sind. Es kann vorkommen, dass Abfragen als „hängend“ erscheinen oder dass die Ausführungszeit der Abfrage stark ansteigt. Wenn Sie einen Anstieg der Ausführungszeit Ihrer Abfrage beobachten, könnte ein Sperrproblem die Ursache sein. Weitere Informationen zu einer verzögerten Abfrageausführungszeit finden Sie unter Warum ist meine Abfrageplanungszeit in Amazon Redshift so hoch?

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

Manchmal wird eine hängende Abfrage durch eine lang andauernde Transaktion verursacht. Beachten Sie die folgenden Tipps, um zu verhindern, dass sich Transaktionen mit langer Laufzeit auf die Abfrageleistung auswirken:

• Identifizieren Sie die Sitzungen mit langer Laufzeit und beenden Sie sie sofort. Sie können die Tabellen STL\ _SESSIONS und SVV\ _TRANSACTIONS verwenden, um nach Transaktionen mit langer Laufzeit zu suchen.
• Gestalten Sie Ihre Abfragen so, dass Amazon Redshift sie schnell und effizient verarbeiten kann.

Hinweis: Transaktionen mit langer Laufzeit wirken sich auch auf die Fähigkeit von VACUUM aus, Speicherplatz zurückzugewinnen, was zu einer höheren Anzahl von Ghost-Zeilen oder unbestätigten Zeilen führt. Ghost-Zeilen, die durch Abfragen gescannt werden, können die Abfrageleistung beeinträchtigen.

Weitere Informationen zur Identifizierung von Sitzungen mit langer Laufzeit, die zu Tabellensperren führen können, finden Sie unter Wie kann ich Sperren in Amazon Redshift erkennen und freigeben?

Überprüfen Sie Ihre Workload Management (WLM)-Konfiguration

Abhängig von Ihrer WLM-Konfiguration kann es sein, dass eine Abfrage sofort ausgeführt wird oder einige Zeit in der Warteschlange steht. Das Ziel sollte immer darin bestehen, die Zeit zu minimieren, in der eine Abfrage zur Ausführung in die Warteschlange gestellt wird. Wenn Sie Ihre Warteschlangen definieren möchten, ü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_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 Ausführungszeit, die Zeit in der Warteschlange und Details zur Commit-Warteschlange. Sie können die Details der Commit-Warteschlange überprüfen, 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;

Ersetzen Sie „2011-12-20 13:45:00" durch die genaue Uhrzeit und das Datum, die Sie auf Abfragen in der Warteschlange und abgeschlossene Abfragen überprüfen möchten.

Überprüfen der Hardwareleistung des Clusterknotens

Während Ihres Cluster-Wartungsfensters können Wartungsaufgaben wie Patches, interne Konfigurationsänderungen und der Austausch von Knoten durchgeführt werden. Wenn ein Knoten während des 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. Dieser Vorgang wird als Hydratation bezeichnet. Während des Hydratationsprozesses kann die Cluster-Leistung abnehmen.

Um herauszufinden, welche Ereignisse (wie Hydratation) Ihre Clusterleistung beeinträchtigt haben, überprüfen Sie die Amazon Redshift-Clusterereignisse. Ihre Clusterereignisse informieren Sie über alle Aktionen zum Ersetzen von Knoten und/oder über alle anderen Clusteraktionen, die ausgeführt werden.

Verwenden Sie die Tabelle STV\ _UNDERREPPED\ _BLOCKS, um den Hydratationsprozess zu überwachen. Die Blöcke, die eine Hydratation benötigen, können mit der folgenden Abfrage abgerufen werden:

SELECT COUNT(1) FROM STV_UNDERREPPED_BLOCKS;

Hinweis: Die Dauer des Hydratationsprozesses hängt von der Cluster-Arbeitslast ab. Um den Fortschritt des Hydratationsprozesses Ihres Clusters zu messen, überprüfen Sie die Blöcke in bestimmten Intervallen.

Um den Zustand eines bestimmten Knotens zu überprüfen, verwenden Sie die folgende Abfrage, um seine Leistung mit der anderer Knoten zu vergleichen:

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

Hier ist ein 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
...This output indicates that the node 7 processed 19429840046 Kb of data for 6242661 amount of seconds, which is a lot slower than the other nodes.

Das Verhältnis zwischen der Anzahl der Zeilen (Spalte „sum\ _rows“) und der Anzahl der verarbeiteten Bytes (Spalte „kb“) ist ungefähr gleich. Die Anzahl der Zeilen in der Spalte „kb\ _s“ entspricht ebenfalls in etwa der Anzahl der Zeilen, abhängig von Ihrer Hardwareleistung. Wenn Sie beobachten, dass ein bestimmter Knoten über einen bestimmten Zeitraum weniger Daten verarbeitet, kann diese geringe Leistung auf ein zugrunde liegendes Hardwareproblem hinweisen. Um zu überprüfen, ob ein zugrunde liegendes Hardwareproblem vorliegt, überprüfen Sie das Leistungsdiagramm des Knotens.

---