Norman,
> > I'm back to running a test. Started JAMES
> > with -server -Xms128M -Xmx256M -Xrunhprof heap=sites,depth=12
> > If this will just run for 48-72 hours, hopefully I can gather
> > some useful data.
> let us see what the new debugging show us ;-)
So far, I have a working hypothesis, but will continue to monitor the heap.
We may be getting hit by the known-to-be-bad cache inside of InetAddress.
After 12 hours or so, InetAddress cache related objects appear to be in
excess of 20% of heap usage, and increasing. From where? It appears to be
a single line in the SMTP handler that was changed in trunk, but not
backported.
2.3.0:
remoteHost = socket.getInetAddress().getHostName();
trunk:
remoteHost = dnsServer.getHostName(socket.getInetAddress());
The dnsServer call does:
public String getHostName(InetAddress addr){
try {
return org.xbill.DNS.Address.getHostName(addr);
} catch (UnknownHostException e) {
return addr.getHostAddress();
}
}
which does not use the InetAddress cache.
By the way, a bit of observation regarding garbage collection. Because of
the memstat instrumentation in RemoteManager, I can make sure to take heap
dumps only and immediately after the JVM does a full GC. And I can see
that with 1.4.2_09 under load and with heap dumping on, it doesn't appear to
GC at all until it must. Asking for a GC under load doesn't often provide
one, so it is good to know when one *does* happen. When I want to dump the
heap, I just keep watching for the full GC, and then I request the dump.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
