Releasing memory after printing report.
Hi,
We use reportbuilder in a c/s application and in a ISAPI dll to allow end
users to design reports (c/s) and run them on the web.
D5/D7, RB7.02 Enterprise. DOA, Oracle DB, TExtradevices for pdf output.
When I watch memory usage in the c/s app, I see that printing a simple
report aquires a certain number of Mbs. This memory stays occupied after
closing the report preview. Then when I go into Report explorer again, and
just as I start printing the same report the second time, the memory seems
to get released before it is again starting to consume memory.
No leaks.
The problem is with the multithreaded web application. The same thing
happens there. The memory gets freed just before the new report is starting
to consume memory. Since A reportbuilder report easily eats 20-40Mb and we
have several threads it is blocking up the webserver with several hundred
Mbs. This is slowing down everything, and frustrating the IT admins very
much (They think we have a memory-leak)
I tried doing "ppReport1.template.new; " after the report was printed, but
it didn't help at all. Still the same thing. The memory was just released
the next time a real report was run.
What to do about this?
I have thought about dynamically creating the tppReport, and freeing it
after each time, but I don't want to go that route unless I really need to.
Best Regards,
Paul Wiik, Lynx Technologies.
We use reportbuilder in a c/s application and in a ISAPI dll to allow end
users to design reports (c/s) and run them on the web.
D5/D7, RB7.02 Enterprise. DOA, Oracle DB, TExtradevices for pdf output.
When I watch memory usage in the c/s app, I see that printing a simple
report aquires a certain number of Mbs. This memory stays occupied after
closing the report preview. Then when I go into Report explorer again, and
just as I start printing the same report the second time, the memory seems
to get released before it is again starting to consume memory.
No leaks.
The problem is with the multithreaded web application. The same thing
happens there. The memory gets freed just before the new report is starting
to consume memory. Since A reportbuilder report easily eats 20-40Mb and we
have several threads it is blocking up the webserver with several hundred
Mbs. This is slowing down everything, and frustrating the IT admins very
much (They think we have a memory-leak)
I tried doing "ppReport1.template.new; " after the report was printed, but
it didn't help at all. Still the same thing. The memory was just released
the next time a real report was run.
What to do about this?
I have thought about dynamically creating the tppReport, and freeing it
after each time, but I don't want to go that route unless I really need to.
Best Regards,
Paul Wiik, Lynx Technologies.
This discussion has been closed.
Comments
borland's groups about it).
The only way to really check for memory leaks is to run a mem-checker on the
DLL. Most of the newer mem-checkers should work just fine for doing this.
--
Ed Dressel
Team DM
Thanks for the reply. Please understand this. I'm not saying reportbuilder
leaks memory, but it keeps some cached data I think. Please look at my
example. I can send you the source (your example app actually) and the DB.
D5, Rb Enterprise 7.02, DOA.
Based on your "End user Reporting using Oracle 8 with the DOA" (just
connected it to one of our DB's instead of scott/tiger).
I know Task manager isn't fully realiable, but I'm not interested in any
small leak here. I'm just interested in the big memory chunk that stays
occupied until you load another report. There is also the fact that it's
very slow.
consider the following example of time / Memory usage:
1. EndUser started. 8.720K
2. Launch Report Exploerer 14.144K
3. Open the report in Design mode. It opens in a few seconds. Very fast.
(The report is a report with 10 subreports connected to separate datasets).
App now shows 14.592K
4.Closing the design mode 14.596K (I don't mind so far)
5. Running Print Preview. App consumes 96% CPU saying accessing data.
- First 22 Seconds 96% CPU, then a pause (probably waiting for Oracle)
- Then processes 27 seconds more (96% CPU).
- Displays showmessage from Main.Detail.beforeprint.
Now the App is 30.844K big.
Click ok on showmessage. Prints very quickly and is 32.084K
6. Close Print Preview. App stays 32.084K
7. Open the report in Design time again. This time this takes approximately
1 minute to open in designmode!!!! The memory gradually creeps down during
that minute.
App is 15.360K after it is opened in design-mode.
I fully accept that it is 15.360K (slightly bigger than in #3) when opening
in design mode again. This is probably Task manager showing the wrong
figures (plus the crappyness of Delphi Memory manager).
I would like some hints on the following:
A. What is done before really printing the report (see item 5 above). Why is
it consuming so much mem and taking up so much CPU.
B. Why is this memory freed only when you open another report (for example
in design mode, see item 7). Is there a way I can flush it when the report
have successfully printed?
Best Regards,
Paul
Did you free the report? Did you run a mem-checker against your app?
approximately
This sure sounds like Windows garbage collector :-) Did you do any research
on the garbage collector?
Ed Dressel
TEam DM
Thanks for your reply, but I'm sorry to say I have to bother you again : /
We are still struggling with memory and slow speeds.
What happens in preprocessing a Preview that can consume much resources?
- Could it be caching a lot of DB info (we sure have a lot of tables in our
DB, but not many used in the reports).
- Are DOA in conjunction with RB exceptionally resource demanding?
1. No, did not free report because thats not in your documentation and also
not in your examples. It will be a lot of hazzle to set up all the
properties etc. after dynamically creating RB. Of course if this is what I
have to do, then I'll do it
2. Did not run a mem-checker. memProof would probably take a two days to
process this, and in the end give much to detailed information for this use.
I know for a fact that task manager is reliable when the delphi app uses
qmemory.
Important :
Since we started using "qmemory.pas" in our apps, what you refer to as the
"windows garbage collector" have started working as it should. Right now it
seems that the fault lies more in the delphi memory manager than in windows.
(qmemory replaces the default delphi memory manager).
The ISAPI used to grow, and never free up memory (fragmentation), but this
is now only the case when we run RB reports.
For normal usage, Task manager now shows host memory growing as ISAPI
processes stuff, then the memory get's released again straight away when
it's finished. It used to grow at least 4k for each ISAPI request/response.
research
I would really recommend you taking a look at qmemory (I think the vital
part is decommitOverstock on idle). I think it's a rumor that windows/task
manager is so crappy at houskeeping/reporting memory size.
I saw another thing today. When I ran the report mentioned earlier (10
subreports) from the ISAPI witch have suppress dialogs, it used 30 seconds
of CPU time (Task manager) and grew 15Mb in size just to tell me "table not
found". The error happened because it was set up with wrong dataowner, but
I'm stunned because it opens so quickly in design-time.
Our memory growth and lag happens only in print/preview, and even before the
data-query is sent off to the DB.
I wonder what is wrong with our report-templates since they consume so much
and are so slow. Your example reports run quickly with so little memory
usage that the not released memory is not a problem.
When we run our report with 10 subreports it produces only 2 A4 pages!! It's
using 30 seconds/35Mb to build this, and 1 minute to free it afterwords. The
release process only happens when opening a new report in design/preview
(probably also on free, but I haven' tried that).
Best Regards,
Paul