Sevus erste mal

Ich habe eine Firebird-DB 1.5
vorab erstmal :
es geht um drei Tabellen
BelegPos
BelegKopf
ArtikelBewegungen (diese Daten kommen von einem Anderem Externen System)

es sollen ca 120000 Datensätze erzeugt werden

hier ist der Proc. Code

Transaktion Starten

Eine Artikelbewegung Laden

Einen BelegKopf anlegen fals dieser noch nicht vorhanden ist

Insert Into BelegPos.....
Update BelegPos set ArtikelNr = '123', Menge = 2 where PrimaryKey = 1234567
Update Preise;
Update Rabatte;

die Statements müssen einzeln angesetzt werden da auf der TBL BelegPos trigger laufen die die Pos Berechnen.

Transaktion.Commit;


Jetzt zu meinem Problem der rechner benötigt beim 1. UPD-Statement (ArtikelNr,Menge) in der regel zwischen 60-80 MB Arbeitsspeicher.
die Restlichen Positionen innerhalb eines Beleges sind vom Speicher her ok (ca 20-30K) und wird vom Windows auch wieder ordentlich frei gegeben.
Da ich aber insgesamt ca 1000 Beleg anlege habe ich einen
speicherverbrauch von: mind. 3GB Arbeitsspeicher und meist um die 9 GB Auslagerunsdatei.

Ich arbeite schon ca 3 wochen an diesem prob. Kann es nur irgendwie nicht finden was das ist.
Ich arbeite nur mit EINER Transaktion und diese Macht auch nur ca 4 Aktionen (insert,UPD,UPD,UPD)
Die Trigger die im hintergrund laufen habe ich auch schon bis aufs kleinste zerlegt aber ohne ergebniss.
immer wenn ich denke, das ich eine lösung gefunden habe und teste diese ein zweites mal geht sie schon nicht mehr.

die Transaktion gibt diesen verdammten speicher nicht mehr frei.

das Programm kann zwischendurch leider nicht geschlossen werden.

gibt es eine möglichkeit selber von delphi aus wieder den speicher frei zugeben?????

danke schonam im Vorraus für weitere fragen oder infos einfach fragen, was ihr wissen wollt.

mfg PRO_RJ


nur mit QUelltext wir es schwierig, da dieser extrem groß ist

Was/wer verbraucht soviel Speicher der Server oder dein Programm? Welche Komponenten. Hast du es mal mit anderen Kompos oder anderem Programm (Admin-Tool) versucht?

Also Ich Arbeite Ausschließlich mit TIBSQL Komponenten und der Speicher wird hauptsächlich vom server verbraucht, das kann man aber nicht sauber trennen wer wie viel brauch aber ich denke mal haupsächlich der server.
Ich habe es auchmal mit ibexpert getestet aber da sieht das ergebniss änlich aus,

was mich eben wundert ist, das wenn ich die trans mit commit bestätige, das der speicher dann nicht wieder frei wird den sonst laufen keine aktionen, die viel speicher brauchen.

80-90MB für ein Update ist schon sehr viel. Wie sehen die Trigger aus?

Ach ja das Thema Trigger.....

es Laufen folgende Trigger mit inhalt

D0009_BU_0 = ein Init. Trigger der einfach nur feldwerte Prüft da is nicht schlimmes drinne wenn er aus ist, bringts auch nicht viel.

der D0009_BU_1 ist der berechnungstrigger und das einzige was da größeres drinne ist, ist eine proc. zum suchen und finden eines artikels

AU_0 kümmert sich um die Kopfberechnung
AU_1 Kümmert sich um die lagerpflege


und jetzt kommt das phänomen

immer wenn ich denke, das ich im trigger was gefunden habe was so viel speicher braucht, und ich es ein zweites mal teste brauche ich beim ersten test deutlich weniger speicher und beim zweiten test unter exak gleichen bedinungen brauche ich wieder so extrem viel das ist ja das problem, was ich nicht verstehe

was ich noch am überlegen bin, ist: ich rufe im dem BU_0 ca 30 mal eine DLL auf (R_Func.dll und dort die FN_Round) könnte diese schon ein problem darstellen aber wie schon oben erwähnt die tests bringen mich irgendwie alle nicht weiter

ich weis nur, das es irgendwo in den BU triggern sein muss nur wie gesagt da ich nichts tragisches drinne


