Wie behebe ich Probleme mit hoher CPU-Auslastung in Amazon Redshift?

Kurzbeschreibung

Amazon Redshift ist so konzipiert, dass es bei der Ausführung von Abfragen alle verfügbaren Ressourcen nutzt. Das bedeutet, dass Sie mit Spitzen bei der CPU-Auslastung in Ihrem Redshift-Cluster rechnen können. Eine Erhöhung der CPU-Auslastung kann von Faktoren wie dem Cluster-Workload, verzerrten und unsortierten Daten oder Aufgaben des Leader-Knotens abhängen.

Wenn sich Ihre CPU-Auslastung jedoch auf Ihre Abfragezeit auswirkt, sollten Sie die folgenden Ansätze in Betracht ziehen:

• Überprüfen Sie Ihren Redshift-Cluster-Workload.
• Sorgen Sie für Ihre Datenhygiene.
• Aktualisieren Sie Ihr Tabellendesign.
• Suchen Sie nach Wartungsupdates.
• Suchen Sie nach Spitzen bei der CPU-Auslastung Ihres Leader-Knotens.
• Verwenden Sie Amazon CloudWatch, um Spitzen bei der CPU-Auslastung zu überwachen.

Lösung

Überprüfen Sie Ihren Redshift-Cluster-Workload

Die folgenden Faktoren können sich auf die CPU-Auslastung in Ihrem Redshift-Cluster auswirken:

• Ein erhöhter Workload (da mehr Abfragen ausgeführt werden). Der Anstieg des Workloads erhöht die Anzahl der Datenbankverbindungen, was zu einer höheren Parallelität von Abfragen führt.
• Die höhere Anzahl gleichzeitiger Abfragen wirkt sich auf Ressourcenkonflikte, Sperrwartezeiten und Wartezeiten für Workload Management (WLM) -Warteschlangen aus.
• Mehr Datenbankverbindungen. Dies kann auf inaktive Sitzungen im Cluster zurückzuführen sein. Inaktive Sitzungen können zu zusätzlichen Sperrkonflikten führen.

Rufen Sie die Sperrinformationen ab, während die Abfragen ausgeführt werden. Verwenden Sie die folgende SQL-Abfrage, um Sitzungen mit langer Laufzeit zu identifizieren:

select *,datediff(s,txn_start,getdate())/86400||' days '||datediff(s,txn_start,getdate())%86400/3600||' hrs '||datediff(s,txn_start,getdate())%3600/60||' mins '||datediff(s,txn_start,getdate())%60||' secs' as "duration"
from svv_transactions where lockable_object_type='transactionid' and pid<>pg_backend_pid() order by 3;<br>

Führen Sie dann PG\ _TERMINATE\ _BACKEND aus, um alle Transaktionen mit langer Laufzeit zu stoppen. Um zu verhindern, dass diese Sitzungen geöffnet bleiben, stellen Sie sicher, dass alle Transaktionen geschlossen sind. Stellen Sie beispielsweise sicher, dass alle Transaktionen, die mit einer BEGIN -Anweisung beginnen, von einer END - oder COMMIT -Anweisung begleitet werden.

Führen Sie dann die folgende SQL-Abfrage aus, um Abfragen zu identifizieren, die viel CPU verbrauchen:

select stq.userid, stq.query, trim(stq.label) as label, stq.xid, stq.pid, svq.service_class,
query_cpu_usage_percent as "cpu_%",starttime, endtime, datediff(s,starttime, endtime) as duration_s,
substring(stq.querytxt,1,100) as querytext from stl_query stq
join svl_query_metrics svq on stq.query=svq.query
where query_cpu_usage_percent is not null and starttime > sysdate - 1
order by query_cpu_usage_percent desc;

Führen Sie die folgende Abfrage aus, um die Ausführungsschritte auf Segment- und Slice-Ebene für jede Abfrage zu analysieren:

select query, segment, step, label ,is_rrscan as rrS, is_diskbased as disk, is_delayed_scan as DelayS, min(start_time) as starttime, max(end_time) as endtime, datediff(ms, min(start_time), max(end_time)) as "elapsed_msecs", sum(rows) as row_s , sum(rows_pre_filter) as rows_pf, CASE WHEN sum(rows_pre_filter) = 0 THEN 100 ELSE sum(rows)::float/sum(rows_pre_filter)::float*100 END as pct_filter, SUM(workmem)/1024/1024 as "Memory(MB)", SUM(bytes)/1024/1024 as "MB_produced" from svl_query_report where query in (<query_ids>) group by query, segment, step, label , is_rrscan, is_diskbased , is_delayed_scan order by query, segment, step, label;

