MSSQL-Server - Wie CPU-Last analysieren?

[Dalai]

Hallo Leute :).

In diesem Thema geht es nicht um Programmierung mit MSSQL sondern um den MSSQL-Server selbst. Das Datenbank-Unterforum passt IMO trotzdem am besten; wenn nicht, dann bitte einfach verschieben.

Da ich weiß, dass einige Leute mit Datenbank-Erfahrung hier im Forum unterwegs sind - darunter bestimmt auch welche, die sich mit MSSQL auskennen, poste ich hier. [Crosspost bei Planet3DNow]

Vorab einige Infos zur Hard- und Software des fraglichen Systems:
AMD Epyc 7261
SuperMicro H11SSL-C
32 GiB RAM
Windows Server 2012 R2
MSSQL Server 2017 (mit CU12)
IIS
ERP-System, das auf Basis von .NET, IIS und MSSQL arbeitet
Hinweis: Das System hat bis auf zwei Domains keinen Internetzugang.

Das Problem stellt sich wie folgt dar: Nach ziemlich genau zwei Wochen Laufzeit des MSSQL-Servers verdoppelt sich die CPU-Last durch den SQL-Server-Prozess und das ändert sich auch mit längerer Laufzeit nicht mehr. Nun wäre ein möglicher Workaround, den MSSQL jedes Wochenende neu zu starten, aber ich würde gern versuchen, herauszufinden, was genau die CPU-Last verursacht.

[Hinweis: Bilder sind extern gelagert, weil DP nur 5 Dateien pro Post zulässt. Dummerweise werden offenbar auch IMG Tags weggefiltert, so dass es hier keine Thumbnails gibt.]
Graphen aus Munin for Windows:
processor by day (leicht unterschiedliche Skalierung)
Bild "processor-day_2019-075ok5v.png" anzeigen.
Bild "processor-day_2019-07h6j3t.png" anzeigen.
Bild "processor-day_2019-07qlk17.png" anzeigen.
processor by month
Bild "processor-month_2019-8kk1h.png" anzeigen.
Bild "processor-month_2019-mij5a.png" anzeigen.
Bild "processor-month_2019-ssksh.png" anzeigen.
Die Lastspitzen werden durch das zweimal wöchentliche Backup der MSSQL-DBs erzeugt.

Screenshots von ProcessHacker:
Bild "processhacker-generalepji2.png" anzeigen.
Bild "processhacker-performdwjny.png" anzeigen.
Bild "processhacker-statist6nkcm.png" anzeigen.
Bild "processhacker-threadsfsjrx.png" anzeigen.
Hier sieht man, dass sqlservr.exe permanent ~0,11% Last verursacht; aktuell sind es 0,15%. Nach einem Neustart des MSSQL ist dieser Wert - wie gesagt für zwei Wochen - irgendwo deutlich unter 0,05, IIRC meist 0,01%.
Außerdem ist ein hohes Cycles delta von ~40 Millionen für einen Thread erkennbar, bei einem Aktualisierungsintervall von 1 Sekunde; ich hab auch schon Cycles deltas von ~60 Millionen gesehen.

Der Aktivitätsmonitor im MSSQL Management Studio war keinerlei Hilfe, denn die sichtbaren lastverursachenden SQL-Statements waren nur die vom Aktivitätsmonitor selbst :roll:.

Nun könnte man natürlich sagen: "Was regt man sich über 1% CPU-Last auf", aber ich halte das Verhalten für nicht normal, wenn es zwei Wochen lang ohne diese Last funktioniert.

Gibt's unter den Lesern jemanden, der sich mit MSSQL auskennt und mir Tips geben kann, wie und wo man das anfangen kann zu analysieren?

Grüße
Dalai

[jobo]

Für jetzt und später:
Ich habe keine aktuelle, praktische Erfahrung mit MSSQL Servern.

Die Screenshots habe ich überflogen.
1. Problematik:
Ist sicher, dass der sqlserver die Last verursacht?
Bzw. welches der anderen genannten Programme (das ERP ist naheliegend) hat Zugriff auf den Server?


Idee:
moderne Datenbanken sind sehr bemüht, performant zu sein und zwar jederzeit und egal, was die Entwickler oder Admins für einen Blödsinn machen.
Moderne Datenbanken teilen sich in 2 Welten, bezahlte und unbezahlte.
Es gibt sehr gute unbezahlte Datenbanken, also warum Geld bezahlen?
Weil die bezahlten Systeme sich selbst optimieren.

