 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / June 2005OutOfMemory and Swap Space
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 > 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. [quoted text clipped - 22 lines] > 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 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 On Mon, 20 Jun 2005 22:31:07 -0700, paddy_ganti wrote: > 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.  SignatureIn pioneer days they used oxen for heavy pulling, and when one ox couldn't budge a log, they didn't try to grow a larger ox. We shouldn't be trying for bigger computers, but for more systems of computers. --- Rear Admiral Grace Murray Hopper 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 > 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 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-* 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... ------------------------------------------------------------------- > 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. [quoted text clipped - 22 lines] > Your assitance is greatly appreciated. > -Paddy 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.