Wie vergleichen sich DTUs in Standard- und Premium-Leistungsstufen in SQL Azure?

8

Wir haben kürzlich einen schwerwiegenden Leistungsabfall in einer SQL Azure-Datenbank beobachtet, die in der Leistungsstufe Standard3 ausgeführt wird. Die CPU-Auslastung stieg in nur einer Stunde von zehn Prozent auf fünfzig Prozent auf fast einhundert Prozent. Daher haben wir die Leistungsstufe auf Premium2 geändert und die CPU-Auslastung sank sofort auf etwa acht Prozent.

Standard3 soll 100 DTUs anbieten und Premium2 soll 250 DTUs anbieten. Dies bedeutet, dass acht Prozent von P2 nur zwanzig DTUs sind, was weit davon entfernt ist, alle 100 DTUs in Standard3 zu verwenden.

Sind diese DTUs unterschiedlich? Wie ist sonst dieser plötzliche Nutzungsausfall beim Wechsel von einer Leistungsstufe von 100 DTUs zu einer Leistungsstufe von 250 DTUs möglich?

performance azure-sql-database

— scharfer Zahn
quelle

Ich interessiere mich für Ihre Erfahrungen mit diesem Thema. Ich würde sagen, dass diese DTUs tatsächlich unterschiedlich sind, aber es hängt wirklich davon ab, was Sie mit Ihrer DB machen. In meiner Umgebung haben wir beispielsweise eine Datenbank im Standard, die ein wenig Probleme hat, weil sie viel CPU-intensive Arbeit leistet, und ich bin mir ziemlich sicher, dass wir von Premium profitieren können, selbst wenn die Gesamtzahl der DTUs kleiner als ist Wir haben jetzt in der Standardstufe.

— Etienne

1

@Etienne TL; DR Premium ist viel, viel schneller als Standard, insbesondere wenn Sie in die Datenbank schreiben. Zum Beispiel kann ein sehr großes SELECT, das einen vollständigen Index-Scan verursacht, die meisten Schreibvorgänge in Standard leicht anhalten, aber diese Schreibvorgänge werden in Premium nur ein wenig langsamer. YMMV und Sie sollten überwachen, was in Ihrer Datenbank vor sich geht, um festzustellen, ob Ihnen das, was Sie sehen, gefällt und ob Sie mehr bezahlen möchten.

— Scharfzahn

6

Ich war ähnlich verwirrt, als ich die Preise für diese beiden Ebenen betrachtete. 100 DTUs auf Standard kosten 150 USD / Monat und 125 DTUs auf Premium kosten 465 USD / Monat. Ich dachte, etwas anderes muss diese Ungleichheit erklären. Ich denke, diese Zeile von https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-dtu#choosing-a-service-tier-in-the-dtu-based -einkaufsmodell muss den unterschied erklären:

                            | Standard                   | Premium
IO throughput (approximate) | 2.5 IOPS per DTU           | 48 IOPS per DTU
IO latency (approximate)    | 5 ms (read), 10 ms (write) | 2 ms (read/write)

Es sieht also so aus, als wäre eine Premium-DTU 19-mal mehr wert als eine Standard-DTU

— UnionP
quelle

1

Ich habe die obigen Informationen unter diesem Link gefunden. Docs.microsoft.com/en-us/azure/sql-database/… Hoffentlich bewegt es sich wieder.

— David Yates

Danke David! Ich habe den Link im Kommentar aktualisiert und ja, hoffentlich verschieben sie ihn nicht wieder :)

— UnionP

5

Die Leistung von Azure-Datenbanken wird in DTUS ausgedrückt, dh der Anzahl der Transaktionen, die pro Sekunde ausgeführt werden können. Außerdem wird die maximale Speichermenge, CPU und E / A begrenzt, die Ihre Datenbank erhält. Weitere Informationen finden Sie in der folgenden Tabelle Achten Sie auf den Abschnitt Sitzungsanfragen.

Ich hoffe, dass das obige Bild die Unterschiede zwischen verschiedenen Datenbankebenen verdeutlicht. Weiter unten wird in Azure Documentation angegeben, wann verschiedene Datenbankebenen verwendet werden sollen.

Wann immer Sie die Leistung der Azure-Datenbank schätzen möchten, sollten Sie unten DMVS überprüfen, das weitere Details zur DTU-Nutzung enthält, ausgedrückt in E / A, Protokoll, Speicher, CPU.

- Diese DMV enthält Daten für nur eine Stunde, die jedoch alle 15 Sekunden erfasst werden

