BSH erzeugt Vollast und stürzt gelegentlich ab

[bsh-rulez]

Bis vor einiger Zeit war BSH das perfekte Backup-Tool: einfach installiert, konfiguriert und läuft reibungslos im Hintergrund. Dann kam ab und zu die Meldung "Programm muss beendet werden" - selten genug, um wirklich zu stören. Mittlerweile kommt das gefühlt täglich, teilweise macht BSH mehrere Tage keine Sicherung. (letzteres liegt z.T. auch daran, dass der Rechner manche Tage nur relativ kurz läuft)
Zu guter Letzt ist mir jetzt schon mehrfach aufgefallen, dass ein zu BSH gehörender Prozess längere Zeit Vollast erzeugt - ohne das BSH etwas zu tun scheint. Siehe angehängten Screenshot des TaskManagers. Jetzt im Sommer signalisiert das gerne Mal der Lüfter

Bei mir läuft aktuell BSH 3.3.1.4 (ist aber schon vorher aufgetreten) auf WinXP mit allen Updates.

Zu den Abstürzen:
In der Ereignisanzeige steht nichts relevantes zu BSH. Das könnte daran liegen, dass jede einzelne Datei einen Eintrag erzeugt - das reicht bei mir vermutlich nicht mal für eine Sicherung (2 MB sind nach <2 Min voll). Muss das sein? In den Einstellungen habe ich nichts gefunden.
Im Anwendungs-Log scheint eine Meldung von ".NET Runtime 2.0 Error Reporting" zu den Abstürzen zu passen:

Code: Alles auswählen

Ereignistyp:	Fehler

Ereignisquelle:	.NET Runtime 2.0 Error Reporting

Ereigniskategorie:	Keine

Ereigniskennung:	5000

Datum:		10.07.2010

Zeit:		13:01:35

Benutzer:		Nicht zutreffend

Computer:	XXX

Beschreibung:

EventType clr20r3, P1 alexosoft.backupservice.mainapp, P2 3.3.1.4, P3 4c1b2d7e, P4 mscorlib, P5 2.0.0.0, P6 4a7cd8f7, P7 343f, P8 26d, P9 system.io.ioexception, P10 NIL.

Die tritt genauso mehrfach auf, eine pro Absturz.


Ich habe zu beiden Fehlern keine Idee und kann auch keinen Grund erkennen, außer das die Abstürze meist bei anderer Aktivität am Rechner aufzutreten scheinen.

[Alex]

Das hört sich nicht so gut an. Mir liegt viel daran, dass die Software fehlerfrei läuft.

Das Problem scheint vermutlich erst nach dem Update 3.3.0.0 aufzutreten, da ich dort viel am Sicherungsprozess geschraubt habe.
Eine Frage noch bevor ich mir das anschaue: Sicherst du die Dateien auf einer normalen externen Festplatte oder auf einem FTP-Server oder wie sieht deine Konfiguration aus?

[bsh-rulez]

Habe gerade mal geschaut, die erste Meldung, die ich noch finden kann ist von Version 3.2.15.1:

Code: Alles auswählen

EventType clr20r3, P1 alexosoft.backupservice.mainapp, P2 3.2.15.1, P3 4b81641d, P4 mscorlib, P5 2.0.0.0, P6 4a7cd8f7, P7 343f, P8 26d, P9 system.io.ioexception, P10 NIL.

Mit 3.3.0.1 hatte ich einen anderen Fehler, mit 3.3.0.2 wieder den (zumindest laut P9).

Ich nutze eine Apple TimeCapsule als Backup-Medium, BSH zeigt sie als Netzlaufwerk an.

[Alex]

Danke für das Recherchieren. Die Fehlermeldungen helfen leider nicht, da sie zum Teil ziemlich willkürlich sind (liegt nicht an mir)

[Alex]

Noch eine Frage 
Bei was genau tritt das Problem auf: Bei automatischen Sicherungen oder / und auch bei manuellen Sicherungen?

Was hast du noch für Einstellungen? Komprimierung / Verschlüsselung?

[bsh-rulez]

