>Also macht unser Aufbau so keinen Sinn, da sich die DB Server untereinander die Performance wegnehmen. Besser wäre es für jeden SQL Server ein eigenes RAID10 LUN? Moment, dieser Schluss wär...
See more...
>Also macht unser Aufbau so keinen Sinn, da sich die DB Server untereinander die Performance wegnehmen. Besser wäre es für jeden SQL Server ein eigenes RAID10 LUN? Moment, dieser Schluss wäre für mich etwas voreilig. Bis jetzt wurden nur Vermutungen häufiger Ursachen im Zusammenhang mit SQL-Servern diskutiert. Um irgendwas konkretes zur Ursache in deinem Fall zu sagen, sollte das Problem erst mal von dir mit konkreten Kennzahlen eingegrenzt werden. Ich habe keine Ahnung was DATEV ist oder wie groß und transaktionslastig eure Datenbank wirklich ist, aber Ich erlebe leider zu oft, dass grade bei allem wo "Datenbank" oder "SQL" draufsteht, hemmungslos und ohne Not überdimensioniert wird, egal ob physikalisch oder virtuell. Bei Virtualisierung werden dann "Performanceprobleme" meist durch äußerst subjektive Erscheinungen (wie dein "Programm läuft langsam") direkt zu wenigen Ressourcen oder der Virtualisierung an sich zugeschrieben. Meist ist die echte Ursache dann in der Applikation zu suchen oder resultiert aus der Summe mehrerer VM-Überdimensionierungen auf einem Host. Also, als erstes checke die Disk-Device Latenzen am besten in (r)esxtop oder den vCenter Statistiken zu den Problemzeiten. Falls die hoch ausfallen (~>20ms), liegt das Problem aller Wahrscheinlichkeit nach wirklich an der Storage-Infrastruktur. Zum Testen kannst du vielleicht auch eine VM per SVMotion auf lokalen Storage verschieben und schauen wie sich die Performance dort verhält. Einen Blick auf den CPU %RDY Wert solltest du auch werfen (meist durch zu viele vCPUs; braucht deine VM wirklich 4?). Dieser Guide bietet eine gute Übersicht über die Vorgehensweise bei Performanceproblemen und die Metriken die es zu überwachen gilt: http://communities.vmware.com/docs/DOC-10352 Das Dokument kann auch fast 1:1 auf ESX5 angewendet werden. Gute Übersicht zu (r)esxtop inklusive empfohlenen Schwellwerten: http://www.yellow-bricks.com/esxtop/ Zu deiner ursächlichen Frage nach den angezeigten Memory-Werten: Aktiver Speicher bedeutet, wie der Name schon sagt, wie viel Speicher wirklich aktiv vom Gast in Benutzung ist. Im Gegensatz dazu sagt der "belegte" Speicher aus, wie viel physikalischer RAM auf dem Host von der VM belegt wird (in deinem Fall wohl die vollen 32GB, die du auch zugeteilt hast, also fallen z.B. Limits schon mal weg). Aber: Nur weil du deiner VM 32GB RAM zuteilst, dein SQL-Server im Gast den ganzen Speicher hortet und du im Taskmanager siehst, dass der Prozess 26GB belegt, heißt das alles noch lange nicht, dass diese 26GB auch wirklich aktiv angetastet werden, geschweige denn irgendwas sinnvolles außer "reserviert sein" vollbringen. Ich gehe daher davon aus, dass der Speicher nicht dein Problem ist (eher überdimensioniert). Um ganz sicher zu gehen schaue dir vielleicht noch die swap- und balloon-counter an. http://www.yellow-bricks.com/2010/12/20/vcenter-and-memory-metrics/
