Profitiert Lohn und Gehalt von mehr CPU-Kernen?

[#1]

Ein Kunde rechnet mit LuG 2.000 Mitarbeiter pro Monat ab, d.h. die Lohnabrechnungen selbst dauern ca. 1h, der Monatsabschluss ca. 1,5-2h

Der Host ist ein XEON Gold mit 2,8 GHz und der VM sind acht Kerne zugewiesen, Full SSD auf Fileserver + WTS sowie ausreichend RAM verstehen sich von selbst.

Frage: Würden mehr Kerne hier einen signifikanten Leistungsschub bringen oder ist LuG hinsichtlich Multicoreperformance eher schlecht optimiert?

[#2]

Parallele Lohnabrechnung in Lohn und Gehalt Leider steht nicht dabei, wie viele Kerne maximal unterstützt werden. Das kann man als Feedback an den Autor mal weiter geben 👍. DATEV schreibt nur: ab 2 Kerne 🙄. Wie lange gibt es schon CPUs mit 2 Kernen oder HT Technologie, die dem OS 2 Kerne vorgaukeln? 

Heute sind wir bei 128 Kernen / 256 Threads angekommen 😎. 

Der DATEV SQL Server nutzt auch nur maximal 8 Kerne, wenn dem OS 16 zugewiesen sind. 

[#3]

Danke für den Hinweis, irgendwas hatte ich nämlich auch im Hinterkopf.

Scheint ja standardmäßig bereits aktiv zu sein und bezieht sich leider nur auf die Lohnabrechnungen selbst, d.h. die Probeabrechnungen und der noch zeitintensivere Monatsabschluss bleiben weiterhin langsam.

[#4]

Hallo stka,

neben der offensichtlich begrenzten Ausnutzung mehrerer Prozessoren durch das Programm sollte man ggf. auch prüfen, ob die Virtualisierung bei so vielen Kernen sich selbst bremst.

Falls beispielsweise Fileserver und WTS auf einem Host liegen, kann es (abhängig von Virtualisierungslösung, Anzahl und Ausstattung der VMs sowie Host-Hardware) vorkommen, dass die sich gegenseitig ausbremsen (z.B. wenn beide viele Kerne haben und Speicher außerhalb des primären Numa-Nodes liegt).

Stichwort: Verfügbarkeit der Anzahl der Kerne, Virtualisierungs-Verwaltung, Numa-Knoten ...

Kann nur bestätigen, dass ich VMs hatte, die mit 2 Kernen letztlich ähnlich schnell wie mit 4 Kernen liefen. Es wurde auch schon von deutlichen Performance-Steigerungen bei weniger Kernen berichtet ....

Vorschlag: Beim Abrechnen von L&G mal im Taskmanager oder im Virtualisierungsmanagement prüfen, wo die Auslastung liegt.

Ein letzter Hinweis (z.B. VM-Ware): Wenn man im Bios des Hosts die Energieeinstellungen optimiert und durch den Hypervisor steuern lässt, kann der Turbo-Takt der Prozessoren genutzt werden (im Schnitt Takt 1,5 fach). Dies erfordert jedoch, dass angrenzende Kerne leer laufen. Der Hypervisor schaltet dann typischerweise zwischen diesen um. Dies kann zu deutlichen Performancesteigerungen führen.

Umgekehrt bremst ein aktiviertes Energiemanagement durch den Host in Standardeinstellungen die Performance  i.d.R. maximal. Gehe aber davon aus, dass dies bei Ihnen nicht der Fall ist.

[#5]

Auch wenn es abhängig von der bisherigen Umgebung ein ziemlicher Handstand wäre, könnte man ja vielleicht sogar in Betracht ziehen, neben dem WTS einen zusätzlichen Rechner mit einem hochgetakteten Prozessor hinzustellen. Da reden wir ja von ganz anderen Basis und Turbotakten als bei bezahlbaren Xeons. Der i5-10600KF taktet beispielsweise bei 6C/12T bei 4.10-4,8 GHz.

[#6]

Und was DATEV in Bezug auf Virtualisierung auch nicht schreibt; es aber vom SQL Express bekannt ist, wenn man Hosts mit mehr als 1 physikalischen CPU nutzt: Geht es wirklich nur um Kerne oder auch CPUs?

Ich kann der VM ja 1 CPU mit 4 Kernen zuweisen oder 2 CPUs mit jeweils 2 Kernen. Macht beim Express einen riesen Unterschied, weil der SQL Express auf 1 CPU limitiert ist und statt der 4 Kerne dann nur effektiv 2 nutzen kann, weil die 2 der anderen vCPU gar nicht beachtet werden. Habe ich live erlebt - war sehr interessant 😎. Beim SQL Standard ist das wieder anders. Der unterstützt mehrere CPU Sockel.

@DATEV: Was ist in Eurer Software hier von Vorteil? 

[#7]

Hallo @stka, hallo @metalposaunist ,

habe zur Info den neuen Thread Virtualisierung Energieeinstellungen VMWare angelegt, in dem ich mal unsere Erfahrung mit den Energieeinstellungen aufgeführt haben.

Ich fand das mit dem Turbotakt (der bei Max-Performance wohl nicht mehr aktivierbar ist) sehr interessant.

Viele Grüße

[#8]

Soweit ich es richtig verstanden habe, sollten entgegen der früheren "Best Practise: jeder Kern ein Socket" generell eher mehrere Kerne pro Socket vergeben werden (aber natürlich nicht mehr als die einzelnen Host-CPUs an Kernen haben - sonst wieder Problem mit Numa..).

Bestimmte Systeme (Stichtwort Nichtserver-Windows) nutzen auch nur ein Socket (falls mehrere, dann ggf. verschwendet).

Ja das mit den vCPUs und deren Konfiguration ist in der Tat ein manchmal mystisch wirkendes durchaus mit Überraschungen und vermeintlich unlogischen Reaktionen verbundenes Thema.

[#9]

@stka 

Für den Lohn würde ich eine extra Kiste daneben stellen.

Es kann ja auch mal Korrekturen mit nochmaligen Abschluss geben usw.

Da wird man ja nie fertig..

Für 27 MA mit Abrechnung und Monatsabschluss habe ich gerade etwa 1 Minute gebraucht.. 12 Kerne, 20 Threads. Hat aber nicht ausgelastet ausgesehen...

[#10]

Hallo metalposaunist,

leider etwas spät aber wir haben 2 Infos:

Es wurde gesagt: Der DATEV SQL Server nutzt auch nur maximal 8 Kerne, wenn dem OS 16 zugewiesen sind

=> 

Da liegt möglicherweise ein Missverständnis vor:

Das Dokument 1014224 wurde um ein Kapitel ergänzt:

Kapitel 4 Einstellung Max Degree of Parallelism (MDOP) ändern

… Max Degree of Parallelism (MDOP-Wert) gibt an, wie viele physische//virtuelle CPU-Kerne ein SQL-Task nutzen kann, „gedeckelt“ wurde das auf maximal 8 auch wenn z.B. 32 Cores vorhanden sind.

Der SQL Server Standard selbst nutzt mehr als 8 Cores: maximal 4 Sockets bei maximal 24 Cores. 

Es wurde gefragt: 

Und was DATEV in Bezug auf Virtualisierung auch nicht schreibt ....

=>

Wir haben im Dokument 1080080 eine Ergänzung vorgenommen:
2.1.3.2 Prozessorsockel (Sockets) zuweisen

Danke für den Hinweis!

[#11]

@Stefan_Hoesch 

Vielen Dank für Ihre Informationen zum MSSQL, das war eine Hälfte der Antwort. Die zweite Hälfte ist jedoch die spannende Frage wie LuG die SQL Statements absetzt und verarbeitet. Jede AN Abrechnung besteht ja aus recht vielen Abfragen (die pro AN zwar immer gleich sind aber unterschiedliche Ergebnisse liefern, was in der Natur der Sache liegt). Also bleibt die spannende Frage doch wie viele AN die Programmlogik von LuG überhaupt gleichzeitig bearbeiten kann und ob sich durch mehr Kerne oder Speicher die Zeiten verbessern lassen.

Meine Leistungsmessungen auf dem Datenbankserver lassen keine Leistungsspitzen bei Probeabrechnungen größerer Mandate erkennen (höherer Pakettraffic bei SQL Anfragen und Antworten sind ausgenommen, sind ja auch eine andere Baustelle).

[#12]

---

@Stefan_Hoesch schrieb:

„gedeckelt“ wurde das auf maximal 8 auch wenn z.B. 32 Cores vorhanden sind.

---

Kann man da händisch ✋ eingreifen oder ist das hard codiert?

Frage wegen der allgemeinen Entwicklung: AMD Epyc 8004/9004: Neue Bezeichnungen für CPUs mit bis zu 128 Kernen

Und was macht man dann mit min. 120 anderen Kernen? 😂

[#13]

Ich gebe einfach mal meinen Senf dazu, auch wenn ich von der Technik keine Ahnung habe.

Wir nutzen LuG im Datev-ASP-Umfeld und rechnen Mandate mit bis zu 300 Arbeitnehmern ab. Die Laufzeiten bei den Probeabrechnungen und auch beim Monatsabschluss sind bei Mandanten Ü100 Abrechnungen schon nicht ohne. Gestoppt habe ich noch nicht, aber über 30 Min. würde ich schon mindestens veranschlagen.

Die endgültige Abrechnung geht schneller. Ich würde hier fast darauf tippen, dass sich was von der Probeabrechnung "gemerkt" wird, wenn so etwas geht. Da ich bei den Großen immer zuerst verprobe, ist es tatsächlich ein Tipp, da es ja seien könnte, dass das Programm bei einer endgültigen Abrechnung immer schneller rechnen kann.

Ich habe auch irgendwie eine maximale Abrechnungsanzahl für LuG als Empfehlung von der Datev im Kopf, weiß aber nicht mehr wie hoch die Anzahl war.

Grundsätzlich tippe ich aber darauf, dass es nicht am Rechner sondern an der Software liegt. Lohn ist ja in den Berechnungen doch ziemlich komplex...

...aber ich bin bei Technik nur Laie.

[#14]

Losgelöst von genügend CPU Cores für den Terminalserver sollte auch die RZ Kommunikation aufgeräumt sein.

Performance verbessern in Lohn und Gehalt classic / comfort / compact