Ich hätte erst behauptet, die Fehler träten nicht bei Sicherungen auf. Allerdings ist mir beim genaueren Ansehen des BSH Logs der letzten Sicherung aufgefallen, dass das Ereignis 7 (Sicherung abgeschlossen) noch gar nicht auftauchte, bevor der Fehler auftrat. Demnach war es eine automatische Sicherung. Die Ereignisse 0, 12, 13 und n*14 sind davor aufgetreten, n entspricht der in 13 gemeldeten Zahl zu löschender Dateien. Danach knapp 9 Minuten nichts, bis der Fehler auftritt. Im BSH Log gar nichts weiter (bis zum nächsten Start).
Eine manuelle Sicherung hat funktioniert. Da das BSH Log mit Meldungen für jede Datei voll ist, kann ich nicht weiter zurück schauen

Zu den Einstellungen:
- Vollautomatisch
- Keine Kompression/Verschlüsselung
- Weitere: aus, an, an, an, aus, an 7 Tage

Ausgeschlossen sind drei Ordner, u.a. der Cache von Firefox.

[bsh-rulez]

Gerade hat wieder eine Sicherung begonnen und pünktlich nach dem Löschen scheint der genannte Prozess auf Vollast zu gehen - mal sehen, wann er abstürzt...

[bsh-rulez]

ok, war zu pessimistisch:
Nach 15 Minutem kam Event 7 (Löschung abgeschlossen). Danach wieder 12, 13 und 14 für das Löschen der nächsten Version. Nach dem Löschen wieder nichts im Log, der Prozess weiter unter Vollast...
Nochmal ca. 14 Minuten später (zu viele Einträge ) wird die Sicherung erfolgreich abgeschlossen!
Die Last ist übrigens danach auf 0% gefallen.

[Alex]

Ok... das hilft mir sehr weiter. Es scheint also an der Datenbank zu liegen, wenn er diese aktualisiert. Scheinbar sind dort die Aktionen zu umfangreich um sie alle auf einmal durchzuführen. Ich werde sehen, was sich machen lässt.

[Alex]

Anbei dieses Beitrags eine optimierte Version von BSH.

[bsh-rulez]

Danke, werde ich gleich mal ausprobieren.

BSH reagiert übrigens während der Volllast-Phase auch nicht auf das Beenden, d.h. das Tray-Icon verschwindet, aber der Prozess macht fleißig weiter.

Habe DLL und EXE ausgetauscht, aber damit stürzt BSH gleich ab:

Code: Alles auswählen

Ereignistyp:	Fehler

Ereignisquelle:	.NET Runtime 2.0 Error Reporting

Ereigniskategorie:	Keine

Ereigniskennung:	1000

Datum:		16.07.2010

Zeit:		21:18:55

Benutzer:		Nicht zutreffend

Computer:	XXX

Beschreibung:

Faulting application alexosoft.backupservice.mainapp.exe, version 3.3.1.4, stamp 4c3f255f, faulting module kernel32.dll, version 5.1.2600.5781, stamp 49c4f482, debug? 0, fault address 0x00012afb.



Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Daten:

0000: 41 00 70 00 70 00 6c 00   A.p.p.l.

0008: 69 00 63 00 61 00 74 00   i.c.a.t.

0010: 69 00 6f 00 6e 00 20 00   i.o.n. .

0018: 46 00 61 00 69 00 6c 00   F.a.i.l.

0020: 75 00 72 00 65 00 20 00   u.r.e. .

0028: 20 00 61 00 6c 00 65 00    .a.l.e.

0030: 78 00 6f 00 73 00 6f 00   x.o.s.o.

0038: 66 00 74 00 2e 00 62 00   f.t...b.

0040: 61 00 63 00 6b 00 75 00   a.c.k.u.

0048: 70 00 73 00 65 00 72 00   p.s.e.r.

0050: 76 00 69 00 63 00 65 00   v.i.c.e.

0058: 2e 00 6d 00 61 00 69 00   ..m.a.i.

0060: 6e 00 61 00 70 00 70 00   n.a.p.p.

0068: 2e 00 65 00 78 00 65 00   ..e.x.e.

0070: 20 00 33 00 2e 00 33 00    .3...3.

0078: 2e 00 31 00 2e 00 34 00   ..1...4.

0080: 20 00 34 00 63 00 33 00    .4.c.3.

0088: 66 00 32 00 35 00 35 00   f.2.5.5.

0090: 66 00 20 00 69 00 6e 00   f. .i.n.

0098: 20 00 6b 00 65 00 72 00    .k.e.r.

00a0: 6e 00 65 00 6c 00 33 00   n.e.l.3.

00a8: 32 00 2e 00 64 00 6c 00   2...d.l.

00b0: 6c 00 20 00 35 00 2e 00   l. .5...

00b8: 31 00 2e 00 32 00 36 00   1...2.6.

00c0: 30 00 30 00 2e 00 35 00   0.0...5.

00c8: 37 00 38 00 31 00 20 00   7.8.1. .

00d0: 34 00 39 00 63 00 34 00   4.9.c.4.

00d8: 66 00 34 00 38 00 32 00   f.4.8.2.

00e0: 20 00 66 00 44 00 65 00    .f.D.e.

00e8: 62 00 75 00 67 00 20 00   b.u.g. .

00f0: 30 00 20 00 61 00 74 00   0. .a.t.

00f8: 20 00 6f 00 66 00 66 00    .o.f.f.

0100: 73 00 65 00 74 00 20 00   s.e.t. .

0108: 30 00 30 00 30 00 31 00   0.0.0.1.

0110: 32 00 61 00 66 00 62 00   2.a.f.b.

0118: 0d 00 0a 00               ....    

Dachte erst, das hängt mit dem noch laufenden BSH Service zusammen, aber keine Änderung. Interessanterweise läuft die alte EXE mit der neuen DLL 

[bsh-rulez]

So sieht es jetzt aus: Volllast gleich nach Start der Sicherung und währenddessen, danach Ruhe.
Allerdings wollte er danach auch nichts löschen... Ich beobachte dass mal, der Lüfter wird es melden

Gibt es eine Aussage zum Logging jeder einzelnen Datei, die ausgeschlossen wird? Von den gut 50.000 Dateien, die im zu sichernden Ordner liegen, sind mehr als 40.000 ausgeschlossen - die liegen alle in einem Ordner (und darunter). Es würde also völlig reichen, den Ausschluss des Ordners zu loggen.

[Alex]

Dass BSH manchmal Volllast produziert ist leider richtig. Gerade bei vielen Dateien > 100.000 ist die Geschwindigkeit leider nicht mehr wie gewollt. Die Datenbank ist damit einfach schon überfordert. Es ist aber leider nicht mehr durch einen einfachen Bugfix in den Griff zu bekommen.

Gleiches Problem gibt es derzeit auch bei der Entwicklung der 4. Version. Mit dieser möchte ich allerdings alles richtig machen, weshalb ich auch viel Zeit darin investiere, den Sicherungsprozess so effizient wie möglich zu gestalten.

Zum Logging gibt es bereits mehrere Benutzer, die der gleichen Ansicht sind, dass sie zu viel protokolliert. Es gibt also Verbesserungsbedarf.

Ich melde mich wieder, sobald es Neuigkeiten gibt.

[bsh-rulez]

Sollte auch keine Kritik sein mit der Volllast, sondern eine Beschreibung der positiven Auswirkungen Deines Patches

Bin gespannt auf Version 4!!!

[bsh-rulez]

Tja, heute war mal wieder Löschen dran und schon gibt's wieder länger Vollast

Hier mein kurzes Protokoll:

Code: Alles auswählen

22:00:00 12 Löschen startet

22:00:11 13 8 Dateien zu löschen

22:15:46 7 Löschen fertig

22:15:46 12 Löschen startet

22:15:49 13 2 Dateien zu löschen

???

22:30:xx 5 (für jede ignorierte Datei)

22:30:44 7 Sicherung fertig

Danach hatte der Prozess gut 30 Minuten Prozessorzeit verbraucht.

Evtl. hat sich der Patch nur auf die Sicherung ausgewirkt? Warum auch immer es 15 Minuten dauert zwei bis acht Dateien zu löschen...