On Sunday 04 June 2006 10:53 pm, Matthew Palmer wrote:
> That's the crazy thing -- we've been monitoring everything we can, and we
> can't find any anomalous bottlenecks. The application is naturally CPU
just a wild guess, but on a heavily multithreaded and multiprocessor system
like yours, its quite possible that a given JVM could use a non-optimal
strategy on a Xen system. I think it's important to test different JVM's,
and different 'bitness' of them (64bit vs. 32bit). Since 32bit x86 is _SO_
register-starved, and Xen interferes with the infamous TLS trick, you should
try to use a 64bit clean system. since you already stated that your software
can't run on a 64bit JVM, maybe you could get some insight by running a
benchmark with similar threading and processor requirements, on all
combinations of 32bit, 64bit, Xen and non-Xen.
in the worst case, you might find that you must delay the Xen deployment until
your software gets more 64bit-friendly. or maybe you'll find that simply
changing JVM get's you the lost performance.
--
Javier
pgpLzvZKftcq3.pgp
Description: PGP signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|