OutOfMemory and Swap Space

[paddy_ganti]

I have this strange issue with an Out Of Memory error thrown on a Sun
JVM 1.4.1 residing on a Windows 2000 box.

The Windows boxes is configured to have 4 GB physical RAM out of which
2 GB is available to applications on their server. ( Based on this
article at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/4gt_ram_tuning.asp
)

Out of this 2 GB , we have 3 JVMs of heap size at 768 M. Thich means a
total of 2034 Megs allocated only to Java processes implying a 2048 -
2034 = 14 Megs left for other applications and most importantly swap
space.

I have -verbose:gc logs that tell me that initially a couple of full
GCs happen followed by a monotonically increasing scavenges and just
before the OOM some hectic full GCs happen apparently to reclaim some
memory but never do.

How important is the consideration of Swap Space in troubleshooting
such an error. Since this is a production environment, I just wanted to
have an idea before I go ahead and recommend a decrease in the heap
sizes for this environment.

Your assitance is greatly appreciated.
-Paddy

 

[Wibble]

I have this strange issue with an Out Of Memory error thrown on a Sun
JVM 1.4.1 residing on a Windows 2000 box.

The Windows boxes is configured to have 4 GB physical RAM out of which
2 GB is available to applications on their server. ( Based on this
article at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/4gt_ram_tuning.asp
)

Out of this 2 GB , we have 3 JVMs of heap size at 768 M. Thich means a
total of 2034 Megs allocated only to Java processes implying a 2048 -
2034 = 14 Megs left for other applications and most importantly swap
space.

I have -verbose:gc logs that tell me that initially a couple of full
GCs happen followed by a monotonically increasing scavenges and just
before the OOM some hectic full GCs happen apparently to reclaim some
memory but never do.

How important is the consideration of Swap Space in troubleshooting
such an error. Since this is a production environment, I just wanted to
have an idea before I go ahead and recommend a decrease in the heap
sizes for this environment.

Your assitance is greatly appreciated.
-Paddy

We had huge heap allocated and still got OOM's. Turned out to be the
perm space, not the heap. Try setting -XX:MaxPermSize to 128MB

 

[paddy_ganti]

I have allocated a MaxPermSize of 256 M. Besides if it were a Perm Size
thing, the heap would not be 100% utilized, Would it?

I see that the heap is constantly utilized at 99% before the OOM
occurs.

-Paddy

 

[Stefan Schulz]

I have allocated a MaxPermSize of 256 M. Besides if it were a Perm Size
thing, the heap would not be 100% utilized, Would it?

I see that the heap is constantly utilized at 99% before the OOM
occurs.

Could you have a "memory leak" by keeping references way past the
natural expiration date? It can be frustratingly easy to have "dangling
references". Just remember, anything reachable by means of a static member
of any class will remain reachable for the entire lifetime of your
application.

I once worked on a project that tried to cache objects (only a limited
number could exist, and often the same object would be requested more then
once). To cut a long and painful story short: It is much better to
allocate and destroy the same object 10000 times then to try and be smart,
and keep it around after it should have died.

 

[asaguden]

I have no direct answer, just some tips:

We use jvmoptions 'Xrunhprof' and save to file, then use 'visualgc'
(http://java.sun.com/performance/jvmstat/visualgc.html)
to remotely monitor GC.

Then we had some help from our 'server guy' who tweaked the GC. What we
ended
up with was '-server -Xms1024m -Xmx2048m -XX:+AggressiveHeap' in
production
with 2 CPU SUN/Solaris. The -XX options might be worth checking out,
since they are targeted for different environments....

We havent had any problems since.
Hope I have provided some new info...

 

[paddy_ganti]

Stefan,

Thats exactly what I feared. I will look into static members throughout
my codebase but this forensic effort of determining exactly which
object is leaky might take some specialised tools and time.

-Paddy

 

[paddy_ganti]

Good to know them. In out environment we dont have -XX options because
they were non standard but nevertheless if they help, I dont mind
trying it out. I am already in favor of using "-XX:+DisableExplicitGC"
but will investigate the utility of the Aggressive Heap parameter once
I figure out the leak.

 

[Alan Krueger]

Thats exactly what I feared. I will look into static members throughout
my codebase but this forensic effort of determining exactly which
object is leaky might take some specialised tools and time.

I'd recommend JProfiler for that.

http://www.ej-technologies.com/products/jprofiler/overview.html

 

[paddy_ganti]

Thank You Alan. Appreciate it.
I just downloaded it and seems to offer a great potential in solving
these kind of problems.

-Paddy

*- The sufficiency of my merit is to know that my merit is not
sufficient-*