Weitere Informationen zur Optimierung dieser Abfragen finden Sie unter Die 10 besten Techniken zur Leistungsoptimierung für Amazon Redshift.

Sie können auch die Ansicht wlm\ _query\ _trend\ _hourly verwenden, um das Redshift-Cluster-Workload-Muster zu überprüfen. Finden Sie dann heraus, mit welchen der folgenden Methoden Sie die Wartezeit in der Warteschlange verkürzen können:

• Reduzieren Sie die Parallelität von Abfragen pro Warteschlange, um mehr Speicher für jeden Abfrageslot bereitzustellen. Durch diese Reduzierung können Abfragen, die mehr Speicher benötigen, effizienter ausgeführt werden.
• Aktivieren Sie Short Query Acceleration (SQA), um Abfragen mit kurzer Laufzeit gegenüber Abfragen mit langer Laufzeit zu priorisieren.
• Skalieren Sie den Redshift-Cluster, um dem erhöhten Workload gerecht zu werden. Die Skalierung eines Clusters bietet mehr Speicher und Rechenleistung, wodurch Abfragen schneller ausgeführt werden können. Weitere Informationen finden Sie unter Wie ändere ich die Größe eines Redshift-Clusters?

Sorgen Sie für Ihre Datenhygiene

Datenhygiene wird anhand des Prozentsatzes veralteter Statistiken und unsortierter Zeilen in einer Tabelle gemessen. Ein hoher Prozentsatz von beidem kann dazu führen, dass der Abfrageoptimierer einen Ausführungsplan generiert, bei dem Abfragen beim Verweisen auf Tabellen ineffizient ausgeführt werden. Unsortierte Daten können dazu führen, dass Abfragen unnötige Datenblöcke scannen, was zusätzliche I/O-Operationen erfordert. Eine schlecht funktionierende Abfrage wirkt sich negativ auf die CPU-Auslastung Ihres Redshift-Clusters aus.

Verwenden Sie die SVV\ _TABLE\ _INFO -Systemansicht, um stats_off - und unsorted -Prozentangaben für eine Tabelle abzurufen. Diese Prozentsätze sollten nahe 0 bleiben. Wenn die Prozentsätze hoch sind, führen Sie das Analyze & Vacuum Schema Utility aus dem GitHub-Repository der AWS-Übungen aus, um Ihre Tabellen zu aktualisieren.

Aktualisieren Sie Ihr Tabellendesign

Das Tabellendesign wird durch die angegebenen Sortierschlüssel, den Verteilungsstil und den Verteilungsschlüssel bestimmt. Der Verteilungsschlüssel und der Verteilungsstil bestimmen, wie Daten auf die Knoten verteilt werden.

Ein ungeeigneter Verteilungsschlüssel oder ein ungeeigneter Verteilungsstil kann zu einer Verteilungsverzerrung zwischen den Knoten führen. Um Verzerrungen bei der Datenverteilung zu reduzieren, wählen Sie den Verteilungsstil und den Sortierschlüssel auf der Grundlage von Abfragemustern und Prädikaten aus. Der Verteilungsschlüssel sollte die Verknüpfungsbedingungen in Ihren Abfragen und Spalten mit hoher Kardinalität unterstützen. Eine korrekte Auswahl des Verteilungsschlüssels kann Abfragen dabei helfen, Zusammenführungsverknüpfungen anstelle von Hash- oder verschachtelten Schleifenverknüpfungen durchzuführen, was sich letztlich auf die Dauer der Ausführung von Abfragen auswirkt.

Verwenden Sie das Skript table\ _inspector.sql, um Tabellen mit schiefer Verteilung zu identifizieren. Verwenden Sie dann das Amazon Redshift Table Design Playbook, um die am besten geeigneten Sortierschlüssel, Verteilungsschlüssel und Verteilungsstile für Ihre Tabelle auszuwählen.

Suchen Sie nach Wartungsupdates

Amazon Redshift speichert kompilierten Code im Cache, sodass Abfragen den Code für zuvor ausgeführte Segmente wiederverwenden können. Der Cache wird dann bei allen Wartungsupdates gelöscht. Daher dauert die Kompilierung von Abfragen, die zum ersten Mal nach einem Patch-Update ausgeführt werden, einige Zeit. Dieser Kompilierungsaufwand kann die CPU-Auslastung eines Redshift-Clusters erhöhen.

Verwenden Sie die folgende SQL-Abfrage, um zu überprüfen, wie viele Segmente pro Stunde kompiliert werden:

select "hour", count(query) total_queries, count(case when is_compiled='Y' then 1 else null end ) as queries_compiled_count, sum(segements_count) total_segments_count, sum(segments_compiled_count) total_segments_compiled_count from
(
  select q.query, date_trunc('h',q.starttime) as "hour", q.starttime, q.endtime, q.aborted, (case when compiled_queries.segments_compiled_count = 0 then 'N' ELSE 'Y' end) is_compiled, compiled_queries.segements_count, compiled_queries.segments_compiled_count
  from stl_query q
  left join (select query, count(segment) segements_count, sum(compile) segments_compiled_count from svl_compile group by query) compiled_queries on q.query = compiled_queries.query
  where q.userid > 1
  and q.starttime > trunc(sysdate) -7
)
group by "hour"
order by "hour";

Suchen Sie nach Spitzen bei der CPU-Auslastung Ihres Leader-Knotens

Aufgaben des Leader-Knotens wie das Analysieren und Optimieren von Abfragen, das Generieren von kompiliertem Code und das Aggregieren von Ergebnissen von Rechenknoten verbrauchen CPU-Ressourcen. Dieser Verbrauch führt zu einer erhöhten CPU-Auslastung der Leader-Knoten. Die CPU-Auslastung des Leader-Knotens kann auch steigen, wenn Abfragen stark auf Systemkatalogtabellen verweisen oder nur Funktionen ausführen, die nur auf dem Leader-Knoten ausgeführt werden.

Wenn der Anstieg der CPU-Auslastung durch einen Leader-Knoten verursacht wird, suchen Sie unter Ereignisse in der Amazon Redshift-Konsole. Überprüfen Sie, ob an Ihrem Redshift-Cluster Wartungsarbeiten stattgefunden haben. Verwenden Sie die unter Nach Wartungsupdates suchen bereitgestellte SQL-Abfrage, um zu überprüfen, ob mehr Segmente als üblich kompiliert werden.

Verwenden Sie CloudWatch, um Spitzen bei der CPU-Auslastung zu überwachen

Verwenden Sie CloudWatch-Metriken, um die Spitzen zwischen CPU-Auslastung und Datenbankverbindungen zu vergleichen. Analysieren Sie die Workload-Leistung, indem Sie das Diagramm mit der Aufschlüsselung der Workload-Ausführung überprüfen. Das Diagramm mit der Aufschlüsselung der Workload-Ausführung zeigt Ihnen, in welchen Phasen die Abfragen am meisten Zeit in Anspruch nehmen.

Verwenden Sie die folgende Abfrage, um die 100 häufigsten Abfragen zu ermitteln, die während eines bestimmten Zeitraums am meisten CPU verbrauchen:

select qms.*, substring(q.querytxt,1,100) qtxt
from svl_query_metrics_summary qms
join stl_query q on q.query=qms.query
where q.starttime > sysdate - 1
and q.userid>1
order by qms.query_cpu_time desc nulls last limit 100;

Verwenden Sie die folgende Abfrage, um eine Liste der Abfragen abzurufen, die die meisten Ressourcen verbrauchen, wenn die CPU 100% erreicht:

select a.userid, service_class, a.query, b.pid, b.xid, a.starttime, slices, max_rows, max_blocks_read, max_blocks_to_disk, max_query_scan_size, segment, round(max_cpu_time/(max_run_time*1.0)*100,2) as max_cpu_pcnt, round(cpu_time/(run_time*1.0)*100,2) as cpu_pcnt, max_cpu_time, max_run_time, case when segment > -1 then 'segment' else 'query' end as metric_lvl, text from pg_catalog.stv_query_metrics a left join stv_inflight b using (query) where step_type=-1 order by query, segment;

Führen Sie die folgende Abfrage aus, um die Datenmenge zu überprüfen, die von jedem Knoten verarbeitet wird:

select iq.day_d, sl.node, sum(iq.elapsed_ms) as elapsed, sum(iq.bytes) as bytes from (select start_time::date as day_d, slice,query,segment,datediff('ms',min(start_time),max(end_time)) as elapsed_ms, sum(bytes) as bytes from svl_query_report where end_time > start_time group by 1,2,3,4) iq join stv_slices as sl on (sl.slice = iq.slice) group by 1,2 order by 1 desc, 3 desc;

Sie können Query Monitoring Rules (QMR) verwenden, um schlecht konzipierte Abfragen zu identifizieren und zu protokollieren. Beispielsweise können QMR-Regeln definiert werden, um Abfragen zu protokollieren, die eine hohe CPU-Auslastung oder eine längere Laufzeit beanspruchen.

---