Leistungsindikatoren

freshman

SQL-Guru
Beiträge
100
Hallo Gemeinde,
möchte hier nun ma lgerne eine Anfrage stellen die wohl jeden angeht.
Welche Leistungsindikatoren sind wichtig, und welchen Wert sollten diese nicht überschreiten..
Denke, wenn jeder was dazu tut, bekommt man eine super Auflistung hin!
ich fang mal an:

Prozessor: Prozessorzeit - nicht dauerhaft bei 50% oder höher liegen
PhysicalDisk: AverageDiskQueueLength - <=2
Speicher: Seiten/sec - <20
BufferManager: BufferCacheHitRatio - >90%
Plan Cache: Trefferquote - so hoch wie möglich
GenerellStatitics: User Connections - Anzahl der Benutzer
Puffer Manager: Page Life Expectancy - => 300
SQL Statistics: Kompilierungen /sec - gleichbleibend
SQL Statistics: Recompilierungen /sec
Dieser Wert steigt, sobald kompilierte Pläne durch verschiedene SET Einstellungen erneut kompiliert werden müssen.

hat noch jemand was brauchbares?
 
Werbung:
Ich kenne mich nicht gut mit SQL Performance aus, aber:
Die Auslagerungsdatei von Windows fasziniert mich immer sehr. Grade im virtuellen Umfeld kommt man ja auf den Gedanken einfach mehr RAM zuzuteilen und auf die Auslagerungsdatei zu verzichten. Die Mehrheit scheint aber auf dem Standpunkt zu stehen das das nicht so gut ist, gute Artikel hierzu gibt es allerdings nicht so viele. Der SQL Server nimmt sich gerne mal (vorübergehend oder nicht) richtig viel RAM, daher sollte immer eine Auslagerungsdatei vorhanden sein, um den Rest aufzufangen.

tomshardware zu Auslagerungsdatei im Desktop Umfeld: http://www.tomshardware.de/Microsoft-Windows-Vista,testberichte-239936-6.html
Auslagerungsdatei im RAM: http://www.winfaq.de/faq_html/Content/tip1000/onlinefaq.php?h=tip1260.htm
Das wollte ich immer mal auf einem alten Terminal Server ausprobieren, könnte lustig sein. SQL nimmt aber meines Wissens nach keine Auslagerungsdatei in Anspruch, nur physischen RAM.
 
Das stimmt, SQL nutzt nur physisch vorhandenen RAM, somit fällt die Beobachtung der Auslagerungsdatei flach!
Recht hast Du, früher wurde immer gesagt, mehr RAM mehr RAM mehr RAM.. dabei gibt es so viele Dinge, die man beobachten sollte, ich finde auch immer den LEVEL 2 Cache wichtig, nehme immer mindestens 512MB Cache für den Controller (bei MS SQL Server).
Wichtig finde ich auch die Blockgröße, mir ist aufgefallen, das bei meiner ketzten MS SQL Server installation auf einem HP Server DL 380 G7 im Array Configuration Tool bei der Konfiguration der Arrays automatisch eine viel zu große Blockgröße vorgegeben wurde....
UNBEDINGT beachten, empfohlene Blockgröße ist anch wie vor 64k
das nur nebenbei!
 
Wirkt sich die Blockgröße auch tatsächlich auf Performance aus oder einfach nur auf den Speicherbedarf? Mit SAN ist das alles nicht so einfach, da kann man zwar unterschiedliche Speicherpools bilden aber mir wurde davon abgeraten, unterschiedliche Speicher in eine VM zu mappen, keep it simple. Wenn also nicht nur SQL sondern auch noch Daten auf einem Server liegen (z.B. DMS) dann müsste man sich entscheiden.

PS: Die Auslagerungsdatei übernimmt dann aber ggf. Daten anderer Anwendungen aus dem Arbeitsspeicher, wenn der SQL den RAM zieht. Das kann so einen Server sonst auch lahm legen.
 
64k Blockgröße (von mir aus auch Speicherplatzbedarf) hat definitiv auch mit Performance zu tun...
guter Artikel:
http://blogs.technet.com/b/vipulsha...ation-for-sql-server-2005-dw-environment.aspx

zu Deinem PS: ich würde nie einen Server ohne Auslagerungsdatei betreiben.. okay?

Wer hat Dir denn davon abgeraten, unterschiedlich Speicherpools zu bilden?
Natürlich ist es optimal, wenn ich möglichst viele Platten in einem Speicherpool einbinde!
Aber bevor ich Daten vermische, würde ich mir immer erst genauestens anschauen, wie die Zugriffshäufigkeit auf die Daten ist.
jeder Zugriff bedeutet Plattenaktivität und auch Controlleraktivität.genauere Analyse ist ZWINGEND erforderlich, da man keine pauschale Aussage diesbezüglich machen KANN!!! überleg mal, Du priorisierst ja bestimmt auch den SQL Server Zugriff, oder?
Dann ist auch entscheiden, was für ein Storage (EMC, NetApp oder HP EVA....) mit welchem RAID betrieben wird.. Anzahl der Controller, Anzahl der Platten usw usw usw..
Also, wer sagt, das man DAS nicht machen soll, der hat wohl ganz genauc anlysiert, oder??
:-)
ABER: wenn Ihr keine Performance Probleme ahbt, dann passt das ja, oder?
:-)
 
Werbung:
Performance Probleme schon geringfügig, aber nicht mit Datenbanken.

Die Aussage, möglichst keine unterschiedlichen Speicherpools einbinden bezog sich auf Speicherpools in einer einzelnen VM und war gedacht um das ganze "flexibel" zu halten im Sinne von HA etc. Ansich stellt es aber in unserer Umgebung keinen großen Aufwand dar.

Bei uns gibt es derzeit auch nur 2 Storrages die sich nur im RAID Level unterscheiden, allerdings auf der selben SAN liegen. Ein Pool aus mehreren RAID1 und einen RAID5, je nachdem wie viel Daten ein Server verwaltet und wie Zugriffsintensiv er ist liegt er entweder auf RAID1 oder RAID5. Allerdings gibt es Pläne, das SAN zu erneuern. In diesem Zusammenhang werde ich mir dann vieleicht auch mal konkreter die Performance einiger SQL Server ansehen, im Moment fehlt mir da etwas die Zeit.
 
Zurück
Oben