Wie Speedgain eine Azure SQL Database vor hohen Kosten bewahrte
In der modernen Welt der Cloud-Datenbanken ist die Effizienz der Ressourcennutzung entscheidend für die Performance und Kostenkontrolle. In diesem Blogartikel zeigen wir, wie Speedgain for Databases einem unserer Kunden, einem führenden Unternehmen im Bereich E-Commerce, geholfen hat, die Ursache für die ausgeschöpften DTUs (Database Transaction Units) seiner Azure SQL Database zu identifizieren und zu beheben, um so steigende Cloud-Kosten zu vermeiden.
Ausgangssituation: Ausgereizte DTUs und langsame Zugriffe
Das Cloud Platform Team unseres Kunden stand vor einem ernsthaften Problem: Regelmäßig verlängerte sich die Laufzeit von Anfragen drastisch, weil die DTUs ihrer Azure SQL Database zu diesen Zeitpunkten vollständig ausgelastet waren. Die initiale Analyse zeigte, dass die Auslastung der DTUs ausschließlich auf die Auslastung der verfügbaren IOs verursacht wurde. Doch was steckte genau dahinter?
Die DTU-Auslastung war regelmäßig im roten Bereich
Damit korrelierte die Auslastung der verfügbaren IOs
Die CPU-Auslastung sowohl für die Datenbank (rosa) als auch für die gesamte Instanz (blau) war in dieser Zeit durchgängig im grünen Bereich
Diagnose mit Speedgain: Niedrige Hit Ratio und überfüllter Plan Cache
Mithilfe von Speedgain konnte das Team das Problem schnell visualisieren und analysieren. Die niedrige Hit Ratio, sowie erhöhte Latch Wait Times deuteten darauf hin, dass viele Zugriffe direkt auf die Disk statt auf den schnelleren Speicher gingen. Dies war ein klares Indiz für eine ineffiziente Nutzung des verfügbaren Speichers.
Ein genauerer Blick in die Speicherauslastung zeigte, dass die Datenbank lediglich 25% des verfügbaren Speichers belegte, die gesamte Instanz jedoch fast 100% des Speichers nutzte. Sobald Seiten von der Disk nachgeladen wurden, erhöhte sich der genutzte Speicher der Datenbank nicht. Wie die niedrige Page Life Expectancy bestätigte, war einfach nicht ausreichend Speicher verfügbar. Das warf die Frage auf, wofür die restlichen 75% Speicherplatz der Datenbank verwendet wurden.
Server Committed Memory
Eine Betrachtung der Speicherzusammensetzung aus Sicht des Servers zeigte an, dass ca. 75% des von der Instanz genutzten Speichers als „Stolen Memory“ ausgewiesen wurde, d.h., für Caches außerhalb der Datenbankseiten genutzt wurden. Aber warum war dieser Wert so hoch?
Die Antwort fand sich im Plan Cache, der übermäßig groß gewachsen war und aus einer großen Anzahl von Abfrageplänen bestand, die nur ein- oder zweimal benutzt wurden.
Der Plan-Cache wächst immer wieder auf den gleichen hohen Wert an
Die gelbe Linie zeigt die Anzahl der Pläne im Cache, die grüne Linie die davon genutzten
Ursachenanalyse und nachhaltige Lösung
Dank des generischen KPI-Dashboards in Speedgain konnte das Team die genaue Ursache identifizieren: Der Plan Cache wuchs permanent an, jedoch wurde nur ein Bruchteil der Pläne wirklich genutzt. Eine detaillierte Untersuchung zeigte, dass eine Vielzahl identischer Abfragepläne vom Typ „Prepared“ im Cache gehalten wurde, was das Plan Cache Bloating erklärte.
Die Lösung bestand darin, den Plan Cache zu bereinigen und der verursachenden Abfrage einen weiteren Parameter hinzuzufügen. Nachdem dies durchgeführt wurde, konnte Speedgain die Wirksamkeit der Maßnahme nachweisen: Der Plan Cache wuchs nicht mehr so stark an und die Datenbank konnte mehr Speicher belegen. Dadurch wurden die Anzahl der IOs gesenkt und die DTUs nicht mehr ausgereizt. Die Performance war nicht nur wiederhergestellt, sondern sogar verbessert, und es entstanden keine zusätzlichen Kosten durch zusätzliche DTUs in einer höheren SKU.
Nach Bereinigung des Plan Chache konnte der Database Cache wachsen
Gleichzeitig blieb der Plan-Cache auf dem niedrigeren Niveau
Langfristige Monitoring-Lösung
Um solche Probleme in Zukunft schneller zu erkennen, wurde ein weiteres Panel in Speedgain integriert. Dieses Panel zeigt die zugrundeliegenden Metriken direkt zusammen an und ermöglicht eine sofortige Identifikation ähnlicher Probleme. Darüber hinaus wurde ein Alerting-System implementiert, das diese Metriken überwacht und bei Auffälligkeiten sofort alarmiert.
Cloud-native Implementierung mit AKS
Ein weiterer Vorteil von Speedgain ist seine cloud-native Implementierung. Speedgain wird auf einem Azure Kubernetes Service (AKS) betrieben, was eine flexible und skalierbare Nutzung ermöglicht. Diese Architektur erlaubt es, die Observability-Lösung nahtlos in die bestehende Cloud-Infrastruktur zu integrieren und bietet gleichzeitig hohe Verfügbarkeit und Leistung.
Durch diese Maßnahmen hat sich Speedgain nicht nur als wertvolles Tool für die Ursachenanalyse erwiesen, sondern auch als dauerhafte Monitoring-Lösung, die proaktive Maßnahmen ermöglicht und somit langfristig Kosten spart.
Fazit
Die effektive Nutzung von Speedgain for Databases hat unserem Kunden geholfen, ein ernsthaftes Performance-Problem zu lösen und zusätzliche Cloud-Kosten zu vermeiden. Durch die gezielte Analyse und Optimierung der Speicherverteilung in der Azure SQL Database konnte die Effizienz nachhaltig verbessert werden. Speedgain hat sich dabei als unverzichtbares Werkzeug erwiesen, das nicht nur bei der Problemlösung, sondern auch bei der langfristigen Überwachung und Optimierung unterstützt.
Machen Sie sich selbst ein Bild, wie Speedgain Ihre Cloud Datenbanken überwacht. Erhalten Sie direkt Insights und verbessern Sie auch Ihre Performance. Holen Sie sich das kostenfreie Trial unter: Speedgain Trial