Thema "Re: Performance nach SR v. 31.03." in Technisches zu Software

Performance nach SR v. 31.03.

agmü — Wed, 12 Apr 2017 12:00:18 GMT

Hallo,

nachdem ich vom DATEV-Service keine befriedigende oder gar nachvollziehbare Antwort erhalte - an dieser Stelle eine Kurze Nachfrage in die Runde:

Seit der Installation des Service-Release vom 31.03.2017 am 01.04. sinkt die Performance der DATEV-Programme täglich um 12:00 Uhr auf Werte die miserabel sind. Die Performance war so miserabel, dass sich alle Programme samt DATEV-Arbeitsplatz ins Nirvanna verabschiedet haben.

Bei uns wird im 12:00 Uhr über den DATEV-SQL-Manager eine Sicherung der Datenbanken angestoßen. Diese Sicherung hat bis 30.03. zu keinerlei spürbaren Performance-Einbußen geführt.

Tritt das Verhalten in anderen Kanzleien auch auf?

Danke für die Rückäußerung.

Andreas G. Müller

NS.: Bitte keine Hinweise auf die Performance-Verbesserung mit Systemnahen Lösungen. Das System war mehr als zufriedenstellend Lauffähig. Die Probleme müssen aus meine Sicht mit dem SR zusammenhängen.

Re: Performance nach SR v. 31.03.

jan — Wed, 12 Apr 2017 12:41:06 GMT

Ist das System denn wieder "mehr als zufriedenstellend Lauffähig" wenn der Task im SQL Manager deaktiviert wird?

Bzw. in der Aufgabenplanung einfach mal ausgesetzt wird.

Ansonsten vielleicht mal die "Native Images" von Hand anstoßen und bauen lassen.

Re: Performance nach SR v. 31.03.

agmü — Wed, 12 Apr 2017 12:51:24 GMT

Das System läuft nachdem die Sicherung angestoßen wird wieder "zufriedenstellend" (schneller geht immer).

Nach einer Woche Einsatz des SR sollten alle Native Images erstellt sein. Zumal deren Erstellung nach dem Start manuell angestoßen wurde.

Re: Performance nach SR v. 31.03.

andreashofmeister — Wed, 12 Apr 2017 13:00:12 GMT

Hallo Herr Müller,

liegts evtl. an den Anwalts-SRs? Oder haben Sie auch andere (KA-Rewe) Programme im Einsatz?

Re: Performance nach SR v. 31.03.

agmü — Wed, 12 Apr 2017 13:44:03 GMT

Hallo Herr Hofmeister,

Die Anwalts SR hatte ich zunächst auch im Verdacht - Sorry an die Entwicklung. Allerdings müssten die Performanceprobleme dann über den ganzen Tag verteilt auftreten. Tatsächlich aber kann ich fast die Uhr danach stellen; jeden Tag um 12:00 Uhr und nach ca. 2-3 Minuten läuft wieder alles normal, gerade so als ob nichts gewesen sei. Die einzige Besonderheit zu dieser Zeit ist der Start der Datensicherung.

Re: Performance nach SR v. 31.03.

andreashofmeister — Wed, 12 Apr 2017 13:49:14 GMT

Welche Form der Datensicherung haben Sie?

Warum mittags um 12 Uhr und nicht abends um 18 Uhr (nur mal so gefragt..?)

Re: Performance nach SR v. 31.03.

Wed, 12 Apr 2017 14:22:20 GMT

.. das habe ich mich auch gefragt ... wenn um 12 Uhr allgemeine Mittagspause wäre, würde es ja keiner merken:-)

Re: Performance nach SR v. 31.03.

RAHagena — Wed, 12 Apr 2017 14:40:43 GMT

...und haben Sie sie testweise schon mal ausgestellt/verschoben um zu schauen, ob diese den Performance-Einbruch auslöst?

Re: Performance nach SR v. 31.03.

agmü — Wed, 12 Apr 2017 14:55:17 GMT

Die Datenbanksicherung die sich im DATEV-SQL-Manager Skript gesteuert einstellen lässt (vgl. Prüfung und Sicherung von Microsoft-SQL-Datenbanken mit dem DATEV SQL-Manager).

Die Uhrzeit war mit dem Gedanken der Mittagspause und der geringeren Serverlast so gewählt. Dennoch soll es vorkommen, dass auch während andere Mittagspause machen gearbeitet werden muss; oder später Mittag gemacht wird. Auch ich mache lieber später meine Mittagspause. Daher kann ich auch das Systemverhalten im "Betrieb" recht zuverlässig einschätzen.

