> We think we might have cracked the underlying problem > though, and it might be similar to the 'behind the scenes > swap thing' (sadly I suspect that such things might actually > be happening -- plus I thought that memory overcommit wasn't > possible with Xen - only with VMware - but I guess they > could have done all kinds of things with Xen by now over > there.)
I didn't think Xen supported that until very recently either. I was just speculating that perhaps something like that was happening (it would certainly make sense from a business perspective to try to leverage the ability to over-commit from Amazon's perspective). At the same time I would expect such practices to very easily have very negative effects so I would be a bit surprised if they did this. Are you running an old JVM by any chance? (Just grasping for straws.) > There's a spinlock problem that's been identified elsewhere > where the JVM mis-detects the number of cores it has > running - based on the underlying architecture - and so Hmm. I can see useless spinning decreasing efficiency, but the numbers from your log are really extreme. Do you have a URL / bug id or anything that one can read up on about this? -- / Peter Schuller