• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

GC taking a long time

 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,
We are running an application on Weblogic Server 6.1 with EJBs (1.1)
As the number of transactions increased (we were firing about 1000 txns in a serial manner) the server went out of memory . The following are the memory settings
RAM size - 512 MB
java" -hotspot -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=8 -Xms256m -Xmx256m -verbosegc
We realized that the bottleneck was at the JMS server end as we are using JMS (MDB) for logging the messages to a file. As the number of messages in the queue increased the messages occupied a major chunk of the RAM and soon the server went out of memory.
The next thing we did was to introduce paging for the JMS Server. This Weblogic feature allowed the messages to be written to the file on the disc after a defined number of messages were written to the queue. In this way we found that our problem of "out of memory" was solved. We could fire around 1000 txns without the server giving an "Out of memory" error. However, we find that the garbage collection takes upto 17 secs occassionally!
Is there some way by which we can optimize the time taken by the GC for its activites as the transaction processing comes to a grinding halt during this time.
Secondly, as we are using the file for paging messages the size of the file goes on increasing and will certainly occupy a large disk space eventually . Is there some way by which this file size can be reduced so that we dont hit a "out of disk space" error for the file?
Regards,
Ashutosh
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We had the same problem with WebLogic. Talk to your rep. There are ways to adjust the timing of garbage collection with WebLogic. You can get WebLogic to gc more often so that it doesn't take as much time when it does.
 
Ranch Hand
Posts: 399
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Would the incremental garbage collection option available with some JVMs help with something like this? On some of the Sun JVMs, it is "-Xincgc".
I've never had to deal with a gc problem and am not familiar with server-side issues, so I really don't know whether Xingc makes sense in this context.
 
Ashutosh Shinde
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
The Weblogic GC controlling option is available in 7.0. Thats what I got to know from the site.
About the option -Xincgc the option seems to be avaialble on Sun JVM , but , how does it work ? What does an "incremental gc" mean ?
Thanks,
Ashutosh
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We were using WebLogic 6.1 and were able to control gc. Call the support line.
 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ashutosh,
Incremental garbage collection is a means of break garbage collection work into small chunks that can be done without excessive delays. That means that there's no single large delay for collection. Different incremental garbage collection schemes differ in terms of whether the root set needs to be scanned in a single step (most of the time, it does, and that can be a delay in itself... so you aren't solving all delays), and how much additional overhead is incurred on garbage collection to make it incremental -- overall, incremental collection will always reduce the total throughput of your application.
A typical incremental GC scheme would have each thread collect a little every time it allocates memory, so the threads that are doing the most allocating take the most performance penalty from it, so fairness is another advantage.
Chris
 
Evildoers! Eat my justice! And this tiny ad's justice too!
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic