[xep-support] 64 bit env

[Curelaru_Cristian at emc.com]

Hi,

 

It looks like I was wrong about which process was taking a very long
time. I think I was expecting to be XEP at that point in time and I also
saw xep in the command line and I jumped to the conclusion it was.

Actually it is the XSLT generating the FO file for XEP that is taking
long.

 

Sorry for pointing the finger in the wrong direction. 

 

-Cristian Curelaru

________________________________

From: owner-xep-support at renderx.com
[mailto:owner-xep-support at renderx.com] On Behalf Of
Curelaru_Cristian at emc.com
Sent: Monday, April 20, 2009 11:37 AM
To: xep-support at renderx.com
Subject: [xep-support] 64 bit env 

 

Hi,

 

I was wondering if somebody ran tests with RenderX in 64 bit
environments. Is it supported - not just to run but to take advantage of
the 64-bit performance?

 

I have a sample that has around 8200 files (dita and images together)
which fails on 32-bit environments with OutOfMemory exception. The FO
file that goes into XEP is 300M.

We decided to test the same on a 64-bit environment. 

This system is windows 2003 enterprise 64-bit, it has on it a java 1.5
64-bit and around 18G mem. I started the same test but it has been
running for a few days now. There is no outofmem error this time, but I
have observed the Renderx process is not using more than 4.2G of
physical memory (the theoretical limit of 32 bit) and it takes the rest
from the page file. There are ~ 13G mem available at all times.

 

I thought that maybe something on the system is not really 64-bit (this
environment being set-up on a VMware image - ESX server) but I noticed
that another process was able to use more physical memory than mentioned
above. Also, I wrote a small program that would just fill the memory
with objects - around 7G. this program was able to take those 7G from
physical memory.

 

The XEP library used is 4.10 and the java process is started by
specifying 8192m max memeory. 

 

So, any reason why xep would fail to use more physical memory or is it a
know issues or this was never tested?

 

Thanks,

Cristian Curelaru

EMC

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20090421/3d9812e9/attachment.html>