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

Attachment: pgpLzvZKftcq3.pgp
Description: PGP signature

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users