SELECT  
    AVG(avg_cpu_percent) AS 'Average CPU Utilization In Percent', 
    MAX(avg_cpu_percent) AS 'Maximum CPU Utilization In Percent', 
    AVG(avg_data_io_percent) AS 'Average Data IO In Percent', 
    MAX(avg_data_io_percent) AS 'Maximum Data IO In Percent', 
    AVG(avg_log_write_percent) AS 'Average Log Write Utilization In Percent', 
    MAX(avg_log_write_percent) AS 'Maximum Log Write Utilization In Percent', 
    AVG(avg_memory_usage_percent) AS 'Average Memory Usage In Percent', 
    MAX(avg_memory_usage_percent) AS 'Maximum Memory Usage In Percent' 
FROM sys.dm_db_resource_stats;

- Diese DMV enthält Daten für 14 Tage mit einem Erfassungsintervall von 5 Minuten

SELECT start_time, end_time,    
  (SELECT Max(v)    
   FROM (VALUES (avg_cpu_percent), (avg_physical_data_read_percent), (avg_log_write_percent)) AS value(v)) AS [avg_DTU_percent]  
FROM sys.resource_stats 
WHERE database_name = '<your db name>' 
ORDER BY end_time DESC;

Immer wenn Sie eine DTU-Metrik konstant bei 90% sehen, ist dies ein Indikator für den Flaschenhals und kann auf die gleiche Weise behoben werden. Wir beheben Fehler auf unseren On-Prem-Servern.

Angenommen, Sie sehen die CPU für einen bestimmten Zeitraum konstant bei 90% der von DMV erfassten Daten. Sie können mit dem Sammeln von Abfragen beginnen, die eine hohe CPU verursachen, und prüfen, ob sie so eingestellt werden können, dass sie weniger CPU verbrauchen Wenn Ihre Optimierungsbemühungen erschöpft sind, müssen Sie möglicherweise definitiv auf eine höhere Stufe upgraden

Referenzen: https://azure.microsoft.com/en-in/documentation/articles/sql-database-performance-guidance/#monitoring-resource-use-with-sysresourcestats

— TheGameiswar
quelle

Ich habe diesen Tisch gesehen. Es erklärt nicht, wie ich avg_cpu_percentnach dem Wechsel von S3 zu P2 von 100 Prozent auf 8 Prozent gesenkt wurde.

— Scharfzahn

Stellen Sie sich vor, wie auf einem Prem-SQL-Server mit 2 GB RAM und wenn Sie speicherintensive Abfragen ausführen, warten einige möglicherweise auf die Speichergewährung. Sie werden also feststellen, dass die Speichermetrik immer hoch ist. Wenn Sie den Speicher erhöhen, wird dies niedriger

— TheGameiswar

Ich bin in Ordnung, wenn ich es niedriger sehe, aber es ist von 100 Prozent auf 8 Prozent gestiegen - mehr als zehnmal niedriger.

— Scharfzahn

Aktuelle

— Michael Freidgeim,

3

Diesmal war der Grund dafür, dass SQL Azure seine Meinung geändert hat, welcher Index für eine häufig ausgeführte Abfrage verwendet werden soll. SQL Azure entscheidet manchmal, dass das Ändern eines verwendeten Index möglicherweise eine gute Idee ist (basierend auf gesammelten Metriken). Zum Zeitpunkt der Beobachtung des Problems war dieser Mechanismus nicht validiert. Sobald die Abfrage auf einen anderen Index umgestellt wurde, validierte das Datenbankmodul nicht, ob tatsächlich eine Verbesserung vorliegt. Keine Ahnung, ob sich dies seitdem geändert hat. Der Weg, um diese Situation zu WITH INDEXumgehen, ist die Verwendung von Hinweisen.

Die von uns beobachtete Leistungsverbesserung war nicht darauf zurückzuführen, dass die Leistungsstufe selbst geändert wurde. Gerade als Standard auf Premium umgestellt wurde, gab es vermutlich eine Hardwareänderung. Daher wurden die Datenbankstatistiken gelöscht und das Datenbankmodul überprüfte die Abfragepläne erneut, und so wechselten wir zu Premium Der Motor wurde gerade auf den alten Plan zurückgesetzt, deshalb haben wir damals die Leistungsverbesserung erhalten.

— scharfer Zahn
quelle

1

Um eine Verschiebung auf eine andere Ebene durchzuführen und gleichzeitig Ausfallzeiten zu minimieren, repliziert Azure die Datenbank grundsätzlich auf einen Host, der diese Art von Last bereitstellt, und schaltet nach Abschluss um (die geringe Ausfallzeit am Ende des Prozesses ist dort, wo sie aktiv geschlossen wird) Transaktionen, die die endgültigen Aktualisierungen replizieren und umschalten). Dies führt wahrscheinlich zu Statistikaktualisierungen, die in Ihrem Fall dem Abfrageplaner geholfen haben, eine bessere Entscheidung zu treffen.

— David Spillett

0

Wenn Sie nach dem neuen Azure SQL vCore- basierten Vergleich suchen , sollten diese Artikel von Websites von Drittanbietern und offiziellen Microsoft-Websites weitere Informationen enthalten.

— Gesichter der IT
quelle