• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Frank Carver
  • Henry Wong
  • Ron McLeod
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Himai Minh

OutOfMemory Issues

 
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We are having OutOfMemory issues in our appllication.

The logs points to Heap Size issue :

<AF[7380]: Allocation Failure. need 3276816 bytes, 108 ms since last AF>
<AF[7380]: managing allocation failure, action=2 (274822776/1073740288)>
<GC(7420): GC cycle started Thu Sep 14 13:39:32 2006
<GC(7420): freed 14574792 bytes, 26% free (289397568/1073740288), in 4835 ms>
<GC(7420): mark: 1165 ms, sweep: 39 ms, compact: 3631 ms>
<GC(7420): refs: soft 0 (age >= 32), weak 0, final 16, phantom 0>
<GC(7420): moved 2372574 objects, 106665600 bytes, reason=1, used 13592 more bytes>
<AF[7380]: managing allocation failure, action=3 (289397568/1073740288)>
<AF[7380]: managing allocation failure, action=4 (289397568/1073740288)>
<AF[7380]: clearing all remaining soft refs>
<GC(7421): GC cycle started Thu Sep 14 13:39:33 2006
<GC(7421): freed 77864 bytes, 26% free (289475432/1073740288), in 1195 ms>
<GC(7421): mark: 1158 ms, sweep: 37 ms, compact: 0 ms>
<GC(7421): refs: soft 17 (age >= 32), weak 0, final 1, phantom 0>
<GC(7422): GC cycle started Thu Sep 14 13:39:38 2006
<GC(7422): freed 14520 bytes, 26% free (289489952/1073740288), in 4542 ms>
<GC(7422): mark: 1158 ms, sweep: 36 ms, compact: 3348 ms>
<GC(7422): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
<GC(7422): moved 286669 objects, 12860328 bytes, reason=1, used 40 more bytes>
<AF[7380]: managing allocation failure, action=6 (289489952/1073740288)>
<AF[7380]: totally out of heap space>
<AF[7380]: completed in 10577 ms>


1. Any idea what should be the next steps for us ?
2. On reseraching the internet, many things points to 'Connection Pooling' , recordset etc but that does not seem to be an issue in our case.


Any inputs to where should we be targetting next ?

All help appreciated.

Thanks,
Milan
 
Marshal
Posts: 27371
88
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Next step should be to find out what kind of objects are really filling up your memory. If your code is doing something like storing elements in a list that expands forever, then that would be your problem. But if you don't see anything obvious like that, you should get a Java profiler and let it watch your memory allocations.
 
Ranch Hand
Posts: 676
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your problem is before GC can collect unused object from memory, your application piling up many more object.

Avoid object creating. It is not at all connection pool problem.
 
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jignesh Patel:
Avoid object creating.



Isn't it rather hard to write a Java program without creating objects ;-)

The problem is unlikely to be how many objects are being created, but rather what is holding references to them.

Almost every Java program creates loads of objects, but most of them are short-lived because references to them are not held for long.

Look for places where you may be storing long-lived references to objects. Global collections, caches, pools etc.
 
Doshi Milan
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for all for the valued suggestions.

I agree that it maybe due to the style of coding. Now, our project is over two years old and developed by over 20 different developers. So... the million dollar question is.....

How do we know what code is the Culprit...
How do we know WHICH are the OBJECTS that are NOT being released...
Are there any tools for it ? Can Java Profilier point us to the object which is causing the issue ?If not, which other tool ?

Thanks,
Milan Doshi
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Doshi Milan:
Are there any tools for it ? Can Java Profilier point us to the object which is causing the issue ?If not, which other tool ?

Thanks,
Milan Doshi


Yes, use a profiler.
After you've encountered enough OutOfMemoryErrors, your first call will be a profiler - speculation from another is nothing more than a red herring - and in some cases an impossibility under the given circumstances.
 
Doshi Milan
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks everyone for valuable inputs, the Profiler has been installed and hopefully provide more information.

Regards,
Milan
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Running profiler may help you find some leaks, but your application may just need more memory:have you tried changing -Xmx value (to increase memory for JVM). The default value is not that large. Its maximum value can be about 1.4G for a 32bit.
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Usually, the major cause for having many live objects cannot be cleared is the wrong scoping and cause the memory leak, so you better check all object variables defined with static outside the method.
Besides, if you increase the xmx heap size, it should be limited by the physical memory; otherwise, it will downgrade the performance a lot due to paging.
 
If you settle for what they are giving you, you deserve what you get. Fight for this tiny ad!
Garden Master Course kickstarter
https://coderanch.com/t/754577/Garden-Master-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic