Schlechte Performance (SQL 2000)

[MichaelG 10]

Hallo Leute,

 

auf folgendem Server (Windows 2003 32bit) betreiben wir eine MSSQL2000 Datenbank:

CPU: Intel Core2Duo E4300 @ 1,8 Ghz

Ram: 3 GB DDR2-667

Festplatte: 2x S-ATA 750 GB im Raid 1

 

Der Server stellt die Datenbank bereit und diverse Clients greifen darauf zu (Frontend ist auf den Clients installiert- Clientzahl liegt wohl bei ca. 30 (die Clients befinden sich in einem 10/100 Mbps Netzwerk)).

 

Leider laufen die Abfragen der Clients sehr zähflüssig und die Anwender beklagen sich über die schlechte Performance, teilweise kommt es auch zu Timeouts.

 

Weder das Frontend noch die Datenbank selbst ist von uns programmiert.

 

Ich kann nur sagen, dass die Schuld für die schlechte Performance nicht bei den Clients zu suchen ist (wir haben schon sehr potente Clienthardware aufgestellt und trotzdem hat sich nichts geändert- die Clients langweilen sich regelrecht).

 

Der erste Gedanke war, dass wir den Server hardwaremäßig aufrüsten, doch ich weiß, dass der SQL2000 Server ja nur maximal 2 GB Ram unterstützt, also macht das Ram aufrüsten keinen Sinn.

Zudem kann ich mit dem 32bit Betriebssystem ja nur maximal 3 GB Ram ansprechen (wobei den Anwendungen standardmäßig nur 2 GB Ram zugewiesen werden können. Ich weiß, es gibt da den /3 GB Switch, was mir bei einem SQL2000 Server ja aber nicht weiter hilft).

Die CPU Last habe ich mal via Taskmanager beobachtet.

100% CPU Last sind die Ausnahme, es kommt aber ab und zu vor. Ansonsten beträgt die CPU Last im Durchschnitt so um die 10-30%, ab und zu auch weniger.

 

Mich würde jetzt einmal interessieren, wie ich herausfinden kann, wo der Flaschenhals liegt...

Ich vermute ja mal dass die 2 GB dem SQL2000 nicht reichen, doch wie kann ich das belegen?

Es gibt ja den SQL Profiler- diesen habe ich mir auch schon oberflächlich angeschaut, doch ich kann mit all den Werten leider nichts anfangen.

Dann gibt es noch den Windows Performance Monitor- auch hier habe ich zig Werte, deren Interpretation mir schwer fällt. :-/

 

Zur Datenbank selbst:

Sie ist ca. 3 GB groß.

Folgende SQL Einstellungen wurden vorgenommen:

Memory:

- Dynamische Konfiguration

- "Reserve physical memory for SQL Server" ist nicht aktiviert

Processor:

- Beide Kerne sind aktiviert

- "Boost SQL Server priority ..." ist nicht aktiviert.

 

Folgende Datenbank Einstellungen wurden vorgenommen:

- "Auto update statistics" ist aktiviert

- "Auto shrink" ist aktiviert

- "Auto create statistics" ist aktiviert

- Data Files: Automatically grow file ist aktiviert (15 MB)

- Transaction log: Automatically grow file ist aktiviert (20 MB)

 

Wenn ihr mehr Angaben benötigt, gebt mir bitte bescheid.

Vielleicht erkennt ihr auf den ersten Blick falsche Einstellungen oder habt einen Ansatz, wie ich den Flaschenhals ausfindig machen kann.

 

Besten Dank.

[LukasB 10]

auf folgendem Server (Windows 2003 32bit) betreiben wir eine MSSQL2000 Datenbank:

CPU: Intel Core2Duo E4300 @ 1,8 Ghz

Ram: 3 GB DDR2-667

Festplatte: 2x S-ATA 750 GB im Raid 1

 

Erstmal: Mit SQL Server 2000 ist langsam essig: Mainstream Support ist nämlich im 2008 abgelaufen. (Extended Support bis 2013).

 

Please Verify your Location

 

Zwei langsame SATA Festplatten für 30 User? Wer hat denn da das Sizing gemacht?

 

Der erste Gedanke war, dass wir den Server hardwaremäßig aufrüsten, doch ich weiß, dass der SQL2000 Server ja nur maximal 2 GB Ram unterstützt, also macht das Ram aufrüsten keinen Sinn.

 

Der Server braucht wohl mehr Platten und mehr RAM.

 

Am besten klärst du da mit dem Hersteller der Software ab was sie für Sizing-Regeln für deren Software hat - das ist nämlich nicht wirklich von der Datenbank-Server-Software selber abhängig, sondern von der Anwendung bzw. dem Datenbank Design.

 

Für 30 User könnte ich mir etwas in der Grössenordnung von 2x 10kRPM OS, 2x 15kRPM Daten (RAID1) und 2x 15kRPM Log (RAID1) vorstellen, das in den meisten Fällen genügen dürfte.

 

Mich würde jetzt einmal interessieren, wie ich herausfinden kann, wo der Flaschenhals liegt...

 

Mit perfmon kannst du das herausfinden. Aber du hast zuwenig Disks und zuwenig RAM.

 

Zur Datenbank selbst:

Sie ist ca. 3 GB groß.

 

Herzig. Dann einfach 8GB RAM in die Maschine und das Problem ist gelöst - die Disks brauchst du das die synchrone Write-Performance auch stimmt. Logischerweise brauchst du dafür ein 64bit OS.

[NilsK 2.792]

Moin,

 

LukasB hat eigentlich in allem Recht. Folgende Ergänzungen:

 

• Stell das AutoShrink ab. Das ist keine sinnvolle Option.
  
• 15 bzw. 20 MB als Autogrow sind viel zu klein, damit erzeugst du Fragmentierung. Setz das auf 50, besser 100 MB oder mehr.
  
• Um RAM-Mangel nachzuweisen, schau dir in PerfMon die Cache Hit Ratio an (oder wie die heißt), also die Auskunft, wie viele angeforderte Datenbankseiten der Server im RAM finden konnte.
  

 

Abgesehen davon, ist es aber durchaus ein häufiger Fall, dass die Clientapplikation oder die von dieser verwendeten Abfragen schlecht geschrieben sind. Das zu ändern, liegt aber außerhalb deiner Macht, und auch der Nachweis ist u.U. nicht trivial.

 

Nach einen Umstieg auf SQL 2005 (oder besser 2008) könntest du darüber hinaus auch den Index-Optimierungs-Assistenten einsetzen, der in vielen Fällen eine Menge hilft.

 

Gruß, Nils

[Dominik Weber 19]

S-ATA Platten sind absoluter Mist für einen DB Server !!!

 

Wir haben bei einem Kunden auch einen SQL 2000 Server stehen, der hat ein Raid-10 Verbund mit 2.5" SAS Platten 15k ... der ist Absolut schnell.

[MichaelG 10]

Hallo,

 

erst mal danke für eure Beiträge.

 

Dass der Support für SQL2000 bald eingestellt wird, ist uns bewusst und ich denke, wir werden auch zeitnah auf SQL2005 umsteigen.

 

Der Software Hersteller möchte natürlich, dass die möglichst beste Hardware eingesetzt wird, schlägt z. B. folgendes vor:

- Intel Xeon E5430 Quad Core mit 2,66 Ghz

- 300 GB SAS Platten (15.000 RPM)

- 8 GB Ram

 

Um zum Thema Festplatten zu kommen:

Warum sind S-ATA Platten für einen Datenbank Server so viel schlechter geeignet als SAS Platten?

Ok, die SAS Platten drehen i. d. R. schneller (15.000 Umdrehungen statt 7.200), aber vom Interface selbst nehmen sich beide Technologien nicht viel, oder?

 

Ich habe jetzt mal 24h Perfmon laufen lassen, dabei folgende Durchschnittswerte erhalten:

Pages/sec (Memory): 0,402

Available Bytes (Memory): 694 MB

% Disk Time (Physical Disk): 1102,163

Avg. Disk Queue Length (Physical Disk): 22,043 (insgesamt)

% Processor Time (PRocessor): 16,516

Processor Queue Lenght (System): 1

Buffer Cache Hit Ratio (SQL Server Buffer): 95,728

User Connections (SQL Server General): 66

 

Ok.

Die Werte sprechen eigentlich dagegen, dass viiiel zu wenig Ram vorhanden ist. Klar, je näher Buffer Cache Hit Ratio an den 100 ist, desto besser und mir ist natürlich klar, dass wir das optimieren sollten.

Ich weiß noch nicht wirklich, wie ich den Wert der Disk Time interpretieren soll (1102% !?!?!?), aber alles in allem scheinen die Werte wirklich für zu langsame Festplatten sprechen.

 

Wir haben übrigens ein Software Raid in dem Server.

Wieviel Leistungseinbusen müssen wir deshalb in Kauf nehmen?

In erster Linie wird dadurch ja der Prozessor belastet, der bei uns ja noch Luft nach oben hat ...

 

Danke für euer Feedback. ;)

[LukasB 10]

Der Software Hersteller möchte natürlich, dass die möglichst beste Hardware eingesetzt wird, schlägt z. B. folgendes vor:

- Intel Xeon E5430 Quad Core mit 2,66 Ghz

- 300 GB SAS Platten (15.000 RPM)

- 8 GB Ram

 

Okay, ihr setzt also eine Konfiguration ein die in jeder Hinsicht schlechter ist als das was euch der Software-Hersteller empfiehlt, und wundert euch dann über miese Performance?

 

Ok, die SAS Platten drehen i. d. R. schneller (15.000 Umdrehungen statt 7.200), aber vom Interface selbst nehmen sich beide Technologien nicht viel, oder?

 

Das Interface ist physikalisch dasselbe, der Befehlssatz jedoch nicht.

 

Bei Datenbanken geht es nicht um Sequential Write/Read (wofür die grossen SATA-Platten optimal sind), sondern um eine möglichst hohe Anzahl IO-Operationen pro Sekunde (IOPS) - je geringer die Rotational Latency ist (d.h. desto schneller die Umdrehungszahl der Platte) desto mehr IOPS sind möglich.

 

SAS Platten sind für den Hochgeschwindigkeitsbetrieb in Servern ausgelegt. Im Firmenumfeld eigenen SATA-Platten für Fat-Clients und z.B. als Speicher auf den primär Sequentiell von nur sehr wenigen Quellen zugegriffen wird, z.B. Backups.

 

Wir haben übrigens ein Software Raid in dem Server.

Wieviel Leistungseinbusen müssen wir deshalb in Kauf nehmen?

In erster Linie wird dadurch ja der Prozessor belastet, der bei uns ja noch Luft nach oben hat ...

 

Software-RAID ist Gebastel. Gut vielleicht für ein Datengrab zuhause oder einen Testserver im Keller, aber nicht für den produktiven Betrieb einer Datenbank in der Firma.

 

Memory hilft in einem SQL-Server im übrigen nichts wenn geschrieben werden muss - synchrone Writes können vom OS nicht gecacht werden (HW-RAID Controller mit BBU können dies aber).

 

Verwende Qualitätshardware von einem renommierten Hersteller (IBM, HP, Dell) und size diese gemäss den Spezifikationen des jeweiligen Softwareherstellers (und eigenen Erfahrungswerten). Dann wirst du in Zukunft nicht mehr in solche Probleme hineinlaufen.

[Dukel 436]

Hallo,

[...]

Um zum Thema Festplatten zu kommen:

Warum sind S-ATA Platten für einen Datenbank Server so viel schlechter geeignet als SAS Platten?

Ok, die SAS Platten drehen i. d. R. schneller (15.000 Umdrehungen statt 7.200), aber vom Interface selbst nehmen sich beide Technologien nicht viel, oder?

[...]

Danke für euer Feedback. ;)

 

Galileo Computing :: Windows Server 2008 – 3.6 Dimensionierung und Performance