Nach Umstieg von lokaler Installation auf SmartIT haben sich die Mitarbeiterinnen auch bei mir beschwert, dass es langsamer als vorher ist. Mein Hinweis, dass die 4 Kerne eines Xeon Gold 6148 der in der SmartIT-Umgebung zur Verfügung steht nicht mal den Datevempfehlungen für einen Terminalserver entspricht (2 x Xeon Gold 6128, also 2 x 6 Kerne mit 3,7 GHz all-Core-Turbo Boost) und ich nicht sagen kann, wie es auf dem Virtualisierungshost aussieht und ob da überhaupt Turbo Boost aktiviert ist oder ob HyperThreading in Betracht zu ziehen ist, verhallte in der Kanzlei natürlich. Habe das dann an den SmartIT-Support weitergeleitet, die wie - schon mal auf eine Anfrage der Kanzlei ohne mich dazwischenzuschalten - erst einmal die Schuld auf den Client schieben wollten. In einer Terminalserverumgebung, wo der Client ja nur anzeigt (und sich so nebenher gesagt mit der RDP-Session früher und dem neuen mülligen Citrix-kram eh langweilt, wenigstens RDP überträgt ja nur Deltainformationen zum vorhergehenden Bild). Irgendwann seit dem 07.10. haben sie dann einen Xeon Gold 6342 zugewiesen (jedenfalls meint das der Taskmanager, mehr Informationen habe ich ja als Kunde bei Datev nicht), aber der Perfomance war das auch nicht wirklich weiter zuträglich, im täglichen Arbeiten bekomme ich das Feedback ist es nicht wirklich schneller geworden und auch eine Messung des Ladens eines Aktenvorblatts dauert noch so seine 4 bis 6 Sekunden wie vorher, wobei alle 4 Kerne auf Volllast spiken. Habe dann mal ein paar Messungen durchgeführt mit dem einzigen Messtool, das mir in der SmartIT-Umgebung zur Verfügung steht: 7zip. Am Donnerstag kurz vor Mitternacht lieferte mir die SmartIT-Umgebung folgendes, jeweils 1 Kern (4 Kerne) in GIPS: Komprimierung; Dekomprimierung 3,80 (12,797); 3,34 (12,37) Mein KVM-virtualisiertes Windows 10 auf einem Xeon E5-2697v3 mit ebenfalls 4 Kernen zugewiesen, ondemand-governor, Turbo Boost aktivert und HyperThreading deaktiviert (was man in virtualisierten Umgebungen eh machten sollte, in Cloud-Umgebungen machen muss) bringt das: Komprimierung; Dekomprimierung 5,12 (17,93); 5,09 (20,02) Dann das gleiche auf einer Windows 10-VM auf einem Xeon X5675 (der ist von 2010...) Komprimierung; Dekomprimierung 4,04 (14,20); 4,56 (17,60) Habe dann unter Linux mit der gleichen 7-zip 23.01 noch einige System direkt auf der Hardware durchgemessen, jeweils mit taskset -c 1-4 (und auf dem Xeon Gold 6354 zusätzlich noch mit numactl -N 0): Model: Komprimierung; Dekomprimierung X5675: 4,99 (17,86); 4,72 (18,73) E5-2640v3: 5,70 (20,74); 4,98 (19,87) (das war der alte Server der Kanzlei) E5-2697v3: 6,64 (22,42); 5,43 (21,46) Xeon Gold 6150: 7,14 (25,60); 6,05 (24,06) Xeon Gold 6354: 9,41 (34,39); 6,73 (26,88) Epyc 7713P: 9,81 (35,96); 7,85 (31,29) i5-12600K (ee): 5,65 (21,04); 5,59 (22,24) i5-12600K (hp): 11,64 (43,28); 8,56 (34,02) Und der Xeon Gold 6354 ist mit 18 Kernen und 3,6 GHz all-Core-Turbo Boost spezifiziert, der Xeon Gold 6342 soll auf 3,5 GHz maximalen Turbo Boost kommen. Klar, die Werte von Windows sind nicht eins zu eins mit denen unter Linux gemessenen zu vergleichen, aber dafür habe ich ja verschiedene Messungen durchgeführt. Ich konnte gestern Abend im SmartIT auch noch mal bessere 7zip-Werte herauskitzeln, aber auch nicht weit über 4,3 GIPS pro Kern. Ich denke, hier ist die Hardware entweder extrem overcommitted oder aber HyperThreading aktiviert. Auf jeden Fall ist dann auch klar, warum sich das für die Mitarbeiter langsam anfühlt, wenn die Grundperformance schon nicht stimmt. Ich weigere mich hier aber auch mehr zu machen, das ich diese Messwerte auch Datev zur Verfügung gestellt habe ist schon kostenlose Beratung obwohl ich (okay, der Kanzleiinhaber) deren Kunde bin und nicht wenig im Monat für das Angebot gezahlt wird (so in 10 Monaten alle 24 Kerne des Gold 6342, wenn ich das noch richtig im Kopf habe).
... Mehr anzeigen