Steen Jansdal wrote: > > > > > As a general rule, -Xmx 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.
James limits the number of spool threads (default is 10). You can, and probably should, define the maximum message size. This done, there is an upper limit beyond which James will require no more heap space. Throwing 1, 2 or 102 * max threads messages of maximum size at James concurrently should require the same heap size. That heap size is the smallest that supports this scenario without getting out of memory conditions. You have to determine this by experimentation. > > 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. That's good but your current tests have stressed you more than James :-) > > > 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. Memory size * duration may be greater, but not absolute memory size. > > > >>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. This is symptomatic of having too large a maximum heap size set. If you do not specify -Xmx the default values, which vary by OS, are way smaller. > I've attached two gifs (hopefully it works this time). Nope! Try zipping them. > As you can see, James is not acting like a good citizen You were more correct in your earlier assertion that the VM is not acting like a good citizen. While I don't discount that there are areas for improvement in James' use of memory, this is all about setting the correct parameters so that the VM knows what it is you expect of a 'good citizen'. Think of it as a well intentioned child that needs a lot of guidance. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
