Mein Prozess hat auf einmal hundertausende Handles

[Luckie]

Eventuell vergessen im Fehlerfall noch offene Handles zu schließen? Try...except...end?

[Der schöne Günther]

Dann, denke ich, würde das bei allen Installation auftreten und höchstwahrscheinlich auch die Handle-Anzahl mit der Zeit kontinuierlich wachsen.

Ich werde zunächst irgendwie mal ein bisschen Logging einbauen was die Handle-Anzahl des eigenen Prozesses angeht, bei dem Kunden aktivieren und ansonsten denke ich darüber nach alle Druckvorgänge in einen eigenen Prozess auszulagern, den könnte man nach jedem Druck-Vorgang schließen...

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1379092)

Dann, denke ich, würde das bei allen Installation auftreten und höchstwahrscheinlich auch die Handle-Anzahl mit der Zeit kontinuierlich wachsen.

Nicht unbedingt.
Eventuell knallt es ja auch nur bei diesem Kunden,
dann würde eine falsche Fehlerbehandlung auch nur da zuschlagen.

[TiGü]

War denn 23 Stunden und 59 Minuten alles gut und schön und grüne Wiese mit Regenbogeneinhörnern mit Puschelschwänzchen UND DANN ging der Hades auf und verschlang alle Handles des Systems ODER stieg nur für dieses System kontinuierlich vom Start an im Laufe der Zeit die Anzahl der Handles?

Workaround Idee 1: Ist es praktikabel eure Anwendung alle XX Stunden automatisch neu zu starten?

Workaround Idee 2: Druckausgaben in PDF umleiten und die dann später zum Netzwerkdrucker schicken?

Idee von Luckie nochmal aufgreifen und alle Try-Handler angucken.
Irgendwo werden Handles im Fehlerfall nicht zu gemacht.
Wird der Fehler wirklich protokolliert?
Ggf. schluckt das einfach die RTL oder sonstige verbaute Internet-Komponenten und man bekommt nichts mit?

[himitsu]

Nur der Vollständigkeit halber:

Natürlicgh kann es sein, dass z.B. ein Usermdedriver des Druckers/Printsystems hier durchdreht und die Handles nicht im eigenen, sondern in fremden Code entstehen (dort nicht richtig freigegeben werden).
Mit einem anderem Programm drucken und da schauen, ob das Problemchen dort auch auftritt.



PS: Man kann die eigene Anwendung auch auf mehrere EXEn verteilen und das Ausdrucken in einem Subsystem erledigen, damit der Hauptprozess störungsfreier arbeiten kann.

[Der schöne Günther]

Zitat:

Zitat von TiGü (Beitrag 1379101)

War denn 23 Stunden und 59 Minuten alles gut

So ungefähr. Ich konnte keinen kontinuierlichen Anstieg beobachten. Ich konnte auch nicht ständig dort im Task-Manager wühlen oder in Ruhe den Windows-Performance-Monitor aufsetzen da Zugriff nur per TeamViewer und die Leute brauchen den Bildschirm zum arbeiten.

Zitat:

Zitat von TiGü (Beitrag 1379101)

Ist es praktikabel eure Anwendung alle XX Stunden automatisch neu zu starten?

Nein, das ist leider keine Option.

Zitat:

Zitat von TiGü (Beitrag 1379101)

Wird der Fehler wirklich protokolliert?
Ggf. schluckt das einfach die RTL oder sonstige verbaute Internet-Komponenten und man bekommt nichts mit?

Das Problem ist ja: Was ist "der Fehler"? Ich sehe nur die Auswirkungen: Hohe Handle-Anzahl im Task-Manager und im Exception-Log des Programms dass alle möglichen Operationen wie Dateien öffnen oder Netzwerk-Sockets mit NOT_ENOUGH_QUOTA fehlschlagen.

Zitat:

Zitat von himitsu (Beitrag 1379104)

Mit einem anderem Programm drucken und da schauen, ob das Problemchen dort auch auftritt.

Das werde ich unbedingt testen müssen. Und zwar nicht nur Notepad, sondern am besten gleich einmal ein komplettes Delphi-Druck-Test-Programm mit Vcl.Printers und FastReport.

[himitsu]

Etwas zum Loggen.
GetProcessHandleCount


Wir hatten auch ab und an mal Probleme mit irgendwelchen Ressourcen, in einem Service, beim Kunden.
Bei uns läuft daher im Hintergrund ein Thread, der regelmäßig danach schaut und das loggt. So können wir dann nachsehen wann in der letzten Woche sich dort was änderte.
> Speicher (HDD, System-Memory, VirtualMemory, DelphiMM-Allocation), Handles, Threads, CPU-Auslasung (Prozess und System), Status einiger Locks (CritialSections), ...

[Der schöne Günther]

Ja, genau solchen Kram einzubauen bin ich grade dran 8-)

Insbesondere den FastMM Usage Tracker.

[TiGü]

OT:
Das Schlimme ist, das bei solchen aufwendigen und zeitraubenden Fehlern die Ursache sich innerhalb von ein bis drei Zeilen Quelltext finden und fixen lässt.
Der Aufwand zur Fehlersuche und tatsächliche Fehlerbehebung stehen oft in einen krassen Missverhältnis.

[Der schöne Günther]

Oh ja. Aber noch viel schlimmer als diese drei Zeilen (die potentiell noch bei anderen Kunden zutreffen könnten) wäre die Tatsache wenn es sein beschissener Netzwerkdrucker ist den es nur bei ihm gibt :twisted: