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:
- Transaction-Log und Backups auf EBS ST1 Platten legen, da diese für large-block, hightrough put sequential workloads optimiert sind: http://de.slideshare.net/AmazonWebServices/aws-reinvent-2016-deep-dive-on-amazon-elastic-block-store-stg301
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 | |||||
Der Beitrag SQLServer Optimierung auf AWS erschien zuerst auf tecRacer Amazon AWS Blog.