Um die Sicherung zu einem späteren/andern Zeitpunkt durchführen zu können, müsste etwas mehr als nur das Datensicherungskonzept umgestellt werden; (manches mal wünsche ich mir ich hätte mich nicht zu einem Client-Server-System überreden lassen und das alte P2P System beibehalten. Das hätte mir mehr als nur eine schlaflose Nacht und eine Menge Ärger erspart).

Den Beiträgen entnehme ich, dass das Phänomen nicht bekannt ist, so dass ich weiter Suche muss.

Danke für die Gedanken und Tipps

Re: Performance nach SR v. 31.03.

andreashofmeister — Wed, 12 Apr 2017 14:59:48 GMT

Doch, nachdem Sie nun mitgeteilt haben, dass das der SQL-Check mit SQL-Sicherung ist:

auf unserem alten Server konnte ich das auch nachvollziehen. War aber ein rel. betagtes System. Dort lief diese Sicherung auch immer (erst) abends.

Aber auch während dieser Sicherung kam es zu den von Ihnen beschriebenen Effekten.

Dieses Phänomene haben wir auf dem neuen System dann überhaupt nicht mehr. Da laufen dann auch mehrere Sicherungen nebeneinander. Ohne diese Auffälligkeiten.

Re: Performance nach SR v. 31.03.

agmü — Thu, 13 Apr 2017 05:44:40 GMT

Ich hoffe doch, dass ein im Dezember 2015 angeschaffter Server noch nicht zum alten Eisen gehört.

Re: Performance nach SR v. 31.03.

Thu, 13 Apr 2017 06:33:56 GMT

Moin,

das ist durch die gewählte Technik ein ganz normales Verhalten. Je nachdem wie der SQL-Server gerade genutzt wird, sind die offenen Daten evtl.recht umfangreich und der für die Datensicherung genutzte Vorgang dauert etwas länger. Versuchen Sie einmal den Sicherungspfad auf ein anderes physikalisches Laufwerk zu legen. Gerade bei RAID 5 und größer kann es zu "Staus" bei den IO Operationen kommen.

Gruß

Re: Performance nach SR v. 31.03.

Thu, 13 Apr 2017 08:41:19 GMT

Hallo Herr Müller,

die SRs sollten ein derartiges Verhalten eigentlich nicht verursachen. Eventuell hilft ein kurzer Blick auf die Konfiguration Ihres Systems via Fernbetreuung. Sie können mich hierzu gerne per Mail kontaktieren: christian.deuerlein@datev.de

Schöne Grüße

Christian Deuerlein

Re: Performance nach SR v. 31.03.

agmü — Thu, 13 Apr 2017 08:49:02 GMT

Hallo Herr Deuerlein,

Danke für das Angebot.

Richtig ist, ein SR sollte ein derartiges Programmverhalten nicht auslösen; zumal lediglich drei Programmpakete (Anwalt classic, Rechnungswesen und Basis Wirtschaftsberatung), bereitgestellt und installiert wurden; Programmpakete die noch nicht einmal auf dem Server laufen.

Re: Performance nach SR v. 31.03.

Thu, 13 Apr 2017 09:07:44 GMT

Hallo Herr Müller,

hier noch einige Ansätze zur Eingrenzung:

Prüfen Sie in der Historie der Datenbankprüfungen (SQL-Manager > Kontextmenü des Servers > ERgebnisdatei DB-Prüfung anzeigen) die Laufzeiten. Es werden dort alle Vorgänge seit der Installation des Systems angezeigt.

Hat sich die Laufzeit der Prüfungen/Sicherungen eventuell verändert?

Wieviel Zeit wird aktuell für den Vorgang benötigt?

Liegt eventuell ein Engpass im Bereich des Storage-Systems vor?

Dies kann z. B. mit dem Passmark Performance Test festegestellt werden (www.passmark.com). Am Server installieren und den Test "Disk" laufen lassen. Die Werte bei Lesen/Schreiben/Random sollten bei einem lokalen RAID > 300 - 500 MB/Sekunde liegen.

Alternativ kann ich Ihnen eine Analyse durch unser Tool Perfalyser anbieten. Sie können sich dies hier herunterladen, am Server entpacken und dort mit _start.cmd installieren (Standardwerte der Abfragen beibehalten). Das Tool protokolliert dann nach C:\perflogs\Messung. Diesen Ordnder können Sie mir gepackt nach 2 - 3 Tagen zukommen lassen, ich werte die Daten dann aus. Kosten entstehen für Sie nicht.

https://go.datev.de/uta/

Benutzername:

bJrVxSVX

Passwort:

46JF3pde

Re: Performance nach SR v. 31.03.

agmü — Thu, 13 Apr 2017 13:35:00 GMT

Es soll irgend jemand die Technik verstehen. Das Problem wurde, Dank der Unterstützung durch Herrn Deuerlein gelöst. Ich hätte nicht erwartet, dass ein zwei Jahre alter/junger Server solche Schwierigkeiten bereiten kann.

