Re: Out of error debugging
Re: Out of error debugging
- Subject: Re: Out of error debugging
- From: Arturo Perez <email@hidden>
- Date: Thu, 28 Jul 2005 16:07:37 -0400
Art Isbell wrote:
On Jul 28, 2005, at 3:10 AM, Helge Städtler wrote:
you can increase the "survivetime" significantly by using following
parameters as launchcommands (this is what my apps run with for now
over 2
years without problems):
-Djava.awt.headless=true -Xmx1024m -XX:NewSize=2m -Xms1024m
but sooner or later this memory-error will haunt you.
Scheduling instances to restart regularly can be a workaround.
There must be some downside to setting the maximum JVM size to be
very large. Otherwise, why can a process set its own maximum JVM size
via a Java property? What are the disadvantages? Does this cause the
OS kernel to preallocate memory possibly to the detriment of other
processes?
Aloha,
Art
Java VMs are complicated beasts. One downside to setting the memory
space large is more time spent garbage collecting. On the other hand a
tread-mill garbage collector hides this time from you so you may not
notice. Another possible downside is a possible preallocation of space
so that you'll have to decide how much memory each of your JVMs will get
from your total available. But the JVM does not have to allocate all
of it up front.
Personally, I think more mileage may be gained from tuning the garbage
collector especially on multiprocessor machines where the collector can
actually run in its own thread.
See the first hit here.
http://www.google.com/search?hl=en&q=jvm+garbage+collector+tuning&btnG=Google+Search
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden