RAID Performance sehr schlecht

[zahni 587]

Und ich tipper weiter  auf  eine  ungeeignete physikalische RAM-Konfig  und/oder ungeeigneten HDDs und keine Schreibache  mit Batterie. 

Dann ist wohl auch  die Firmware veraltet. Die Kiste  (DL 580 G7) wurde sicher irgendwo "billig" als Gebraucht gekauft. So ein Teil kauft man sich nicht neu für ein paar Benutzer.

[webbies 10]

nein, es wurde nicht gebraucht gekauft, es ist ein Server, der aber schon entsprechend lange anderweitig im Betrieb ist und nun zusätzlich auch Datev bereitstellen soll :) Haben noch refurbished HDDs bei Also zu dem Modell gefunden, die werden wir jetzt erstmal verbauen um das Thema HDDs schonmal ausschließen zu können

[zahni 587]

Mhttps://mcl.de ist normalerweise eine gute Adresse für gebrauchtes HPE-Zeug.

[webbies 10]

danke, das ist ein guter Hinweis

[testperson 1.857]

Dagegen spricht, das der ja laut TO von Datev aufgesetzt wurde.

 

Ich vermute nach wie vor ein Problem mit der physischen Netzwerkkarte im Host.

 

Wäre nicht der Erste, wo nicht nur am Host das VMQ disabled werden müsste, sondern auch noch das Offloading auf der Karte der VM

Bei SQL kann man so nachweislich bis zum 10-fachen Durchsatz haben.

 

Aber alles nur Vermutung, müsste man halt einfach ausprobieren.

 

;)

 

Das wäre alles im weiter oben verlinkten Dok. 1014806 beschrieben ;)

Es fehlt im übrigen immer noch die Info, welche Energiesparpläne am Host bzw. in den VMs genutzt werden bzw. wie die "Performance Einstellungen" im BIOS sind.

 

Und welche Gründe sprechen gegen ein Out-Sourcing der DATEV Anwendungen?

[webbies 10]

Das Dokument 1014806 habe ich für die VMs durchgearbeitet, ist dies auch für den Host erforderlich? Die Energieoptionen stehen alle auf Höchstleistung. Die BIOS Einstellungen prüfe ich, wenn ich die Platte austausche. Mir ist aufgefallen, dass die VM mit den Daten eine Warnung ausgibt:

 

Für die folgende Komponente wurde durch Ihren Systempartner/ technischen Ansprechpartner oder DATEV Support eine Protokollierung aktiviert. Diese Einstellung weicht vom Standard ab  und kann zu Performanceproblemen führen.

Aktuelle Protokollierungsebene:      Verbose

Komponente:      API Call
Anwendung:       C:\PROGRAM FILES (X86)\DATEV\PROGRAMM\INSTALL\DATEV.INSTALLATION.SYNCHRONISATION.HOST.EXE

 

Wie kann man das auf die empfohlene Einstellung ändern?

 

In der TracingError Datei steh folgendes

 

[14.12.2017 09:02:46, Datev.Installation.Synchronisation.Agent.exe] Information: TraceLevel set from Error to Verbose by component API Call
Datev.Installation.Synchronisation.Agent.Program : Void Start().
[14.12.2017 09:02:47, Datev.Installation.Synchronisation.Agent.exe] Warning: There is no mapping for the category 'Datev.ConfigDB'.

bearbeitet 15. Dezember 2017 von webbies

[testperson 1.857]

AFAIK: Start -> Ausführen -> datevprodiag.exe -> Protokollierung verwalten.

[webbies 10]

hmm, da sind extrem viele Logs, auch viele mit verbose ... aber keiner der API Call heißt

[muenster 16]

Das ist ein Log des Installationsmanagers. Der Hinweis auf das fehlende Mapping zur Datev.ConfigDB macht mir an und für sich Sorgen. Hier jetzt weitere Hinweise zu geben wenn die grundlegenden DATEV Kenntnisse nicht gegeben sind halte ich für gefährlich. Ein örtlicher Systempartner der draufschaut wäre jetzt hilfreich. Die configDB ist nämlich ein Quell wahrer Freude, vor Allem wenn sie fehlerhafte Einträge hat.

[coshi 11]

Schalte die TCP Chimneys aus und dein Problem wird gelöst sein.

[djmaker 95]

Am 28.1.2018 um 05:29 schrieb coshi:

Schalte die TCP Chimneys aus und dein Problem wird gelöst sein.

 

Hmm, mit halbwegs aktuellen Treibern sollte das aber kein Problem darstellen. Für den TO: Stcihwort "netsh autotuning"

[coshi 11]

Konntest du dein Problem lösen?

Es wäre schön wenn du die Lösung für die Nachwelt kurz formulieren könntest.

[webbies 10]

Sorry, da das Thema für uns leider noch immer nicht abshließen zufriedenstellend gelöst ist, hatte ich noch nichts geschrieben. Ich kann aber berichten, dass die Performance durch die Festplatte mit der höheren Drehzahl in den Keller ging. Die Festplatte mit der höheren Blockgröße hat im Performance Test keinen Unterschied gemacht. Die vermurkste Installation ist aber nach wie vor ein Thema :)

bearbeitet 16. Februar 2018 von webbies