Performance SQL- Server

[#1]

sind das screenshots vom fileserver?

[#2]

Der Server ist der DATEV- File- SQL- Server ohne weitere Aufgaben.
Rewe läuft auf einem Clienten mit i7- Prozessor, der ber der Aktion NULL- Auslastung zeigt.

der Client hat einfach eine Mist- Abfrage gesendet, ohne ordentliche Indexe zu nutzen.
Da braucht der beste Server Ewigkeiten, wenn aufgrund schlampiger Programmierung zig Tausende von Datensätzen durchwühlt werden müssen.

[#3]

Da braucht der beste Server Ewigkeiten, wenn aufgrund schlampiger Programmierung zig Tausende von Datensätzen durchwühlt werden müssen.

ja gut.. kann man sich drüber streiten.

hab den prozessor glaub im kommserver. egal.. 

ram-auslastung scheint mir auch zu gering. wann wurde der das letzte mal neu gestartet?

ach.. steht ja da.

10 Minuten für den klapprigen prozess..

[#4]

Zeigt doch sehr schön, warum DATEV bis heute auf den Single Thread Wert pocht 😉. Wenn der 1 Kern lahm ist, ist das bei 63 anderen möglichen Kernen auch keine Hilfe. 

[#5]

Irgendwie macht es Sinn, daß eine einzelne ReWe- Anfrage auch nur einen Kern bekommt.
So bremst diese wohl sequentiell programmierte Last nicht den Rest der Kanzlei aus.
Wir kennen das lokale ViWs, welches alle Kerne des Clienten gleichzeitig auf 100% fährt. Viel Spaß beim Arbeiten. 

Mehr als 2 Kerne auf dem Fileserver wird kein Anwender gleichzeitig belegen. 
Damit sind 12- Kerner mit hoher Taktfrequent für den SQL- Server durchaus optimal.

[#6]

Bloß geht die Entwicklung eher in die Richtung, mehr Kerne statt mehr Takt. Deshalb lässt sich Intel ja die Gold CPUs mit > 3GHz und wenigen Kernen gut bezahlen. Total untypisch im Rechenzentrum. Die Kanzlei ist auch nur ein Rechenzentrum im micro-Format. 

AMD hat eine CPU mit 128 Kernen vorgestellt. DATEV zieht dann 1 davon. Toll. Und was macht man mit dem Rest? 😂

Die CPUs werden nur durch die Anzahl der Kerne schneller, weil mehr parallel berechnet werden kann. Wenn DATEV da noch lange auf dem SingleThread rumreitet - der ist jetzt schon nicht mehr arg gestiegen. Erst mit den neuen AMDs wieder aber das Ziel ist das eigentlich nicht. 

---

@martinkolberg schrieb:

Wir kennen das lokale ViWs, welches alle Kerne des Clienten gleichzeitig auf 100% fährt.

---

Wenn dadurch die Aufgabe schneller bearbeitet werden kann, ist das doch OK? Besser so, als wenn ich x Minuten auf Aufgabe A warten muss, aber ich zumindest in der Zeit B tun kann? Hm. Und wenn das so krass der Fall ist, ist da auch was falsch in der Programmierung in meinen Augen. 

---

@martinkolberg schrieb:

Irgendwie macht es Sinn, daß eine einzelne ReWe- Anfrage auch nur einen Kern bekommt.

---

Dann aber nicht beschweren, wenn DATEV eben mal > 10min für amazon braucht 😉.  

[#7]

@metalposaunist 

Bei DATEV ist der MSSQL Server ein reines Datenspeichermedium, der macht gar nichts außer ein paar Speicherbewegungen. Die Abfragen, die an den SQL Server geleitet werden sollten nur nicht auf den Prozessor 0 kommen, hier werden in der Regel die IRQs bearbeitet und damit der SQL Thread immer wieder unterbrochen.

Da DATEV Software immer die geamten Daten auf den Client zieht (siehe @zippo in der alten Newsgroup zum Thema Arbeitsplatz) bestimmt der Client auch die Auswertungsgeschwindigkeit - und genau hier bestimmt dann die Auslastung der CPU die Verarbeitungszeit. Laufen, wie auf einem Remote Desktop Server, viele unterschiedliche Threads steigen auch die Zeitscheiben, die die CPU zu versorgen hat. Der Wechsel der Threads kostet auch so seine Zeit. Nun steht am Ende GHz gegen Kerne und wieviel CPU Zeit durch den Wechsel verbraten wird. Manchmal gewinnt die lahme CPU mit wenig Wechseln.

Der Mist an der Sache ist MS, dort wurde erkannt, dass sich Kerne besser lizenzieren lassen als Sockel und dann stellt sich wieder die dämliche Frage was nun optimaler ist.

[#8]

Hi,

---

@martinkolberg schrieb: Mehr als 2 Kerne auf dem Fileserver wird kein Anwender gleichzeitig belegen. 

---

Jaein.... 

1x Rechnungswesen

1x Auswertungen EO

1x DMS o.ä

ergeben dann durchaus 3 Kerne die belegt sind. 

Beste Grüße
Christian Ockenfels

[#9]

---

@metalposaunist schrieb: AMD hat eine CPU mit 128 Kernen vorgestellt. DATEV zieht dann 1 davon. Toll. Und was macht man mit dem Rest?

---

Den willste aber nicht mit einem Windows-Server lizenzieren... 

Aber, wenn ein Prozess nur einen Kern belegt, so what.... Die anderen Benutzer haben durchaus andere Prozesse, die dann auch vom SQL (teilweise) auf andere Kerne gelegt werden. 

Da skaliert der MS-SQL durchaus nach Prozessen bzw. die von dort angefragten SQL-Datenbanken.

Beste Grüße
Christian Ockenfels

[#10]

---

@münster schrieb: Bei DATEV ist der MSSQL Server ein reines Datenspeichermedium, der macht gar nichts außer ein paar Speicherbewegungen.

---

Das würde ich so nicht unterschreiben.

Insbesondere bei der EO kann ich durchaus behaupten, dass es so nicht ist. Die SQL-Abfragen werden vom Server ausgeführt und bearbeitet. Auch bei den Auswertungen ist zunächst der SQL belastet und übergibt dann an den Client. Und je nach Abfrage ist der Server erst einmal richtig im Stress (Bsp. Nachbewertung von LEA-Kostensätzen, die reinste Killeranwendung).

Bei DMS sieht es naturgemäß anders aus. Datei wird vom SQL angefordert auf den Client kopiert, Client führt aus. Warum: Word / Excel kann nun einmal keine Dateien direkt aus einem SQL-Speicher öffnen. Wird es auch nie können. Die Office-Anwendungen arbeiten immer im Dateisystem (von Outlook mal abgesehen... je nach Postfach).

Die allgemeine These, dass DATEV alles in "BLOB"-Felder der SQL-Datenbank schreibt, können wir seit Jahren also nicht mehr so stehen lassen.

Beste Grüße
Christian Ockenfels

[#11]

datev empfiehlt server cpus und nicht unbedingt workstation-cpus...

mal unabhängig von der "kern-geschwindigkeit".

bei uns sieht es z.B. so aus.. da haben die cpus etwas mehr cache usw.

die datenbanken liegen auf festplatten und das gerät ist schon etwas älter.. aber läuft ziemlich gut.

fast nach empfehlung der datev..

[#12]

---

@münster schrieb:

Da DATEV Software immer die geamten Daten auf den Client zieht

---

Aber doch nur zu Btrieve Zeiten, oder nicht 🤔?  

@Gelöschter Nutzer: 3,4GHz max aber die CPU dümpelt bei 1,xGHz rum? Ist das nicht das falsche Energieprofil? Tatsächlich konnte ich bestätigen, dass DATEV besser läuft, wenn die CPU immer mit max GHz läuft; egal, was gerade zu tun ist. 

[#13]

@metalposaunist 

das profil ist höchstleistung und cpu min100/max100. bios? speedstep? dont know.. läuft gut.

[#14]

---

@metalposaunist  schrieb:

---

@münster schrieb:

Da DATEV Software immer die geamten Daten auf den Client zieht

---

Aber doch nur zu Btrieve Zeiten, oder nicht 🤔?  

---

Btrieve wurde 1:1 auf SQL umgezogen. @zippo hat ja nun auch oft genug auf fehlende Suchen und Views hingewiesen. Der Verwendung von Filtern zeigt ja auch, dass keine Abfragen genutzt werden.

Alle Berechnungen, Sortierungen etc. werden vom Client vorgenommen - muss auch so sein. DATEV nutzt die NUKO für die Verwaltung der Userrechte, würde die SQL Datenbank diese selbst verwalten könnten StoredProcs und Views genutzt werden. Nutzt DATEV aber nicht, jede Anfrage auf den SQL wird zunächst auf die Rechte des Users geprüft, nicht umsonst kommen pro Sekunde so schön viele SQL Anfragen beim Server an und damit haben wir eine der wesentlichen Engpässe - die IRQs auf Prozessor 0.

Der Unterschied ist zu betrachten wenn Fibu Programme genutzt werden in denen die ganze Logik in der Datenbank läuft, @achilleus könnte sagen welche das ist. Der Hersteller hat vor vielen Jahren den Schuss auch nicht gehört und dadurch viele Kunden verloren.

[#15]

@metalposaunist 

tja.. ich habe bei dem "tollen" Wetter mal um diese Energiespareinstellungen gekümmert und das war mal gar nicht so einfach, dass Bios zum "stromverschwenden" zu bringen.

Ende vom Lied: der Start dauert sonst etwa 2,3 Sek und der Zugriffstest dauert irgendwas mit 1,x Sekunden.

Also das hat wirklich was rausgehauen..

Nächstes Problem: der Server wird bald 5 Jahre alt und müsste eigentlich (kein Support mehr) getauscht werden.

Wenn ich allerdings in die Singlethread-Performance Liste gehe und im Bereich Server-CPU's schaue (Gold, Silver usw.). ist das höchste der Gefühle ein Gold 6334 mit einem Wert von 2.600.

Kaum mehr als unsere jetzigen CPU's... also das nervt schon irgendwie, dass DATEV immer noch so auf Singlethread abfährt.

Geht sowas eigentlich?:

https://docs.microsoft.com/de-de/troubleshoot/sql/admin/support-network-database-files

DATEV-Datenbanken auf ein NAS ablegen? NTFS ist ja auch nicht das höchste der Gefühle..

[#16]

---

@Gelöschter Nutzer schrieb:

DATEV-Datenbanken auf ein NAS ablegen?

---

Kann man bestimmt. Hatte ich bei einem Kunden einmal so übernommen und 2 VMs gleichzeitig neu starten endete bei Server 2008 R2 mit einem Hänger beim Start. 

Das QNAP NAS war zwar mit 10Gbits Modulen ausgestattet und auch so an die Hosts per iSCSI angeschlossen aber wenn man dann 3,5" 7200rpm HDDs drin hat, die weder die Performance noch de IOPS schaffen ... Welcher Dienstleister sich das ausgedacht hat, gehört auch ins Gefängnis 😶. 

Ich meine gerade bei SQL sind IOPS wichtig. Aber das überlasse ich heute besser Experten, die sich um bestmögliche Hardware und Kommunikation untereinander kümmern. Ich bin mehr DATEV Software, Schnittstellen und Beratung. 

[#17]

bei iscsi sind wir ja auch wieder bei ntsf.

am schönsten wäre ja ein mainboard mit haufenweise nvme ssds, softwareraid1, robustes zsf-dateisystem, trim usw.

[#18]

@Gelöschter Nutzer,

was mich an den Teilen des Leistungstests wundert ist, dass die Zeiten für Festplatte und Datenzugriff gar nicht so unterschiedlich sind. Diese Parameter sind im laufenden Betrieb entscheidend, die Anderen spielen beim Programmstart eine Rolle.

Ein Aufrüsten beim Storage, egal ob fest mit dem Mainboard verbunden oder ein Storage Subsystem (NAS lassen wir mal außen vor), wird vermutlich nicht den gewünschten Effekt der "Schwuppdizität" (Erfinder des Begriffs war die Redaktion der ct) in Relation zum Preis erzielen.

Ein ZFS ist im Übrigen nicht das schnellste Dateisystem am Start, dafür aber sicher und sehr solide. MS bietet aber auch noch ReFS an, Probleme inklusive.

Ein NAS für die Datenbank, egal ob als File- oder Blockdevice, halte ich nicht für eine gute Idee. Zugriff über 2 Betriebssysteme mit allen Zicken der Protokolle? Für mich nicht.

[#19]

@münster 

was mich an den Teilen des Leistungstests wundert ist, dass die Zeiten für Festplatte und Datenzugriff gar nicht so unterschiedlich sind.

Ich habe keine lokalen Datenpfade.. ist wohl Zufall, dass die Werte nahe beieinander sind (und auch erst seitdem ich alle Sparfunktionen am FS abgestellt habe).

Ein NAS für die Datenbank, egal ob als File- oder Blockdevice, halte ich nicht für eine gute Idee. Zugriff über 2 Betriebssysteme mit allen Zicken der Protokolle? Für mich nicht.

ja, sehe ich nach einlesen langsam auch so.. schade.

[#20]

@Gelöschter Nutzer,

da hat ja nicht nur der Filer seine Finger drin, der Client (auch TerminalServer) hat ja auch so seine Belastung. Das Netzwerk spielt bei DATEV keine untergeordnete Rolle, da liegt ganz heftig Pakettraffic drauf. Jeder Zugriff auf die SQL Datenbank muss ja erst einmal über die Nuko, das bremst enorm da das nicht vom SQL Server nativ in der Datenbank abgearbeitet wird.

[#21]

@münster 

den zusammenhang verstehe ich gerade noch nicht :-).

Liegen deswegen die Werte nahe beieinander? der server bremst und deswegen ist der festplattentest nicht besser?

Es begrenzt einerseits das LAN und andererseits der Server.. der Client könnte mehr.

[#22]

---

@münster  schrieb:

da hat ja nicht nur der Filer seine Finger drin, der Client (auch TerminalServer) hat ja auch so seine Belastung. Das Netzwerk spielt bei DATEV keine untergeordnete Rolle, da liegt ganz heftig Pakettraffic drauf. Jeder Zugriff auf die SQL Datenbank muss ja erst einmal über die Nuko, das bremst enorm da das nicht vom SQL Server nativ in der Datenbank abgearbeitet wird.

---

SQL geht ja noch... Da werden nur Pakete generiert, wenn auch tatsächlich Aktion in den Anwendungen gestartet werden. 

Aber das RDP (Terminalserver) spuckt da ordentlich Pakete ins Netzwerk. Jede Mausbewegung löst Pakete aus... Und da kommt enorm was zusammen.

Wenn iSCSI zum Einsatz kommen soll, dann meines Erachtens nur in eigenen Netzwerken/Switchen. Allein schon aus Schutzgedanken heraus (Core-Netzwerk getrennt von Produktiv-Netz).

Beste Grüße
Christian Ockenfels