xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-François El Fouly <jean-franc...@elfouly.fr>
Subject Memory issue (was: Re: Major issue with image loading in FOP 0.95beta)
Date Thu, 08 May 2008 06:40:55 GMT
Jeremias Maerki a écrit :
>> And my next problem is to find a way to force memory recycling after 
>> this long and hefty FOP processing, but until further investigated this 
>> is OT ;-)
>>     
>
> You probably didn't get my hint earlier but with the new image loading
> framework you should actually get away with lower memory settings. In my
> tests I have been able to produce PDF with little text and many images
> with 40MB of VM memory which wasn't possible with 0.94 and earlier.
>   

Well, I got the hint, but it seems in contradiction with what I read.
So to take the picture from a bit higher:
- all XSL-FO transformation + FOP generation now work OK.
- this generates 20-30 documents (chapters) for a grand total of about 
150 Mb, to be bound together by iText.
- source XML is 1.5 Mb
- 1011 PNG images for a total of 151 Mb, the largest image is 715 kb.

Now the figures:
- XML -> XSL-FO transformation + FOP generation take 15 minutes on a 
pretty decent DELL Server (running Debian 4.0) having all the physical 
RAM possible (staging server for several customers)
- JVM has 2000 Mb (which is BTW the grand max on this 
processor/server/OS/JVM architecture)
- only one instance of FOP launched (one document generation)
- the second next step in the publication process (opening the 150 Mb 
with iText to add the bookmarks) fails immediately (at file open) saying 
it cannot allocate memory

If I try to investigate memory usage using 
Runtime.getRuntime().getFreeMemory() and logging the figures with log4j, 
these are the figures I get:
- before XSLT + FOP: 1900 Mb free/2000 Mb
- end of XSLT + FOP: 241 Mb free
- set FopFactory instance to null as a desperate hint to the GC that FOP 
objects could be/should be recycled
- I force garbage collection using System.gc()    [OK, in an application 
server this is a brute force approach, but could not see a more clever 
maneuver ATM]
- 350 Mb free/2000 Mb total
- Bind all chapters with iText
- 250 Mb free
- Force another GC
- 350 Mb free again (so the binding operation has no effect on the 
available memory).
- the next iText step still fails.

Now I don't take runtime.getXXXMemory() for bible word but at least it 
"looks like" the Xalan + FOP subsystem hogs 1500 Mb of RAM which I 
cannot recover.
So I hired the team member who's competent in profiler usage next week 
but I must say at the moment I'm still stuck :-(

Of course I've made my homework and read the f...riendly manual before 
daring to ask.
Did I miss any important indication ?


Mime
View raw message