Wir haben eine App, die SQL Server 2008 R2 Express auf dem Backend auf einem virtuellen Windows 2008 R2-Server ausführt, der auf VMWare ESXi läuft. Benutzer beschweren sich, dass die App sehr langsam ist. Ich sehe sehr hohe Festplatten-E/A, die für mich keinen Sinn ergeben.
Hintergrund:
- Die durchschnittliche Länge der Festplattenwarteschlange beträgt etwa 60, das Maximum etwa 250
- Die durchschnittliche Anzahl an Festplattenlesevorgängen pro Sekunde liegt bei etwa 2000, das Maximum bei etwa 3500
- Der Ressourcenmonitor zeigt, dass sqlservr.exe die MDF-Datei mit etwa 40–60 MB/s liest (siehe unten). Die Schreib-E/A ist sehr niedrig.
- Die MDF-Datei ist nur 2 GB groß, das heißt, das Ganze sollte in den Speicher passen
- Der Server verfügt über 32 GB RAM und normalerweise sind weniger als 16 GB im Einsatz
- Der Server verfügt über 8x 15k SAS-Festplatten in RAID10. Es handelt sich um einen Dell mit einem PERC H710-Controller, der eine SSD aufnehmen kann, um CacheCade (SSD-basierter Lese-Cache) zu aktivieren. Ich würde das gerne ausprobieren, aber es sieht so aus, als ob das Ganze sowieso im RAM zwischengespeichert werden sollte, also bin ich mir nicht sicher, ob das hilft.
- Die SQL-VM befindet sich auf einem Dell-Server, auf dem VMWare ESXi 5 läuft. Auf diesem ESXi-Host gibt es eine weitere VM, aber es handelt sich dabei um einen Domänencontroller mit sehr geringer IO.
- Diese App lief zuvor auf einem eigenständigen Windows 2003-Server. Wir haben ein Upgrade auf Windows 2008 R2 durchgeführt und gleichzeitig auch die App auf eine neuere Version aktualisiert. Es ist also möglich, dass einer dieser Faktoren dazu beigetragen hat.
Welche Möglichkeiten gibt es, tiefer in die Sache einzudringen? Gibt es eine Möglichkeit zu sehen, was der SQL-Server im Hintergrund tut (welche Abfragen ausgeführt werden usw.)? Scheint dieses Verhalten normal zu sein und ist die Belastung einfach zu hoch für den Speicher? Ich frage mich, ob etwas nicht richtig konfiguriert ist.
Antwort1
http://msdn.microsoft.com/en-us/library/cc645993(v=sql.105).aspx#Scalability
Espress verwendet für den SQL-Prozess nicht mehr als 1 GB RAM. Sie müssen mindestens Web oder Standard kaufen und installieren, um mehr als 4 GB zu verwenden. Beide unterstützen 64 GB, was mehr ist, als Sie haben, also nehmen Sie eine davon.
Außerdem ist die Arbeit als DBA ein ziemlich tiefgehendes Thema, aber es ist über Technet und die Hilfedatei sehr gut zugänglich. „Woher weiß ich, welche Abfragen ausgeführt werden?“ ist so ziemlich ein Thema, das am ersten Tag behandelt wird (ebenso wie die Frage, welche Edition für eine bestimmte Aufgabe geeignet ist). Profiler ist nicht einmal für Express verfügbar, sodass Sie mit Ihrer aktuellen Konfiguration aufgeschmissen sind.
Antwort2
Sehen Sie sich die Abfragedetails an – überprüfen Sie Abfragen mit hohem physischen oder logischen IO, isolieren Sie sie und sehen Sie sich den Abfrageplan an. Ich habe seit Jahren eine veraltete Version wie 2008 R2 verwendet ... http://gallery.technet.microsoft.com/scriptcenter/Find-inefficient-query-88f4611fkann Ihnen einen Anfang geben.
Mein Hinweis geht in Richtung fehlender Indizes, die Tabellenscans auslösen. Der Profiler und die Tuning-Assistenten können ebenfalls dabei helfen, herauszufinden, wo das Problem liegt. Wenn 2008 R2 bereits über eine Aktivitätsübersicht im Manager verfügt, bietet dieser ein schönes Fenster mit den teuersten Abfragen.