Steen,
The best settings are dependant on many things, not least of which is the the version and vendor of the Java VM. Improving the efficiency of garbage collection has been and remains one of the major activities of VM vendors such as Sun, IBM and BEA, particularly in respect of server environments. Each VM had different options, uses different strategies and responds differently to the options.
It would be informative to benchmark James with a variety of VMs and options. Which VM are you using?
Of course I should have told you that. I'm using Suns JDK 1.4.2_01 client VM.
As a general rule, -Xm should be set no larger than the heap size required to avoid out of memory conditions. Anything larger will simply delay garbage collection and the time taken to run the garbage collection will be greatly increased. In other words, performance will be degraded.
How would you determine the heap size required? It's almost impossible.
Now a days users are sending multi megabyte mails, with word documents,
access databases and other very big files. And since James are multithreaded it must be able to handle several very big mails simultaneously.
Most VMs stop all threads when running a GC, though some recent ones do achieve some parallelism, but NOT if GC is explicitly invoked. Therefore, large GCs can cause time-sensitive applications, such as James, to start seeing time-outs of sockets, etc.
In theory that could happen but in practice it won't. I haven't seen a GC on my box bigger than 0.2 seconds, and I guess timeout values for
normal mail clients and SMTP servers are much bigger.
http://java.sun.com/docs/hotspot/PerformanceFAQ.html contains a number of useful hints and tips which you may wish to consider. If you are using a HotSpot VM, specifying -server will give better performance for an application such as James.
But also uses more memory.
Another thing I've done is force James to run the Garbage Collector more often. I'm using the new FetchMail feature, and every second minute a fetchTask is run. In this fetchTask I've added a call to System.gc() to force the Garbage Collector to run.
See http://java.sun.com/docs/hotspot/PerformanceFAQ.html#15 that says, never force GC. Get the environment right and VM managed GC will always do a better job.
I see what they mean but their VM does NOT do a better job. It's NOT acting like a good citizen. Allocated memory are NOT released even though it's not used.
I've done some tests, running James with and without a periodic
call to System.gc(). In each test I have started James and after approximately 5 minutes sent a mail with a 3.6 Mb attachment to
my self, and then again after an hour the same mail again.
I've attached two gifs (hopefully it works this time). The first
(fig1.gif) is a picture of James' memory usage without a periodic System.gc(), and the second (fig2.gif) is with. The red lines are the total heap allocated and the blue lines are the used memory.
As you can see, James is not acting like a good citizen in the first picture. Handling a big mail allocates a lot of memory but the memory is not released again. In the second picture you can see that the total heap drops quickly after handling a big mail.
Note, if you have a dedicated box running James or you have so much memory that you can reserve 1 GB for James I totally agree with you. I'm talking about being a good citizen, making room for everybody. Their should be room for the database server, web server, cvs server or whatever on the same box.
You might like to browse http://www.javaperformancetuning.com/ which contains much information and many useful links.
Sure I will :-)
Cheers,
Steen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
