Performance nach SR v. 31.03.

[#1]

Da das SR keine Programme enthalten hat, die den Server selbst betreffen und auch das Servicetool nur vermeintlich neuere Dateien moniert (Servicetool wurde mit dem SR nicht aktualisiert, daher Hinweis richtig), dürften Installationsfehler unwahrscheinlich sein.

Alle anderen Punkte kann ich ebenfalls verneinen.

[#2]

Als  IT Dienstleister möchte ich hier ein gutes Wort für den Kollegen Christian Deuerlein von der DATEV einlegen.

Dokumentiert wird ein Problem mit der DATEV Anwendung, Herr Deuerlein gibt detaillierte Anweisung zu Fehlersuche (Passmark Tool).

Dennoch muss er selbst den Fehler in der Konfiguration beim System des Anwenders finden.

Danke für Ihren Einsatz (wahrscheinlich ohne Berechnung)  Herr Deuerlein…

[#3]

Sehr geehrter Herr Wagner,

darf eine Problemlösung nicht hinterfragt werden, wenn diese nicht ohne weiteres eingängig und nachvollziehbar ist?

Mit einer Schmälerung oder Nichtanerkennung der Unterstützungsleistung hat dies nichts zu tun.

Als Nicht-Admin versuche ich nur nachzuvollziehen, warum gerade jetzt diese Problematik und genau in dieser Konstellation aufgetreten ist, den für mich ist nach wie vor nicht nachvollziehbar, warum eine Änderung der Anwendungsprogramme in genau einer Anwendungskonstellation zu Schwierigkeiten führt.

mit freundlichen Grüßen

Andreas G. Müller

[#4]

Als kleines Update für alle Interessierten Leser:

Der SERVER ist zwischenzeitlich mit 32 GB Arbeitsspeicher ausgestattet.  Damit lässt sich zwar die Performancedelle zur Mittagszeit auffangen.  Als "Belohnung" habe ich heute beim Speichern eines Word-Dokuments den Hinweis erhalten, dass der SQL-Manager sein Kapazitätslimit erreicht hätte und deshalb das Worddokument derzeit nicht in die DokAblage übernommen werden könne.

Das Tuning des bis Ende März stabil laufenden "Ökosystems" geht weiter.

[#5]

Beinhaltet der Sicherungslauf im SQL Manager auch die Prüfung?

Hintergrund: https://www.datev.de/dnlexom/client/app/index.html#/document/1080803

[#6]

kann ich nur mit ? beantworten.

Muss ich mir ansehen; Danke für den Tipp.

Es fasziniert mich einfach immer wieder, wie ein laufendes System step by step zerfällt und genauso mysteriös wie ein Phönix aus der Asche wieder ohne murren und zicken wieder läuft.

[#7]

Zwischen den beiden Zuständen lag dann aber häufig ein Reboot

[#8]

Der Reboot kann's nicht sein, denn dann müsste mich der Server jeden Tag beglücken .

Ich hätte besser nicht nachgesehen:  Der Server hat 15 Leistungswarnungen für den Zeitraum der Beeinträchtigung angezeigt.  Ein genauer Blick auf den Auslöser der Warnungen ist  - und den hatte ich schon lange nicht mehr - ein Mcaffe-Prozess, der für 98,89% Prozessorauslastung sorgt.  (Vielleicht habe ich diese "Baustelle" auch einfach nur verdrängt; Wie konnte ich nur verdrängen dass Ende April eine neue VIWAS-Version ausgeliefert wurde).

[#9]

Eine Nachfrage: Läuft auf dem Server auch der Kommunikationsserver?

[#10]

Nein auf dem Server läuft kein Kommunikationsserver.  Den brauchen wir für unser Einsatzprofil nicht .

[#11]

Ist auf den Plattensystemen der Schreibcache deaktiviert?

[#12]

Nein der Schreibcache ist aktiviert.

Der Dienst McShield beansprucht - wieder einmal - rd. 100% der CPU-Leitsung, sobald die Intensivprüfung gestartet wird.

Das Problem hatte ich bereits vor längerer Zeit.  Nach einiger Zeit und dem einen oder anderen Update von VIWAS ist das Problem verschwunden.