es wird gelesen, Ein Paar felder berechnet (alle Nummeric(18,4) und eben die FN_Round

It FreeIT bei den UDFs aktiviert?

Also Mit UDFs Arbeite ich ist die RFunc.dll

was ise "FreeIT" bzw. wo stelle ich das ein
oder wie mache ich das

Pro_RJ hat folgendes geschrieben:

Also Mit UDFs Arbeite ich ist die RFunc.dll ...

1. Erkläre mal bitte diesen Satz. 2. Dann die Frage nach den DB-Zugriffs-Komponenten. Um was geht es ? 3. SQL-Code fehlt komplett.

Ich vermute mal stark, das das Problem mit einer UDF zu tun hat, welche Speicher anfordert und nicht mehr freigibt. Ansonsten wäre, wie Hansa schon gesagt hat, ein wenig Code für Hilfestellung hilfreich.

Hi,

meine erste Frage wäre gewesen ob Du eine UDF verwendest )

Schau zu, dass Du den Code der DLL bekommst, wenn das nicht geht, wäre es vernünftiger die Funktion selbst in ne DLL zu verpacken um dann auch den Speicher freizugeben....

Lemmy

Pro_RJ hat folgendes geschrieben:
Also Mit UDFs Arbeite ich ist die RFunc.dll ...


1. Erkläre mal bitte diesen Satz. 2. Dann die Frage nach den DB-Zugriffs-Komponenten. Um was geht es ? 3. SQL-Code fehlt komplett.




1. ich nutze die UDFs aus der Dll RFunc.dll

FN_ROUND
FN_WORDNUM
FN_STRCOUNT
FN_EXPRISVALID
FN_CALCEXPR
FN_DATETOSTR
FN_TRIM
FN_SUBSTR
FN_STRLEN
FN_CHR




2. ich nutze für Den datenbankzugriff ausschließlich TIBQuerys
3. QUellcode Kann ich leider nur sehr bedingt zur verfügung stellen, das es sich hier um eine Professionelle anwendung handelt und ausserdem wären das bestimmt bald 100 Seiten Quellcode (mitt Triggern und statements).

4. an den Quellcode der UDFs komme ich leider nicht ran deswegen kann ich zu diesen nicht viel sagen

ich bin gerade dabei mal die sache mit dem FreeIt zu testen aber diese geht ja leider nur bei UDFs die einen String zurück geben un nicht bei zahlen(wo ich sie eigentlich bräuchte)

_________________

Hi,

was machen denn die UDFs die Du verwendest? Versuch mal rauszufinden ob es eine bestimmte UDF ist, die den Speicher zu müllt. Wenn Du die gefunden hast, dann schaue zu, dass Du deren Funktion entweder in einer anderen UDF findest oder programmier sie einfach nach.

Grüße
Lemmy

Es Kann eigentich nur die FN_Round sein, da das die einzige ist, die anläuft
aber an diesen quelltext komme ich eben leider nicht ran. oder kann ich die DLL extern in diesem Trigger wieder freigeben

Hi,

dann deaktivier doch zum Testen mal einfach die Funktion. WEnn es an der liegt, sollte es doch nich schwer sein einen Ersatz zu finden, so z.B. in der fbUDF die bei jeder Installation von FIrebird mit dabei ist.

Grüße
Lemmy

Habe ich auch schon gemacht bringt nichts im moment bin ich testen ob es an der init. von den Old werten liegt(da habe ich bis jetzt schon einiges gefunden was speiher verbraucht)

Ein interesantes Probelm habe ich jetzt schon gefunden:

ich nutze in dieser TBL Secondär Indexe
Wenn in diesem Index aber ein feld ist, welches NICHT init. ist
und ich suche anschließend über diesen index duert das elendig lange und
brauch zum finden von ca 700 sätzen fast 200 mb Speicher

Also ich denke ich habe gerade das Eigentliche Problem (und was wichtiger ist die LÖSUNG) gefunden:

Das Problem kam nicht vom FBServer sondern von den TIBQUery-Comps.
in den Querys Kann man die Bufferchunks einstellen womit man festlegen kann wie viel speicher für diese Datenmenge Reserviert werden soll. diese Ist Standartmäßig auf 1000 eingestellt. Das Heist er hält sich immer speicher für ca 1000 Datensätze frei gehalten. da das statements die dort ausgeführt werden nur einfache lese Statements sind wird viel zu viel speicher Belegt.

das 2. Problem war, Dadurch das es immer die selben statemnts sind hat windows einen cache aufgebaut und dadurch immer mehr speicher benötigt. das war das ganze Probem

Typisches Problem, alternativ kannst Du auch die Unidirectional Eingenschaft der TIBQuery auf True setzen, damit bewirkst Du, daß nie mehr Speicher alokiert wird, als für 2 Datensätze benötigt wird. Dabei aber beachten, daß Du eine Datenmenge dann nur sequentiell abarbeiten kannst.