Yoav, thanks for your insightful comments.
> I like OptimizeIt, having used them all. But the features are fairly similar.
> A Profiler is a key tool I highly recommend using frequently.
I think you are right, and we will start using one as a regular part of our
development.
> However, profilers are not designed for production use. They will require much
> more memory (often an order of magnitude) and slow down the system (again,
> often by an order of magnitude or more) when running. For production, there's
> no substitute for good logging that you can control at runtime, e.g. log4j.
We are not using runtime-controllable logging at this time. It seems that log4j
is the de facto standard, so I suppose that's what I'll try first. How does the
JDK 1.4 logging facility compare to log4j?
Have you used any of the profilers designed for production use like RootCause
or jvmstat? I'm strongly interested in trying one of them out.
> What does the hs_err file say?
JRockit does not produce an hs_err file that I can see. It does do a dump to
catalina.out, which doesn't contain anything obviously useful to me. It does
output 'registers', 'stack', 'code' and 'loaded modules'. All are in hex except
the loaded modules.
> Maybe you need to try on a different OS? A different linux kernel? On
> Solaris, for example, you will get JDK crashes unless you download the Sun OS
> patches for the JDK.
I'm open to suggestions. We were pretty much a Windows shop until about 6 months
ago when we started transitioning lots of machines to Linux. So we have a knowledge
investment in Linux that I'd like to maintain. We are running the 2.4.18-27.8.0smp
kernel and I suppose we could set up a server with 2.4.20 and see if that made a
difference. Any other operating systems you would recommend?
>> We recently migrated from a Windows 2000/ServletExec 3.1/Sun HotSpot client
>> 1.3.1 environment which didn't have these problems - I'm not sure what to
>> think at this point.
> And the code didn't change, right? You only migrated do a different OS and a
> different VM?
The code did change a bit, in that ServletExec was not fully compliant with some
parts of the servlet and JSP specs, and our code was unintentionally taking advantage
of that. We also used SingleThreadModel extensively which of course Tomcat doesn't
really support. So if anything, the memory usage was much worse on ServletExec.
The hardware on the new server is better, but comparable (2GB RAM in both situations).
>> Please reply directly to me (and cc the list) as I receive only the digest
>> version.
> Use the archives ;) I like the ones at AIMS.
I'd love to just use the archives, but then I would never actually read the list.
I'm not proactive enough to think of reading the list on a regular basis, so it's
better when it fills up my email box every day and I'm forced to look through it. :-)
Regards,
Roman
