02 Jan '17

SQLServer Optimierung auf AWS

Written by tecRacer

This content is more than 4 years old and the cloud moves fast so some information may be slightly out of date.

Im Dezember haben wir im Rahmen eines Consulting-Einsatzes verschiedene SQLServer EBS-Laufwerks-Kombinationen bei einem Kunden ausprobiert, um eine optimale Performance zu erreichen.

Zusammenfassung:

  • r4.4xlarge bringt fast doppelte Performance gegen über r4.2xlarge, obwohl CPU und RAM bei beiden Instanzen nicht viel Auslastung haben … Das war eine Überraschung!
  • Striping generell bringt fast doppelte Performance gegenüber kein Striping
  • EBS Typ io1 mit 5000 IOPS bringen gegenüber EBS Typ GP2 bei der einen Abfrage doppelte Performance, bei den anderen 4 Abfragen teilweise fast gleiche oder nur 30 % mehr Performance bei erheblich mehr Kosten
  • Die neuen R4 Instanzen haben übrigens DDR4 RAM, bis zu 10 Gbit Network und bis zu 12 Gbit EBS-Network Anbindung. Leider konnten wir keinen Vergleich zu R3 machen

  Weitere Ideen:

SQLServer Dataware-House Test bei Kunde am 6.12.2016

SQLServer 2016 SP1 Standard Edition auf Windows 2016 SQL-DB Grösse 180 GB

Test der Performance unterschiedlicher EBS-Storage-Lösungen

VIVA_000 Boot Laufwerk C auf 50 GB EBS GP2

  • SQLDATA Laufwerk auf D: mit 1 x 500 GB GP2 für DATA und LOG
  • Laufwerk T als SQLTemp mit 100 GB io1 und 5000 IOPS (wurde aber bei den SQL-Abfragen so gut wie gar nicht verwendet und spielt daher eigentlich hier keine Rolle)

VIVA_000_S Boot Laufwerk C auf 50 GB EBS GP2

  • SQLDATA Laufwerk auf S: mit 3 x 200 GB GP2 gestriped für DATA und LOG
  • Laufwerk T als SQLTemp mit 100 GB io1 und 5000 IOPS (wurde aber bei den SQL-Abfragen so gut wie gar nicht verwendet und spielt daher eigentlich hier keine Rolle)

VIVA_000_U Boot Laufwerk C auf 50 GB EBS GP2

  • SQLDATA Laufwerk auf U: mit 6 x 100 GB GP2 gestriped für DATA und LOG
  • Laufwerk T als SQLTemp mit 100 GB io1 und 5000 IOPS (wurde aber bei den SQL-Abfragen so gut wie gar nicht verwendet und spielt daher eigentlich hier keine Rolle)

VIVA_000_P Boot Laufwerk C auf 50 GB EBS GP2

  • SQLDATA Laufwerk auf P: mit 1 x 550 GB io1 mit 5000 IOPS für DATA und LOG
  • Laufwerk T als SQLTemp mit 100 GB io1 und 5000 IOPS (wurde aber bei den SQL-Abfragen so gut wie gar nicht verwendet und spielt daher eigentlich hier keine Rolle)

VIVA_000_I Boot Laufwerk C auf 50 GB EBS GP2

  • SQLDATA Laufwerk auf S: mit 3 x 200 GB io1 mit 5000 IOPS gestriped für DATA und LOG
  • Laufwerk T als SQLTemp mit 100 GB io1 und 5000 IOPS (wurde aber bei den SQL-Abfragen so gut wie gar nicht verwendet und spielt daher eigentlich hier keine Rolle)
Test1 mit Skript mit 4 Queries r4.4xlarge r4.2xlarge
VIVA_000 nach SQLServer-Restart 02:11 1 x 500 GB GP2
VIVA_000 direkt wiederholt 00:15
VIVA_000_S nach SQLServer-Restart 00:59 01:30 3 x 200 GB GP2 striped
VIVA_000_S direkt wiederholt 00:15 00:19
VIVA_000_U nach SQLServer-Restart 00:51 01:23 6 x 100 GB GP2 striped
VIVA_000_U direkt wiederholt 00:15 00:19
VIVA_000_P nach SQLServer-Restart 01:22 1 x 550 GB io1 mit 5000 IOPS
VIVA_000_P direkt wiederholt 00:15
VIVA_000_I nach SQLServer-Restart 00:52 3 x 200 GB io1 mit 5000 IOPS striped
VIVA_000_I direkt wiederholt 00:15
OnPremise vorgewärmt 01:34 vorgewärmt, mit SAN
wiederholt 01:23
Test2 mit 1 Query (AD-Server) mit viel Table-Scans
VIVA_000_S nach SQLServer-Restart 01:54 03:35 3 x 200 GB GP2 striped
direkt wiederholt 00:18 00:31
VIVA_000_I nach SQLServer-Restart 00:59 3 x 200 GB io1 mit 5000 IOPS striped
direkt wiederholt 00:14
VIVA_000_U nach SQLServer-Restart 01:53 03:34 6 x 100 GB GP2 striped
direkt wiederholt 00:15 00:31

Similar Posts You Might Enjoy

06 May '14

AWS EC2 Performance Probleme und deren Lösung

Die Firma Datadog hat ein White Paper zu den Top5-Performance-Problemen bei AWS EC2 veröffentlicht. Das 24-seitige PDF-Dokument erklärt anschaulich, wie man die wichtigsten Probleme erkennt, warum die Probleme auftreten und wie man sie beseitigt. Das PDF von Datadog finden Sie hier: AWS EC2 Performance Probleme und deren Lösung. - by tecRacer

07 Aug '18

CloudWatch Alarme über Slack empfangen

Ob CPU-Auslastung einer EC2-Instanzen, Fehler beim Ausführen einer Lambda-Funktion oder verfügbarer Speicherplatz einer RDS-Instanz mit Amazon CloudWatch lassen sich Ressourcen bei AWS überwachen. Dafür werden zwei Komponenten benötigt: Metriken: Eine Metrik ist ein Sammeltopf für Messwerte, die von den AWS Services automatisch befüllt werden. Alarme: Ein Alarm überprüft in regelmäßigen Abständen ob sich die Messwerte einer Metrik noch innerhalb von definierten Grenzen bewegt. Eine Übersicht über alle verfügbaren Metriken findet sich unter Metriken und Dimensionen-Referenz von Amazon CloudWatch. - by Andreas Wittig

22 Feb '18

Link Local-Addressen bei AWS

Im sogenannten APIPA/Link Local-Bereich (siehe RFC 3927) sind auf AWS EC2-Instanzen mehrere Dienste erreichbar, von denen der Metadata Service mit Abstand der Bekannteste und Wichtigste ist. Allerdings gibt es dort auch andere Services (siehe Post “Default DNS-Server in AWS VPCs”), die in der Dokumentation teils recht versteckt sind. - by Thomas Heinen