Inoffizielles deutsches Xbase-Forum

Hallo zusammen

ich nutze seit langem L&L in einer Web-App zur erstellung von diversen PDF Files das läuft seit vielen Jahren eigentlich gut. Seit einiger Zeit jedoch belegt das Programm langsam (über Tage) aber sicher immer mehr Speicherplatz (500-600 MB) bis es schlussendlich nicht mehr reagiert und neu gestartet werden muss. Das Programm läuft als Dienst.

Die ganze Druckfunktion - PDF Erstellung ist in einer Funktion mit nur einem Ausgang (Return). Das heisst Close-Job wird in jedem Fall zuverlässig ausgeführt.

Ich habe bereits diverse Tricks zur Speicherbereinigung angewendet, die haben in allen anderen Fällen geholfen. Jedoch nicht bei dem L&L Problem. Der vom Programm belegte Arbeistspeicher beginnt mit dem ersten Aufruf von L&L langsam aber sicher zu wachsen.
Obwohl der Druckjob mit Sicherheit geschlossen ist, bleibt L&L im Arbeisspeicher und nutzt weiterhin CPU usw.

Der Combit Support kann auch nicht helfen .... ich kann den Fehler nicht gezielt herbeiführen ....

Hat vielleicht jemand eine Idee?

Aber das hier ist es nicht?

https://www.xbaseforum.de/viewtopic.php ... 64#p140164

Wollte auch gerade fragen, welche Version benutzt du ?

Tom, es wäre schon möglich dass es das selbe ist. Ich nutze aber keine Vorschau, kein RTF, kein direktes Druckken und die PDF's sind meist nur 1-2 Seiten, max. auch nicht über 5 Seiten und damals hatte ich das Problem noch nicht. Auch die verwendeten jpg's sind nicht Ursache.

Wolfgang, aktuell ist es die Version 27.004

Der Combit Support hat meinen Case geschlossen ohne auch nur eine Antwort oder Idee zum Problem zu haben. Auch wieso die L&L DLL's nach CloseJob und dllunload() mit mehreren aktiven Thread im Speicher verbleiben, diesen belegen und ständig mehr CPU Leistung verbrauchen als die Alaska Runtime im Leerlauf wurde mir nie beantwortet.......

Hab jetzt mal mit der DsListLabel in einer for next Schleife 1000 PDFs erzeugt. Der Speicehr lief nicht voll, und nach dem CloseJob wurde er auch wieder freigegeben.
Der Test ist allerdings nur mit einem Thread.
Evtl. müsste man jetzt da mit mehrern Threads noch einen Test machen

LL VErsion 27.4.2022

Hallo Karl

Ein Thread kann ja wegen einem Fehler sich beenden, wird auch dann ein JobClose aufgerufen?

Marcus Herz hat geschrieben: ↑Mi, 14. Sep 2022 14:40 Ein Thread kann ja wegen einem Fehler sich beenden, wird auch dann ein JobClose aufgerufen?

Hallo Marcus

Nein. Dann natürlich nicht. Aber dann hätte ich einen Eintrag im Fehlerlog oder einen "Kopflosen" Thread.
Ich habe schon Einträge im Fehlerlog aber die kommen erst wenn der Speicher voll ist.

Und wenn DebWin4 mitläuft - da ist auch nichts zu sehen?

Das habe ich noch nie versucht. Hat dann DebWin4 Zugriff auf einen Serverdienst?

Würde ich meinen. Wenn wir unser Backend als Dienst laufen lassen und in DebWin4 L&L capturen lassen, geht das jedenfalls. Einfach probieren, sind ja nur drei Klicks.

Ach so. Es muss natürlich auf diesem Server laufen.

Habs gerade versucht. Geht nicht. Zeigt nichts an. Kann aber auch nicht den selben User verwenden unter welchem der Dienst läuft.......

Kann aber auch nicht den selben User verwenden unter welchem der Dienst läuft.......

Dann wird's auch nicht gehen.

Hallo
Das mit dem Speicher hat mir jetzt keine Ruhe gelassen.
Ich habe noch mehrere Test durchgeführt und der Speicher läuft voll. Die Handles aber sind stabil

Ich hab aber nicht lokalisieren können, wo der Speicher verloren geht.
Egal, ob Direktdruck oder PDF Export, Fehler ist der gleiche.
Egal, ob mit Threads oder direkt, Fehler ist der gleiche.

Hab mit Sysinternal procexp64 kontrolliert.

LL Version immer noch 27.4

Ich hab mein Test PRG angehängt, vielleicht will ja jemnad anderer da noch suchen.
In dem PRG wird in einer Schleife mehrmals ein PDF-Export oder Druck angestossen. Siehe Kommentare

Marcus Herz hat geschrieben: ↑Do, 15. Sep 2022 13:27 Ich habe noch mehrere Test durchgeführt und der Speicher läuft voll. Die Handles aber sind stabil

