SQL 2012 optimieren wie?
Hallo,
wir haben einen SQL Server Typ Microsoft 2012 auf einem Windows 2012 Server laufen.
In der SQL sind 3 Datenbanken die 3 verschiedene Programme benutzen. Das Datenbankverzeichnis ist auf C: auf einer SSD im Raid 1 Verbund. Die Programme starten alle von Laufwerk D: dort sind 4 7.2K SAS Platten im Verbund als Raid 10.
Als CPU sind 2 Prozessoren mit je 6 Kernen a 2,93GHz. Dazu hat das System 144GB Arbeitspeicher. Der Server ist mit 4GBit am Switch per Lastenausgleich angebunden.
Wir hatten vorher im System statt SSD 4x 15K Festplatten als Raid10 im System und nur 32GB Arbeitsspeicher. Am Arbeitsplatz von dem ich die Programme aufrufe hat sich an Geschwindigkeit nicht geändert, dass eine Programm, was eine Datenbank nutzt, braucht noch genau so lange bis es voll genutzt werden kann wie vorher.
Ich hatte hier aus einen alten Betrag was gelesen von Arbeitsspeicher würde was bringen.
Aktuell werden 18GB von 144GB Arbeitsspeicher genutzt, dies ist aber nur so viel, da 3 VM's laufen, die Arbeitsspeicher zugewiesen haben bekommen.
Mit freundlichen Grüßen
wir haben einen SQL Server Typ Microsoft 2012 auf einem Windows 2012 Server laufen.
In der SQL sind 3 Datenbanken die 3 verschiedene Programme benutzen. Das Datenbankverzeichnis ist auf C: auf einer SSD im Raid 1 Verbund. Die Programme starten alle von Laufwerk D: dort sind 4 7.2K SAS Platten im Verbund als Raid 10.
Als CPU sind 2 Prozessoren mit je 6 Kernen a 2,93GHz. Dazu hat das System 144GB Arbeitspeicher. Der Server ist mit 4GBit am Switch per Lastenausgleich angebunden.
Wir hatten vorher im System statt SSD 4x 15K Festplatten als Raid10 im System und nur 32GB Arbeitsspeicher. Am Arbeitsplatz von dem ich die Programme aufrufe hat sich an Geschwindigkeit nicht geändert, dass eine Programm, was eine Datenbank nutzt, braucht noch genau so lange bis es voll genutzt werden kann wie vorher.
Ich hatte hier aus einen alten Betrag was gelesen von Arbeitsspeicher würde was bringen.
Aktuell werden 18GB von 144GB Arbeitsspeicher genutzt, dies ist aber nur so viel, da 3 VM's laufen, die Arbeitsspeicher zugewiesen haben bekommen.
Mit freundlichen Grüßen
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 299784
Url: https://administrator.de/contentid/299784
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
6 Kommentare
Neuester Kommentar
Also.... du solltest erstmal wissen, was auf dem System so los ist.
Es gibt ganz unterschiedliche Verwendungen.... Gewichtungen zwischen lesenden und schreibenden Operationen etc., CPU lastige Anwendungen, IO-lastige Anwendungen, welche die 99% lesend und 1% schreibend arbeiten etc
1.) guck dir die Cache hit Ratio an - ist im Perfmon beim SQL Server buffer manager zu finden. Dann weißt du ob viel Ram überhaupt hilft. Sollte > 90% liegen, sonst steigen die physischen Diskzugriffe an.
2.) schau dir an wieviel Speicher die SQL Server.exe nutzt. Ich hatte neulich mal 7 GB auf nem Server gesehen, auf dem der Prozeß sich beliebig viel Speicher nehmen könnte.... von 64 GB. Also da blieb viel Speicher ungenutzt.
3.) konfigurier den Server so daß er auf gar keinen Fall mehr als den physischen Arbeitsspeicher - 2 GB beansprucht. DAnn gibts Paging.
4.) schau dir die CPU Auslastung an... im SAP gibts Queries die laufen eine Woche auf 12 CPUs, in Webshops gibts Stored Procedures mit 100 ms Laufzeit und 0 CPU Last
5.) last but not least da du phyissche Platten hast: schau dir im Perfmon die Physical disk: avg disk read queue length, Write queue length und SQLSERVER:transactions" an. Die Disk Queues ollten normalerweise auf 0 sein. Sollten die ab einer bestimmten Anzahl von transactions pro Sekunde steil nach oben anwachen und dort nicht nur für ein paar Sekunden bleiben dann ist das System IO-überlastet und da hilft nur noch ein SSD Array oder ein potentes SAN weiter.
Ach ja last but not least - bei stark schreibenden Anwendungen mutieren die Indizes gerne mal bis hin zu 99% Fragmentierung. Prüf das mal und guck ob da
a) der Wartungsplanagent überhaupt läuft
b) ein Index Rebuild oder Index reorganize drinne ist-.
Es gibt ganz unterschiedliche Verwendungen.... Gewichtungen zwischen lesenden und schreibenden Operationen etc., CPU lastige Anwendungen, IO-lastige Anwendungen, welche die 99% lesend und 1% schreibend arbeiten etc
1.) guck dir die Cache hit Ratio an - ist im Perfmon beim SQL Server buffer manager zu finden. Dann weißt du ob viel Ram überhaupt hilft. Sollte > 90% liegen, sonst steigen die physischen Diskzugriffe an.
2.) schau dir an wieviel Speicher die SQL Server.exe nutzt. Ich hatte neulich mal 7 GB auf nem Server gesehen, auf dem der Prozeß sich beliebig viel Speicher nehmen könnte.... von 64 GB. Also da blieb viel Speicher ungenutzt.
3.) konfigurier den Server so daß er auf gar keinen Fall mehr als den physischen Arbeitsspeicher - 2 GB beansprucht. DAnn gibts Paging.
4.) schau dir die CPU Auslastung an... im SAP gibts Queries die laufen eine Woche auf 12 CPUs, in Webshops gibts Stored Procedures mit 100 ms Laufzeit und 0 CPU Last
5.) last but not least da du phyissche Platten hast: schau dir im Perfmon die Physical disk: avg disk read queue length, Write queue length und SQLSERVER:transactions" an. Die Disk Queues ollten normalerweise auf 0 sein. Sollten die ab einer bestimmten Anzahl von transactions pro Sekunde steil nach oben anwachen und dort nicht nur für ein paar Sekunden bleiben dann ist das System IO-überlastet und da hilft nur noch ein SSD Array oder ein potentes SAN weiter.
Ach ja last but not least - bei stark schreibenden Anwendungen mutieren die Indizes gerne mal bis hin zu 99% Fragmentierung. Prüf das mal und guck ob da
a) der Wartungsplanagent überhaupt läuft
b) ein Index Rebuild oder Index reorganize drinne ist-.
1 und 5: Schonmal was von Perfmon.exe gehört?
2: Als SQL Admin sollte man wissen, das man den SQL Speicherverbrauch nicht im TaskManager nachguckt. Der zeigt nämlich fast alles was der SQL Server nimmt nicht an. Auch hier: Perfmon.exe
3: Die SQL Standard Edition nimmt eh nicht mehr als 64GB: https://msdn.microsoft.com/de-de/library/ff642522(v=sql.110).aspx
2: Als SQL Admin sollte man wissen, das man den SQL Speicherverbrauch nicht im TaskManager nachguckt. Der zeigt nämlich fast alles was der SQL Server nimmt nicht an. Auch hier: Perfmon.exe
3: Die SQL Standard Edition nimmt eh nicht mehr als 64GB: https://msdn.microsoft.com/de-de/library/ff642522(v=sql.110).aspx
Wir hatten vorher im System statt SSD 4x 15K Festplatten als Raid10 im System und nur 32GB Arbeitsspeicher. Am Arbeitsplatz von dem ich die Programme aufrufe hat sich an Geschwindigkeit nicht geändert, dass eine Programm, was eine Datenbank nutzt, braucht noch genau so lange bis es voll genutzt werden kann wie vorher.
Moin,
verstehe ich das richtig, dass es um die Startzeit des Programms geht ? Dafür ist nicht nur der SQL-Server verantwortlich. Je nachdem, wie die Software so gestrickt ist, wird da noch haufenweise Zeugs abseits des SQL-Servers geladen.
Schon mal probehalber am Client eine SSD eingebaut und das Programm dorthin installiert ?
Gruß
Bernhard