Wir haben Performanceprobleme mit unserem MSSQL. Ich suche jetzt Möglichkeiten die Geschwindigkeit zu erhöhen - erstmal nur theoretisch.
Ein paar technische Daten zum MSSQL Server:
1x Quad-Core mit HyperV = 8 Kerne in der VM
22GB RAM
HDD auf SAN mit Raid10.
Der Windows Server ist eine VM, die auf einem eigenen Hardware Server sitzt und diesen Host nicht mit anderen VMs teilen muss. Eine unserer Vermutungen ist, dass das SAN evtl zu langsam ist. Deshalb die theoretische Idee, der VM eine weitere virtuelle Platte zu spendieren, die auf einem eigenen SAN liegen sollte und somit völlig von der ursprünglichen Platte getrennt ist. Die Platte soll dann für einen Teil der Datenbankdateien genutzt werden.
ihr solltet solche Aktionen nicht aufs Geratewohl unternehmen. Bei SQL Server (und anderen Datenbanken) gibt es hunderte von Faktoren, die die Performance beeinflussen können. IO gehört sicher als wesentlicher Punkt dazu, ist aber längst nicht immer die Ursache für Probleme.
Sind z.B. DB und Logs getrennt? Wie sieht es mit der Nutzung der TempDB aus und wo liegt die? Sind alle notwendigen Indizes vorhanden? Gibt es Sperrkonflikte oder andere Verzögerungen durch die Applikationslogik? Ist das SAN korrekt angebunden und vom LAN getrennt? ... usw. usf.
Aus Erfahrung kann ich sagen, dass es bei Datenbanken sehr viel bringt auf die jeweilige Query optimierte Indizies zu erstellen. Leider packen das Entwickler oft nicht, weil Hibernate oder ähnliche API's benutzt werden.
BTW: Wie viele Prozessoren hat denn die Hardware ? Du darfst auf keinen Fall sol viele VCPU's zuordnen, wenn die Hardware nur 8 Cores hat.
Je nachdem, was der Host sonst noch macht, 2 bis max. 4 vCPU's
Bei Nils gab es (glaube ich) einen Link zum Thema, wie viele VCPU's eine VM haben sollte...
@NilsK
Vorab, ich werde keinenfalls den MSSQL betreffende Lösungsvorschläge selbsttätig ausführen. Dafür habe ich zu wenig Erfahrung damit.
Der MSSQL Server hat seine beiden Platten auf ein und dem selben Raid des SANs liegen. Damit sind die Dateien für DB, T-Log und TempDB nicht getrennt. Ich weiß, dass das die Vorgaben zur optimierten Installation eines MSSQL durch Microsoft sind (Dokument habe ich jetzt nicht zur Hand).
Für Indizierungsprobleme haben wir uns schon einen Profi für MSSQL (mit Dynamics NAV!) ins Haus geholt. Er konnte auch einiges erkennen und ändern, aber eine dramatische Besserung hat das nicht gebracht. Allerdings ist seine Aussage, dass die Performance des virtualisierten Windows Servers mit MSSQL schon sehr gut ist.
Ob allerdings in NAV Probleme liegen, die nur die Anwendungsentwickler erkennen und lösen können, haben wir noch nicht geprüft.
@zahni
Bzgl der CPUs habe ich mich ein wenig vertan. Der Host hat 2x Quadcores. Hyperthreading (nicht HyperV!) ist abgeschaltet. Der VM des MSSQL sind alle 8x CPU-Kerne zugeordnet. Das sollte problemlos sein, da der Host keine weiteren VMs laufen hat. MSSQL in der Standardversion verwendet nur 4 Kerne, was man klar am Taskmanager erkennen kann. Die restlichen 4 Kerne dümpeln nur vor sich hin.
Der MSSQL Server hat seine beiden Platten auf ein und dem selben Raid des SANs liegen.
das wäre Punkt 1, den man ändern sollte. Erfordert ggf. Umkonfiguration im SAN und in den Speicherpfaden der DB, aber nicht in der Datenbanklogik.
Damit sind die Dateien für DB, T-Log und TempDB nicht getrennt. Ich weiß, dass das die Vorgaben zur optimierten Installation eines MSSQL durch Microsoft sind (Dokument habe ich jetzt nicht zur Hand).
Da fehlt zwischen "dass das" und "die Vorgaben" aber ein "nicht", oder?
Der VM des MSSQL sind alle 8x CPU-Kerne zugeordnet. Das sollte problemlos sein, da der Host keine weiteren VMs laufen hat.
Nein. Der Host hat auch selbst was zu tun und braucht dafür CPU-Leistung. Das ist bei allen Virtualisierern so (wie sollte es auch anders sein?), bei Hyper-V und Verwandten aber besonders.
Nein, mir ist schon bekannt, dass bei MSSQL Installation die drei Bereiche getrennt werden sollten. Bei der Installation hatte ich allerdings nichts zu sagen, muss jetzt aber die Performance Probleme ausbügeln.
Bzgl VM hast du fälschlicherweise angenommen, dass ich HyperV einsetze. Es ist aber VMware ESX. Andererseits gehe ich davon aus, dass VMware und HyperV bzgl der Verwendung von vCPUs sich analog verhalten und werde die vCPUs der Maschine auf vier reduzieren.
