Swap not occuring under DU4.0F

[Matthew Murdock]

I have a bunch of 4100 Alpha's with 2gb of physical memory. I am using a java based application, and I am running out of memory, however, dxsysinfo, vmstat, all say swap is free. vmstat 2 10, shows a r of 3 w of 244 and a u of 135 approximately. THese do not seem to change very much. whats up with this?

[Matthew Murdock]

It was found that the customer had swap in "lazy" mode (or deferred mode). After changing to immediate mode, system started to swap as needed, thereby eliminating processing core dumping due to insuffient memory, granted, it was dog slow, but, it still ran. the vmstat showed things changing.

[Matthew Murdock]

It was found that the systems had swap disabled (set in deffered mode), instead of immediate mode. After changing, the systems started to swap out like they should. The application continued to run instead of core dumping. The Java Application had a memory usage patch installed that was not working properly either. The vmstat and dxsysinfo showed , what I call normal activity.

[Dave Bechtold]

Hi Mathew,

Sounds like you resolved your initial issue. I just wanted to share with you that the Java JVM (Java Virtual Machine) does it's own Memory Management for Heap and stack. Many times issues related to tuning Java apps is related to setting the proper heap size (-mx & -ms options) or stack (-ss & -oss) for the app. Also, consider that the FastVM, default VM for Java V1.3 and higher on Tru64, requires even more memory for the app in contrast to using the Classic VM. The Java Release Notes have a lot of good information on heap, garbage collect, and tuning. Of course the JVM Heap is limited by the processes limits under ulimit and proc subsystem for hard limits. These may need to be raised to accommodate the apps need for memory, otherwise the JVM will run out of a resource and fail with "Out of memory" or core dump depending on what's it's doing. It sounds as if the app was maybe hitting the process limits. While in Lazy mode the system should have started swapping as the demand for system virtual memory increased, versus Eager mode which would have caused the app to reserve virtual space as it created the process.

Another good thing to do in situations like this is to run with -verbose and -verbosegc options to see how well the app is doing with heap and if it's actaully exhausting the JVM Heap or process limits.

I just wanted to share this information based on my own experiences with running Java apps.

Hope it helps.

Dave Bechtold