On Tue, Sep 2, 2008 at 8:59 PM, Randall R Schulz
I'm not sure you're analyzing the problem correctly:
1) 32-bit Java applications can use no more than 2 GB each.
2) Java applications do not intrinsically have a 32-bit or 64-bit memory model. That is determined only by the JVM on which they're executing. Thus any Java application can avail itself of a larger virtual (and physical) address space by the simple expedient of running it under a 64-bit JVM. That, of course, requires a 64-bit OS.
Yes, I know that on 32 bit platform, each Java process can only use up to 2 GB of memory. The application is configured with Xms and Xmx parameter as 1024m each, and even with this the OOM-killer is still sniping processes on this box (being sendmail, bash, and the java application itself). I also must rephrase my original comment, the problem really is not with Java per say, but the fact that even though the box has 8 GB of RAM, the kernel invokes OOM-killer when the box is only using 1.5 GB of memory, and not using any swap at all. We traced the issue to lower memory issue, where after a couple days, the amount of low memory will decrease from 800 MB to 8 MB and lower, and this is what invoked the OOM-killer. So the question is what is the root cause of this issue? Is this with the Java application?, or is there an updated bigsmp kernel with this oom-killer fixed, and if there is no fix available, how can we make sure the kernel's OOM-killer won't snipe the processes on this box (processes being sendmail, bash, to the java application itself) We tried turning off the oom-killer with the following command as we are debugging the issue, and we got "no such file or directory" echo "0" > /proc/sys/vm/oom-kill Thanks Thanks
...
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org