An der Stelle würde ich anfangen zu suchen.
Selbstoptimierung einer DB hat meinetwegen mit smarten Optimizern angefangen und mit Statistiken über den Datenbestand. Das ist lange her.
Heute werden Profiles angelegt, Quotas gebastelt und ständig analysiert. Welches Statement läuft wie gut und vor allem, wann treten welche Lasten auf?
Gerne z.B. gemäß menschlicher Gewohnheit, tags wird gearbeitet und nachts geschlafen, ein idealer Zeitpunkt für eine DB, aufzuräumen, zu löschen, etc.
Einfacher, es gibt Businessabläufe, die zu bestimmten Tageszeiten bestimmte Fähigkeiten erfordern. Viele Daten löschen ist eine andere Anforderung als Replikate abgleichen oder Massenimport. Darauf stellen sich teure Systeme ein, zumindest bieten sie die Möglichkeit und dafür müssen sie selbst analysieren.

[Dalai]

Zitat:

Zitat von jobo (Beitrag 1437759)

1. Problematik:
Ist sicher, dass der sqlserver die Last verursacht?

Die Screenshots vom ProcessHacker zeigen das eindeutig, und ein Neustart des MSSQL lässt die Last sofort verschwinden.

Zitat:

Bzw. welches der anderen genannten Programme (das ERP ist naheliegend) hat Zugriff auf den Server?

Das ERP ist das einzige, was den MSSQL nutzt. Der Punkt ist, dass es zwei Wochen läuft, und dann geht innerhalb weniger Stunden die Last hoch. Das ERP wird unabhängig davon wochentags durch mehrere Leute benutzt.

Zitat:

Es gibt sehr gute unbezahlte Datenbanken, also warum Geld bezahlen?
Weil die bezahlten Systeme sich selbst optimieren.

Eine ständige CPU-Last, selbst wenn das ERP (und damit der SQL) nicht benutzt wird, werte ich keinesfalls als Optimierung sondern genau als Gegenteil.

Zitat:

Gerne z.B. gemäß menschlicher Gewohnheit, tags wird gearbeitet und nachts geschlafen, ein idealer Zeitpunkt für eine DB, aufzuräumen, zu löschen, etc.

Nur um nochmal die Graphen in Worte zu fassen: Die Last ist permanent und ziemlich konstant. Es gibt da keine Zyklen.

Mir geht es primär darum, wie und womit ich die Last analysieren kann, um herauszufinden, wodurch sie verusacht wird. Wenn sich herausstellt, dass es am ERP liegt, dann ist das halt so (und der o.g. Workaround wird benutzt werden).

Aufgrund der Zeitdauer von zwei Wochen bis zum Auftreten der Last kann ich auch nicht einfach eine VM aufsetzen, auf der nur der MSSQL installiert wird (und kein ERP), und den laufen lassen; abgesehen davon habe ich aktuell keine dafür geeignete Hardware.

Grüße
Dalai

[juergen]

Hallo,

das wird's vermutlich nicht sein, aber ist ein Wartungsplan eingerichtet?
Wir richten diesen eigentlich immer ein und führen dann wöchentlich/ monatlich die vorgegebenen Wartungen durch.

Evtl. hilft dir sowas weiter?
Es gibt wohl eine Testversion.

[Dalai]

Zitat:

Zitat von juergen (Beitrag 1437767)

das wird's vermutlich nicht sein, aber ist ein Wartungsplan eingerichtet?

Soweit ich das im SQL Management Studio unter Verwaltung > Wartungspläne sehe, ist da nichts definiert. Der SQL Server Agent ist außerdem deaktiviert; IIRC müsste der laufen, damit die Wartungspläne ausgeführt werden. Das Backup der DBs erfolgt nicht per Wartungsplan sondern per Skript, das in der Windows-Aufgabenplanung definiert ist.

Zitat:

Evtl. hilft dir sowas weiter?

