Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Netzwerke (https://www.delphipraxis.net/14-netzwerke/)
-   -   Delphi Indy + Firebird Embedded = Speicherproblem? (https://www.delphipraxis.net/90041-indy-firebird-embedded-%3D-speicherproblem.html)

omata 10. Apr 2007 21:16


Indy + Firebird Embedded = Speicherproblem?
 
So ich habe auch mal wieder ein Problem...

Ich habe einen Indy-Server, indem eine Firebird Embedded Datenbank integriert ist. Die Indy-Clients haben ebenfalls so eine Datenbank. Nun werden Daten hin und her gesendet, so entsteht ein komplexes Clustersystem. Dieses System rechnet an einem etwas größeren Problem und das dauert. Deshalb auch der Versuch diese Rechnung auf viele Rechner zu verteilen.
Leider gibt es auf dem Server Probleme. Wenn das System eine halbe Stunden läuft kommen immer mal wieder Zurgiffverletzungen, obwohl ich im OnExecute alle Fehlermeldungen abfange. Diese Meldungen können also nicht im OnExecute entstehen. Viel schlimmer ist allerdings der Speicherverbrauch. Plötzlich, aus heiterem Himmel verbraucht der Server einfach mal 40MB mehr Arbeitsspeicher. Dieser steigt dann weiter an. Nicht gleichmäßig, obwohl das System die ganze Zeit arbeitet und Daten austauscht, sondern sprunghaft. Und das in Sprüngen von > 30MB. Irgendwann ist der Server dann einfach ohne Fehlermeldung verschwunden.
Mit MemProof habe ich auch schon nach Speicherfehlern gesucht, es sind keine vorhanden.

Die Frage ist nun woran kann das liegen? Liegt es an der Datenbank oder an den Indys oder an der Kombination?

Vielleicht kann mir einer von euch einen Tipp geben.

Edit: Mir fällt gerade noch etwas ein...
Diese Probleme habe ich nicht auf einem Rechner. Ok, dort laufen dann auch nur 2-3 Clients aber funktioniert den ganzen Tag ohne Probleme. Wenn ich im Rechenzentrum dann mit >20 Clients arbeite treten die oben erwähnten Fehler auf.

Viele Grüsse
Thorsten

omata 12. Apr 2007 12:44

Re: Indy + Firebird Embedded = Speicherproblem?
 
Liste der Anhänge anzeigen (Anzahl: 1)
So, habe jetzt mal den Speichermanager gewechselt. Ich benutze jetzt FastMM. Nach 2 Stunden traten dann allerdings wieder die selben Fehler auf. Ich habe mal das Schreiben der Fehler in eine Datei aktiviert. Diese bringt mir allerdings nicht so wirklich viel. Da verstehe ich nicht so ganz wo ich jetzt weiter suchen soll. Vielleicht habe ich ja auch noch einen Compilerschalter vergessen, der noch mehr wichtige Hinweise liefern würden.
Mein Hauptproblem ist ja, das ich nicht weiss in welchem Bereich ich weiter suchen soll. Ist es Indy, Zeos, Firbird,...

Vielleicht fällt euch ja noch was ein...

Grüsse
Thorsten

hoika 12. Apr 2007 13:30

Re: Indy + Firebird Embedded = Speicherproblem?
 
Hallo

Indy, Zeos, Firebird

tja ...

Firebird: FBSERVER.EXE auf Speicheranstieg prüfen im Taskmanager

Laut dem log sieht es aber so aus, als ob du was doppelt (access violation) freigibst
und danach kommende Sachen nicht freigegeben werden.
Damit bleiben eventuell auf Firebird-Seite Transaktionen offen,
die zum Speicheranstieg bei Firebird führen.

Ich benutze memproof, der zeigt man zum Schluss an,
wo gnau (mit Sprung in den Code) Speicher angefordert wurde.

Bei dir ist es ein Objekt mit 612 Byte, was oft nicht freigegeben wird.

fastmm muss doch auch so ne Anzeige habe,
sonst nimm mal memproof.


Heiko

omata 12. Apr 2007 19:48

Re: Indy + Firebird Embedded = Speicherproblem?
 
Hallo Heiko,

Zitat:

Zitat von hoika
Indy, Zeos, Firebird
tja ...

so siehts aus...

Zitat:

Zitat von hoika
Firebird: FBSERVER.EXE auf Speicheranstieg prüfen im Taskmanager

ich benutze die Embedded-Version, da sehe ich leider nichts von der EXE.

Zitat:

Zitat von hoika
Laut dem log sieht es aber so aus, als ob du was doppelt (access violation) freigibst
und danach kommende Sachen nicht freigegeben werden.
Damit bleiben eventuell auf Firebird-Seite Transaktionen offen,
die zum Speicheranstieg bei Firebird führen.

Ich benutze memproof, der zeigt man zum Schluss an,
wo gnau (mit Sprung in den Code) Speicher angefordert wurde.

Bei dir ist es ein Objekt mit 612 Byte, was oft nicht freigegeben wird.

ok, das kann schon sein. Nur tritt der Fehler eben erst nach über einer Stunde auf. Wenn ich das Programm teste dann habe ich keine Speicherfehler. Auf nur einer Maschine kann das System ein ganzes Wochenende ohne Probleme und Speicheranstieg laufen. Der Fehler tritt leider eben erst mit vielen Clients also vielen Threads auf dem Server auf.

Zitat:

Zitat von hoika
fastmm muss doch auch so ne Anzeige habe,
sonst nimm mal memproof.

Ich nehme normalerweise immer MemProof und auch hier habe ich das schon damit getestet. Allerdings habe ich im Rechenzentrum keine vollständige Entwicklungsumgebung. Allerdings fällt mit gerade ein das ich MemProof ja auch ohne Installation benutzen kann - ich probier das mal aus.

Trotzdem danke für deine Bemühungen, bin für jede Anregung dankbar.

Gruss
Thorsten

hoika 13. Apr 2007 07:05

Re: Indy + Firebird Embedded = Speicherproblem?
 
Hallo,

wo ist das Problem,

per dunit ein paar Clients deinen Server mit abfragen zu bombardieren ?
Dass kann ja auch lokal passieren (Clients + Server auf einem Rechner).

zu memproof:
du kannst doch auch eine "memproof-enabled" Version laufen lassen,
beim Beenden wird dann im Exe-Verzeichnis eine Log-Datei erzeugt.


Heiko

omata 15. Apr 2007 18:10

Re: Indy + Firebird Embedded = Speicherproblem?
 
Hallo Heiko,

es läuft jetzt endlich. Die Lösung lag eigentlich schon die ganze Zeit zum greifen nahe, hatte sie bis jetzt leider irgendwie doch nicht gesehen. Das Property MaxConnections im Indy-Server habe ich einfach mal auf eins gesetzt. Dadurch kann es nur noch einen Thread zur Zeit geben, das ist ja auch genau das was ich benötige.

Also jetzt lief das Rechenzentrum mit 40 Rechnern 2,5 Stunden lang und auf dem Server gab es keine einzige Fehlermeldung (FastMM mit eingeschaltetem Errorlog auf Client- und Serverseite).

Gruss
Thorsten


Alle Zeitangaben in WEZ +1. Es ist jetzt 20:03 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz