RunAudit (Überprüfungslauf) deaktivieren?

[stefan_l]

Hallo,

hier beim Mainzerruderverein laufen unsere insgesamt vier Fahrtenbücher mittlerweile recht stabil. Die Neustarts bzw. Zeitpunkte der Neustarts der Systeme ist jetzt harmonisiert, die Clients verbinden sich korrekt mit der Datenbasis des Masters.
Bezüglich des RunAudit (Überprüfungslauf) habe ich mich gefragt, ob man diesen deaktivieren kann bzw. einen anderen zeitlichen Intervall wählen kann?

Denkbar wäre doch etwa den Überprüfungslauf einmal in der Woche und nicht bei jedem Efa Start (in unserem Fall täglich) laufen zu lassen.
Bei uns verhält es sich nach dem Neustart der Rechner nämlich dann so, dass es ca 12 Minuten dauert bis efa die Überprüfung abgeschlossen hat und dann schließlich startet. Während dieser Zeit ist die CPU bei nahezu 100% und so mancher Benutzer wertet dies als "Freeze" und meldet dann "ein Problem mit dem Fahrtenbuch".

Ich bin dankbar für Tipps, wie wir hier eine Optimierung der "Freezetime" erreichen können bzw. diese nur einmal die Woche haben..

Dank und Gruß
Stefan

[nick]

Hallo Stefan,

der Audit sollte keinesfalls so lange laufen, eher im Bereich von wenigen Sekunden. Außerdem sollte der Audit auch nur auf dem Master laufen und nicht auf den Clients. Kannst Du das bestätigen, oder läuft bei euch der Audit auch auf den Clients? Das sollte eigentlich gar nicht möglich sein...

Gruß,
Nick

[stefan_l]

Hallo Nick,

auf den Clients läuft kein RunAudit, das ist nur auf dem Master der Fall.
Aber der Master braucht beim Start eben etwa 12 Minuten bei CPU-Vollauslastung (im dazugehörigen Java-Prozess).

Was wären denn die Schritte, wie wir hier bei der Analyse am besten weiterkommen?

Gruß
Stefan

[nick]

Hallo Stefan,

findet der Audit denn haufenweise Fehler? Könntest Du mir bitte mal eine Logdatei efa.log von efa an help (at) efa (punkt) nmichael (punkt) de schicken, in der der Programmstart mit den Audit-Aktivitäten verzeichnet ist? Bitte aktiviere zuvor in der efa-Konfiguration im Expertenmodus die Option Debug-Logging, starte dann efa neu, warte bis der Audit fertig ist, und schicke mir bitte die gesamte Logdatei an dem Start von efa zu.

Danke & Grüße,
Nick

[nick]

Hallo Stefan,

vielen Dank für Deine Logdatei. Ich antworte hier im Forum, da die Hinweise auch für andere Nutzer interessant sein könnten.

1. Dein Audit meldet haufenweise Warnungen zu ungültigen Referenzen, die er ersetzt. Einmalig ist sowas unter Umständen ok, falls du bestimmte Daten gelöscht hast, und der Audit danach "aufräumt". Nach einem wiederholten Start sollte es aber nicht immer wieder erneut zu solchen Meldungen kommen. Bitte überprüfe doch mal, ob der Audit bei jedem Start so viele Warnungen bringt, und ob diese unter Umständen sogar immer dieselben sind. Falls ja, dann schaue dir doch bitte mal stichprobenartig einige der Daten an, die der Audit bemängelt. Falls dir daran nichts komisch vorkokmmt, schicke mir bitte mal einen Komplettauszug der Daten (am besten ein von efa erstelltes Backup deines Projekts) per email zu.

2. Trotz der vielen Warnungen läuft der Audit schnell. Er startet um 22:23:23 und ist um 22:23:32 fertig, hat also nur 9 Sekunden gebraucht. (Die Zählung der gefundenen Warnungen ist falsch, das werde ich mit dem nächsten Update korrigieren.)

3. Ich vermisse in deiner Logdatei die Ausschrift Projekt '...' geöffnet. Merkwürdig.

4. Zwischen den Ausschriften efaRemote Server läuft auf Port 3834 (22:05:07) und Starting Project Audit for Project (22:23:23) vergehen über 18 Minuten. Leider gibt es hier nicht genügend Debug-Ausschriften, die genauen Aufschluß darüber geben, was efa hier tut. Bei Bedarf könnte ich dir eine solche Version von efa zum Testen geben. Aber auch so: Nach dem Starten des Remote-Servers bereitet efa die GUI vor, öffnet das zuletzt geöffnete Projekt, und startet dann den Audit. Falls sich also
deine Clients sofort nach dem Start des Server-efa versuchen zu verbinden, könnte dies Auswirkungen haben. Das könnte ein Nebeneffekt sein, die du ja anscheinend auch beobachtest. Als Hauptursache vermute ich aber, daß es auf dem Server-efa sehr lange dauert, das Projekt zu öffnen. Grund dafür könnte hauptsächlich eine sehr große Nachrichtendatei sein. Der Audit bemängelt dies auch:

Code: Alles auswählen

[15.08.2012 22:23:24] - efaBths - 01816 - INFO    - DAT025 - Nachrichtendatei hat maximale Dateigröße überschritten. Derzeitige Größe: 6581621 byte
...
[15.08.2012 22:23:30] - efaBths - 01816 - INFO    - DAT026 - 1 gelesene Nachrichten wurden erfolgreich in die Archivdatei C:\Documents and Settings\Fahrtenbuch\efa2\backup\messages_20120815_222324.efa2messages verschoben.
[15.08.2012 22:23:31] - efaBths - 01816 - WARNING - DAT025 - Nachrichtendatei ist nach Archivierung gelesener Nachrichten noch immer groß. Derzeitige Größe: 6580980 byte
[15.08.2012 22:23:31] - efaBths - 01816 - WARNING - DAT025 - Es gibt 81 ungelesene Nachrichten. Bitte lies die Nachrichten und markiere sie als gelesen.

Du hast 81 ungelesene Nachrichten, die teilweise aufgrund von Fehlern oder Warnungen (wie die des Audits), die efa gefunden hat, riesig groß geworden ist. Deine Nachrichten hast du vermutlich nie als gelesen markiert, so daß efa alte (gelesene) Nachrichten nicht archiviert. Dadurch wächst die Datei immer weiter an. Warum das Öffnen dieser 6.5 MB großen Datei allerdings so lange dauert, ist noch ein wenig rätselhaft. Das muß ich mir mal gesondert anschauen. (Die Daten liegen auf einer lokalen Festplatte?)

In der nächsten efa-Version werde ich noch deutlicher auf das Lesen der Nachrichten hinweisen, und auch eine Option anbieten, diese bereits beim Erstellen automatisch als gelesen zu markieren (zum Beispiel, wenn sie per email an die Admins zugestellt werden und diese sich nie zum Lesen der Nachrichten in efa einloggen). Außerdem wird efa als allerletzte Rettung bei vierfachem Überschreiten der Maximalgröße (1 MB) auch ungelesene Nachrichten archivieren.

Grundsätzlich gilt aber, daß die Nachrichten, die efa dem Administrator zustellt, gelesen werden sollten, da sie wichtige Informationen über das Wohlbefinden von efa enthalten können!

Gruß,
Nick

[stefan_l]

Hallo Nick,

erst einmal vielen Dank für die ausführlichen Erklärungen und die genaue Analyse!
Es lag tatsächlich an der Nachrichtendatei, jetzt startet efa wieder in weniger als einer Minute! Da wären wir sicher nicht alleine darauf gekommen. Vielen Dank!

Jetzt bräuchten wir nur noch eine Lösung für das "bereits-vorhandene-laufende-Nummer-Problem" beim parallelen Eintragen von Fahrten von zwei PCs (z.B. zwei Clients).
Wie gesagt, unser Vorschlag wäre: Unmittelbar vor dem Speichern der Fahrt in das Fahrtenbuch noch einmal die Nummer zu prüfen und ggf. den Zähler dann um weiter inkrementieren. Ansonsten macht das Eintragen von mehreren PCs aus wirklich nur bedingt Sinn. Bei Bedarf, kann ich da aber gerne noch ein Thema in einem geeigneten Thread eröffnen. In welchem Forum soll ich das am besten platzieren?

Primär aber erst mal super, das efa wieder flott aus den Federn kommt!

Dank und Gruß
Stefan

[nick]

Hallo Stefan,

freut mich, daß efa jetzt wieder flott startet. Gestern abend habe ich auch noch eine mögliche Ursache entdeckt, warum bei großen Nachrichtendateien (oder vermutlich eher: großen Nachrichten in großen Nachrichtendateien) efa unverhältnismäßig lange zum Starten benötigt. Falls es das ist was ich denke, dann habe ich das jetzt gefixed, muß es mir aber nochmal genau anschauen. Sonst sollten auch die gestern beschriebenen Änderungen dazu beitragen, daß so etwas nicht mehr so leicht vorkommt.

Jetzt bräuchten wir nur noch eine Lösung für das "bereits-vorhandene-laufende-Nummer-Problem" beim parallelen Eintragen von Fahrten von zwei PCs (z.B. zwei Clients).

Laß mich nochmal rekapitulieren: Das Problem tritt auf, wenn in beiden PC's dasselbe Fahrtenbuch verwendet wird, und nahezu zeitgleich in beiden PC's eine Fahrt eingetragen wird. Beim Öffnen der Maske holen sich dann beide PC's (dieselbe) nächste LfdNr, und beim Versuch den Eintrag zu speichern (Fahrt beginnen) gewinnt der erste, und der zweite quittiert den Versuch mit einer Fehlermeldung wegen doppelter LfdNr. Richtig verstanden?

Danke & Gruß,
Nick

[stefan_l]

Hallo Nick,

sorry, dass ich erst jetzt antworte! Mittlerweile haben wir uns an das Phänomen fast schon gewöhnt, was aber eigentlich doch nicht unbegingt sein müsste...

Laß mich nochmal rekapitulieren: Das Problem tritt auf, wenn in beiden PC's dasselbe Fahrtenbuch verwendet wird, und nahezu zeitgleich in beiden PC's eine Fahrt eingetragen wird. Beim Öffnen der Maske holen sich dann beide PC's (dieselbe) nächste LfdNr, und beim Versuch den Eintrag zu speichern (Fahrt beginnen) gewinnt der erste, und der zweite quittiert den Versuch mit einer Fehlermeldung wegen doppelter LfdNr. Richtig verstanden?

Genau das ist das Problem. Bei uns gibt es (wie bei vielen Rudervereinen) feste Termine an denen z.B. immer 3 oder 4 Vierer gleichzeitig aufs Wasser wollen. Da entsteht schon mal eine kleine Warteschlage an den Fahrtenbuch-PCs. In solch einer Situation wäre es wirklich von großem Vorteil, wenn man "gleichzeitig" Fahrten an mehreren PCs eingeben könnte.

Man könnte doch die laufende Nummer immer erst zum "Abspeichern-Zeitpunkt" vergeben, oder?

Beste Grüße
Stefan

[nick]

Hallo Stefan,

habt ihr in letzter Zeit efa mal geupdated? Das Problem ist seit Version 2.0.5 (11.11.2012) bereits behoben, siehe http://efa.nmichael.de/changelog_efa2.html.de. Fahrten können seit dieser Version zeitgleich an mehreren über efaRemote verbundenen efa's begonnen werden, ohne daß es zu Fehlern wegen der LfdNr kommt.

Gruß,
Nicolas