Leider hab ich meine Zweifel. Der Aktivitätsmonitor im MSSQL MS war ja bereits ein Reinfall. Alles, was dort als abfrage-/CPU-intensiv zu sehen war, waren die Abfragen des Aktivitätsmonitors selbst sowie alle 5 (oder 10) Minuten das Abholen von eMails durch das ERP. Sicherlich werden Drittanbieter Performance-Analysetools weiter ins Detail gehen, aber ob das wirklich hilft? 14 Tage Testzeitraum ist auch nicht gerade hilfreich bei dieser Art von Problem...

Bislang hat sich auch noch keiner über die Performance des MSSQL beschwert. Dummerweise ist der Anbieter des ERP bislang keine Hilfe bei der Analyse; mein Eindruck ist, die nehmen den MSSQL so wie er ist und kümmern sich nicht weiter. Wobei ich nicht weiß, ob die Installation des ERP mehr als nur DBs im MSSQL anlegt und mit Demodaten befüllt; mit anderen Worten, es ist unklar, ob es irgendwelche Einstellungen am MSSQL vornimmt.

Versteht mich nicht falsch. Ich bin dankbar für jede Art von Hilfe. Aber auf gut Glück mit irgendeiner DB Performance-Analyse-Software rumspielen, ohne Ahnung, wonach ich suchen soll, ist nicht so mein Ding. Ich administriere den MSSQL nur, ich hab noch nie damit gearbeitet oder sonst Ahnung davon.

[EDIT]
Will sagen: Mir müsste schon jemand (der Ahnung hat) sagen, womit und wo ich gucken soll bzw. was ich genau tun soll, um dem Problem auf die Spur zu kommen.
[/EDIT]

Grüße
Dalai

[jobo]

Zitat:

Zitat von Dalai (Beitrag 1437769)

[EDIT]
Will sagen: Mir müsste schon jemand (der Ahnung hat) sagen, womit und wo ich gucken soll bzw. was ich genau tun soll, um dem Problem auf die Spur zu kommen.
[/EDIT]

Grüße
Dalai

Sorry, zu spät gelesen.

[Delphi.Narium]

Gibt es da eventuell für Dich hilfreiche Information? How to Monitor SQL Server

Kannst Du eventuell über dashier CPU and memory utilization within the date and time given an weitere, für Dich relevante, Informationen kommen?

Da ich keine Ahnung vom MSSQL-Server habe, würd' ich, wenn ich so wie Du vor 'nem Administrationsproblem stehe, so eine Abfrage bei Google machen mssql cpu last 2 weeks usage und versuchen, mir daraus irgendwie was wissenswertes zusammenzusuchen und dann daraus ggfls. 'ne eigene Lösung bauen.