DANKE DANKE....
Genau so ist es. Die Handles unter Xbase sind stabil. L&L füllt einfach den dem Programm zugeordneten Speicher bis es bummst.

Könntest du das bitte an Combit dem Hr. Rauchfuss mitteilen!

Ich hab noch mehr Tests durchgeführt:
LST ohne Bild

1000x JobOpen / Jobclose => kein Speicherverlust
1000x JobOpen, 1.000.000x DLL API Aufufe LLDefineField() , Jobclose => kein Speicherverlust
1000x JobOpen , Report, Drucker-INIT, Jobclose => kein Speicherverlust

1000x JobOpen , Report, Drucker-INIT, LlPrintWithBoxStart, PrintJobclose => kleiner Speicherverlust
1000x JobOpen , Report, Drucker-INIT, LlPrintWithBoxStart, Druckschleife, PrintJobclose => grosser Speicherverlust

Geb das jetzt an Combit weiter. Halt euch auf dem laufenden

Wir machen je Thread im Programm (Modul) immer nur ein JobOpen und schließen Printjobs erst beim Verlassen des Threads (und im AppExit und im ErrorSys). Könntest Du das auch noch ausprobieren, Marcus? Büdde!

das gleiche:
Ich hab obige Kombinatiionen in jeweils einem Thread laufen: thread macht Jobopen / Jobclose, etc.
insgeasmt 440 Thread Aufrufe, jeweils neues Objekt
bis zu 5 Threads Parallel,
gleiches Fehlerverhalten,

Es macht keinen Unterschied, ob im Thread oder direkt

Vielleicht das auch nochmal im Legacy mode ausprobieren ?
(Unter HKEY_CURRENT_USER "Software\combit\cmbtll" "PDF.LegacyRenderingMode" = T setzen)

You should not try to use perfmon, task manager or any tool like that to determine memory leaks. They are good for identifying trends, but not much else. The numbers they report in absolute terms are too vague and aggregated to be useful for a specific task such as memory leak detection.

Ich habe die Tests vorerst eingestellt. Heute das ganze etwas sturkturierter durchgeführt.
Alle obigen Scenarien mehrmals durchgeführt mit Zwischenstopps, um Speicher zu lesen. Mal geht der Speicher hoch, dann wieder runter. Es gibt keine Regel. Der gleiche Test braucht mal mehr, mal wenoger Speicher. Da spielen wohl noch andere Komponenten rein, z.B. der Garbagecollector.

Ich hab ca 4500 PDFs erstellt und die Private Bytes im Procmon gingen um ca. 4 Kb oder sind das 4000 Kb hoch, da ist die Anzeige unklar.

Hab den Test auch nochmal mit Threads durcgeführt, bis zu 50 Threads paralell, jeder erzeugt mehrere PDFs. Verhält sich auch nicht anders. Es wird mehr Speicher belegt und nicht mehr freigegeben, aber er bleibt konstant



@Wolfgang: Nachdem ich den Registry Key eingetragen habe, hat es noch mehr Speicher belegt.

Hallo Karl

Nochmal zurück zu deinem ersten Post. Ich hab ja jetzt in Schleifen auch jeweils ca 4500 PDFs erzeugt (Bin mit dem Löschen kaum nachgekommen).
Konnte aber nicht fetsstellen, dass der Speicher voll läuft. Nach dem 1. Aufruf von LL wird Speicher beansprucht (u.a. von den EXTERN Funktionen, wleche ja alle STATIC template anlegen). Die bleiben ja dann im Speicher. Wieviele PDFs erzeugt du den in deiner APP, bis du den Speichervelust fetsstellen kannst?

Hallo Marcus

Das kann ich leider nicht genau bestimmen. Es ist eine Web-App als Dienst mit einigen Threads. Leider läuft so alles auf einem CPU Kern auch wenn mehrere User mehr oder weniger gleichzeitig ein PDF benötigen gibt es durch den einen CPU Kern der für alles zur Verfügung steht schon Verzögerungen. Ob es damit zusammenhängt?

Das Sample Invoice von Combit entlädt jedenfalls die Module korrekt ..... Bin jetzt am Experimentieren.

Nur zur Info: Ich hab das Sample2, die Artikelliste zum Testen verwendet. Da ist ja auch ein GIF drin

Heute konnte ich auf einem Server beobachten wie der Speicher von 30MB auf jetzt 250MB volläuft. (Taskmanager)
Ich suche nun nicht mehr nach gross nach der Ursache sondern nur noch einen Weg das Problem zu beseitigen. Habe mir schon überlegt zurück auf eine alte Version von L&L zu wechseln. Das Ausgabe Programm(PDF Erstellung) ist seit der Version 17 praktisch unverändert und die Probleme sind relativ neu ....

Wieviele PDFs sind ca. erzeugt worden? Kannst du das abschätzen

einige hundert....