Danke nochmals.

Re: Performance nach SR v. 31.03.

Thu, 13 Apr 2017 13:38:35 GMT

Interessehalber, wer war der Übeltäter?

Re: Performance nach SR v. 31.03.

agmü — Thu, 13 Apr 2017 13:43:42 GMT

der fehlende Schreibcache beim Raid 1 war's wohl; obwohl diese Einstellungen seit der Auslieferung nicht geändert wurden.

Re: Performance nach SR v. 31.03.

andreashofmeister — Thu, 13 Apr 2017 13:57:19 GMT

Na, da hätte man ja lange hier über Datensicherungsszenarien philosophieren können. Aber immerhin. Erfahrungsaustausch dank Community. Klasse Sache hier, oder?

Schöne Ostertage!

LG, A. Hofmeister

Re: Performance nach SR v. 31.03.

agmü — Thu, 13 Apr 2017 16:15:31 GMT

Die DATEV-Community ist eine Spitzen Einrichtung und die Reaktionszeiten sind häufig sensationell. Wir hätten sicher noch Jahre über Sicherungskonzepte nachdenken können.

Für mich bleibt dennoch ein schaler Nachgeschmack: Die "Problemlösung" fühlt sich so an als ob ich wegen blockierender Bremsen die Bremsleuchten austausche; aber so scheint IT zu funktionieren

Schöne und erholsame Osterfeiertage

Re: Performance nach SR v. 31.03.

Thu, 13 Apr 2017 16:38:27 GMT

Den schalen Beigeschmack hätte ich auch, obwohl aus anderen Gründen. Üblicherweise wird der Schreibcache mit einer Batterie (oder Akku oder Kondensator) abgesichert. Diese "Notstromversorgung" des Cache wird durch den Controller überwacht. Einige bessere Modelle können einen leeren (warum auch immer) Akku erkennen und schalten dann den Schreibcache ab. Bei weiteren Betrieb sollten Sie einmal den Status des Akkus prüfen (lassen) um Datenverluste zu vermeiden.

Auch ich wünsche schöne Ostertage.

Gruß

PS: Dummspruch aus dem Radio heute. Der für das Osterwetter zuständige Server wurde von einem Trojaner verseucht, es handelt sich um den Regenwurm...

Re: Performance nach SR v. 31.03.

Gelöschter Nutzer — Fri, 14 Apr 2017 07:39:35 GMT

bei den meisten controllern lassen sich auch regelmässige testläufe einrichten, die den allgemeinzustand des akkus testen. während dieses tests wird der cache deaktiviert und wenn der test fehlschlägt, bleibt dieser auch deaktiviert und der akku sollte getauscht werden. bei uns war nach 3 jahren der akku schon hin.. die hersteller sagen ca. 5 jahre.

Re: Performance nach SR v. 31.03.

theo — Fri, 14 Apr 2017 08:27:16 GMT

manches mal wünsche ich mir ich hätte mich nicht zu einem Client-Server-System überreden lassen und das alte P2P System beibehalten. Das hätte mir mehr als nur eine schlaflose Nacht und eine Menge Ärger erspart.

Durchschlafen kann man damit. Dafür würden Sie sich wahrscheinlich mittlerweile während der Arbeitszeit ständig kaputtkonfigurieren bzw. stundenlang die Hotline (per Remote auf dem Server / erfolglos) bemühen, während Ihre Kollegen frei haben. Es weiss nämlich keiner, wie man die neue Benutzerverwaltung im P2P konfiguriert.

Re: Performance nach SR v. 31.03.

agmü — Tue, 18 Apr 2017 06:03:28 GMT

Die neue Benutzerverwaltung habe ich erstmals unter unserem alten P2P-System eingerichtet. War - unter Berücksichtigung des damaligen Umsetzungsstandes - weitgehend problemlos möglich.

Aber, Hand auf's Herz, ob ich eine schlaflose nach wegen der Benutzerverwaltung habe oder weil die Einstellungen am Server nicht optimal sind, ist für mich egal.

Durch die Änderungen am Server scheint jetzt der Rest der DATEV-Programme Schwierigkeiten zu machen - Jedenfalls erhalte ich seither gehäuft Programm reagiert nicht Meldungen - muss ich weiter beobachten und sehen wie die Kollegen reagieren. Vielleicht fehlt dem Server auch nur die notwendige Last

Re: Performance nach SR v. 31.03.

Gelöschter Nutzer — Tue, 18 Apr 2017 06:16:44 GMT

wieviel ram und wieviel arbeitsspeicher ist dem sql/server zugewiesen? wieviele nutzer sind es?

Re: Performance nach SR v. 31.03.

agmü — Tue, 18 Apr 2017 09:21:19 GMT

Arbeitsspeicher ist ausbaubar. Derzeit nur 8 GB bei max. 3 Nutzern.

Das eigentlich nicht logische Phänomen, dass die DATEV-Software bei geringer Nutzerzahl (1 Nutzer) an Performance zu verlieren scheint, beobachte ich schon länger, ohne dass sich es greifen oder eingrenzen könnte.

Nachdem zwischenzeitlich die maximale Anwenderzahl tätig ist reagieren die Programme auch wieder erwartungskonform.

Re: Performance nach SR v. 31.03.

agmü — Wed, 19 Apr 2017 10:13:59 GMT

Alls kleines Update für die Interessierten Leser:

Die Datensicherung hat dieses mal die Anlage einer Akte massiv beeinträchtigt. Bis das Fenster für die Kollisionsprüfung erscheinen ist sah sich der Arbeitsplatz veranlasst den Hinweis zu geben, dass diese Prüfung mehrere Minuten dauern könne. Dann wollte er die Akte nicht speichern, weil angeblich ein Nachname fehlen würde ....

Es bleibt spannend. Offensichtlich war der Ausbau der Bremsleuchte für die Beseitigung der Bremsblockade doch nicht wirklich hilfreich.

Ich werde den Interessierten und geneigten Lesern weiter berichten.

Re: Performance nach SR v. 31.03.

Gelöschter Nutzer — Wed, 19 Apr 2017 10:42:57 GMT

irgendetwas läuft da auf den hammer... bei uns läuft auch jeden mittag eine sql sicherung und bei 20 anwendern lässt es sich noch ganz passabel arbeiten.

würde, wenn keine ssd, eine extra partition für die auslagerungsdatei erstellen und diese bei 20gb fixieren. dann schauen, was der ram so macht. unser sql, ausschiesslich sql, braucht max 3gb ram für das system ect. die restlichen 20gb nimmt datev-sql, 1gb puffer. das kann man im sql manager fixieren.. weiss aber gerade nicht mehr wo.

Re: Performance nach SR v. 31.03.

agmü — Wed, 19 Apr 2017 15:02:09 GMT

Danke für den Hinweis,

Das eigentliche Problem liegt darin, dass bei identischer Hardwareausstattung das Einspielen eines Servicerelease - noch nicht einmal am Server selbst - zu einem Performanceeinbruch führt und dies auch nur einmal am Tag.

Für mich fehlt hier jeder Zusammenhang zu einer auszulagernden Partition oder der (de-)Aktivierung eines Schreib-Cache oder der Größe des Arbeitsspeichers. Bei einem neues System oder einer neuen Softwareversion hätte ich das Verhalten nachvollziehen können.

Re: Performance nach SR v. 31.03.

Gelöschter Nutzer — Wed, 19 Apr 2017 15:32:31 GMT

- eventuell ist auch bei der Installation des SR etwas schief gelaufen

- oder, es passt nicht mehr durchs Loch, entsprechend blockiert die ganze Maschine (entsprechend etwas Umlagern)

- was sagt die Ereignisanzeige auf dem Server?

- eventuell liegt auch ein Hardwaredefekt vor. Technische Prüfung des SQL in Ordnung? SMART-Werte der Platten in Ordnung?

- Trojaner/Wurmbefall?

Es kann vieles sein.

Re: Performance nach SR v. 31.03.

agmü — Thu, 20 Apr 2017 05:39:41 GMT

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.

Re: Performance nach SR v. 31.03.

wabe — Sun, 23 Apr 2017 13:43:53 GMT

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…

Re: Performance nach SR v. 31.03.

agmü — Mon, 24 Apr 2017 11:37:42 GMT

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

Re: Performance nach SR v. 31.03.

agmü — Fri, 05 May 2017 12:47:31 GMT

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.

Re: Performance nach SR v. 31.03.

jan — Fri, 05 May 2017 12:56:42 GMT

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

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

Re: Performance nach SR v. 31.03.

agmü — Fri, 05 May 2017 13:06:25 GMT

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.

Re: Performance nach SR v. 31.03.

jan — Fri, 05 May 2017 13:09:47 GMT

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

Re: Performance nach SR v. 31.03.

agmü — Fri, 05 May 2017 13:24:17 GMT

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).

Re: Performance nach SR v. 31.03.

Fri, 05 May 2017 14:27:56 GMT

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

Re: Performance nach SR v. 31.03.

agmü — Fri, 05 May 2017 15:03:49 GMT

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

Re: Performance nach SR v. 31.03.

mkolberg — Fri, 05 May 2017 18:49:16 GMT

Ist auf den Plattensystemen der Schreibcache deaktiviert?

Re: Performance nach SR v. 31.03.

agmü — Sat, 06 May 2017 09:33:10 GMT

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.