Ja, ich weiß, dass das sehr aufwändig werden kann, musste aber zu meiner Administratorzeit öfter auf diesem oder ähnlichem Weg Problemlösungen für diverse Systeme finden. Nein, spaßig ist das nicht :-(

Irgendetwas, das klar sagt: "Mache dieses oder jenes", hab' ich leider nicht finden können :-(

[Dalai]

OK, danke. Das wird eine Weile dauern, das durchzugehen. Wusste bisher nicht, dass im Windows Performance Monitor auch Quellen vom MSSQL zu finden sind. Ich kann jetzt schon sagen, dass sowohl Ereignisprotokoll als auch Errorlog des MSSQL sauber sind (da hab ich natürlich zuerst geschaut).

Grüße
Dalai

[p80286]

Zunächst auch ich habe keine direkte Erfahrung mit dem SQL-Server.
Unsere DB-Admins haben für die in DE-Gehosteten Datenbanken immer einen Neustart von 3.00 bis 4.00 in den Verfügbarkeitspänen gehabt. Enzig die DBs die auch für Ostasien verfügbar sein mußten hatten ihren Restart gegen 8.00 was aber nur zähneknirschend akzeptiert wurde. Soweit ich weiß benötigt die DB einen Neustart um die erarbeiteten Optimierungen dauerhaft verfügbar zu haben, was aber von DB zu DB unterschiedlich ist. Ich meine auch einmal gehört zu haben, daß es DB(Konfigurationen) gibt die 247-taglich sind, was aber durch den Parallelbetrieb von zwei phys.DB erreicht wird.

Aber wie gesagt, nimm es als Anregung in welcher Richtung Du nachschauen mußt.

Gruß
K-H

[TigerLilly]

Wie unten schon erwähnt, schau dir im Windows Performance Monitor an, woher die Last, die der SQL Server erzeugt, tatsächlich herkommt.
Siehe auch hier: https://www.mssqltips.com/sqlservert...or-sql-server/

Konzentriere dich nicht nur auf die Kennzahlen des SQL Servers, sondern nimm den Server selbst auch dazu.

Dann weißt du, in welchem Bereich du weitersuchen musst.

BTW: Was für eine Hardware und welche Versionsstände sind denn das?

[Dalai]

Zitat:

Zitat von TigerLilly (Beitrag 1438140)

BTW: Was für eine Hardware und welche Versionsstände sind denn das?

Siehe ganz oben im OP.

Grüße
Dalai

[TigerLilly]

Ach ja, stimmt. Danke.

Das Neustarten ist eine Unsitte und meiner Erfahrung nach bei einem sauberen System nicht notwendig.

Lass dir im PerformaceMonitor zusätzlich zu den Einträgen aus meinem Link unten diese Werte anzeigen:
Memory – Available MBytes
Physical Disk – Avg. Disk sec/Read
Physical Disk – Avg. Disk sec/Write
Physical Disk – Disk Reads/sec
Physical Disk – Disk Writes/sec
Processor – % Processor Time
System – Processor Queue Length

Siehe auch hier:
http://www.appadmintools.com/documen...ers-explained/
https://www.brentozar.com/archive/20...rmance-tuning/

Alle, bei denen sich im fraglichen Zeitraum nichts tut, lass dann wieder weg.
Starte die protokollierung und stell die Salierung der zeitachse so, dass du ein paar Wochen im Überblick hast. Skaliere die einzelnen Counter passend. Das dauert ein bissl, bis alles passt, aber dann lass das fortwährend laufen und du kannst gut beobachten.

Du kannst auch im SQL Profiler einen Trace starten und über einen Filter die Abfragen des Profilers ausblenden. Aber das würde ich vorerst nicht machen. Immer nur eine Sache auf einmal beobachten. Sonst gibt es Seiteneffekte.

Dazu passend: Wenn du das System überwachst, solltest du außer zuschauen natürlich nichts drauf tun.

Lass hören, wenn du weitere Infos hast.

[p80286]

Zitat:

Zitat von TigerLilly (Beitrag 1438238)

Das Neustarten ist eine Unsitte und meiner Erfahrung nach bei einem sauberen System nicht notwendig.

Damit ich nicht dumm sterben muß, was heißt "unsitte"?
Das haben wir schon immer so gemacht, war vor 10 Jahren notwendig, ......

Ich geh mal davon aus, unsere Admins wußten was sie tun?

Gruß
K-H

[TigerLilly]

Zitat:

Das haben wir schon immer so gemacht, war vor 10 Jahren notwendig, ......

Genügt das als Info?

Im Ernst: Es gibt Situationen, wo man den Server neu starten MUSS (Portänderungen, Hotfix/Update, TempDB zu groß), aber sonst ist es besser, den Server NICHT neu zu starten. Alle Daten und Prozedur-Caches ect würden geleert und die Performance leidet, bis sich alles wieder eingepegelt hat.

[hoika]

Hallo,
zumal man auch mal Windows-Updates installieren muss,
die idR einen Neustart erfordern.

[jobo]

Nein, in der Regel erfordert ein Update keinen Neustart mehr. Das war vielleicht noch bei Windows 7 die Regel, wenn überhaupt.
Es hat natürlich auch was damit zu tun, wieviel Software und Dienste auf einem System installiert sind. Das sollten im 24/7 Systemen relativ wenig sein.

[HolgerX]

Hmm..

Zitat:

Zitat von jobo (Beitrag 1438351)

Nein, in der Regel erfordert ein Update keinen Neustart mehr. Das war vielleicht noch bei Windows 7 die Regel, wenn überhaupt.

Hatten diese 'Zwagsneustarts' nicht gerade mit Windows 10 und dessen Serverderivat mit den 'Upgrades' wieder Einzug gehalten? ;)
(LTS hierbei unberücksichtigt)

Und auch Windows-Server müssen bei einigen Update neu gestartet werden, spätestens wenn die (wie heute meist üblich) als VM implementiert sind und dessen Host nen Update erhalten hat... ;)

[TigerLilly]

Was ich sagen wollte: Es ist NICHT notwendig den Rechner oder den SQL-Server-Dienst als Wartungsmaßnahme rgelmäßig neu zu starten.