On 22 Feb 2015 at 19:43:08, Aaron Hardy at AC
Thanks for the follow-up.
I never managed to track down the exact cause of the futex lock or
gettimeofday calls. My best guess is that it has something to do with XWiki
running on an Amazon EC2 instance. I didn't see the same kind of issues on a
local machine. I had another thread a few months ago where I asked if anyone
had successfully run XWiki on AWS, and it didn't seem like there was much
experience with that setup.
My short term solution was just to double the RAM and throw it all at XWiki.
That seems to have mostly dealt with the stability issues (at least, the
instance rarely crashes under load), but under the hood I think it's still
performing much worse than it should be.
Any ideas you have about what might be causing the issue, or any tips for
running XWiki on Amazon under reasonably high loads would be much
Thanks for the information and indeed you could be right about the Amazon EC2
context for the futex problem.
I don’t have any experience with running XWiki on Amazon EC2 so I cannot help
On Fri, Feb 20, 2015 at 10:05 AM,
Sorry you didn’t get any answer…
Were you able to find out the problem and improve XWiki under load?
On 20 Sep 2014 at 06:52:10, Aaron Hardy at AC
Trying to track down the source of some persistent performance issues
load with 6.2 RC 1 (haven't had time to upgrade to 6.2 final yet). I'm
maxing out at about 30 or so users before dying on a system with 4GB of
The java interpreter is getting pegged to 100% of the CPU, and about 70%
the calls in the stack trace are futex lock errors. A good chunk of the
remainder are gettimeofday calls.
Potentially useful info (sorry for formatting):
% time seconds usecs/call calls errors syscall
-- --- --- - -
72.75 5361.592109 45075 118947 14045 futex
12.28 905.064191 466 1943354 gettimeofday
4.83 356.110745 3709487 96 45 restart_syscall
2.88 212.173358 836 253729 clock_gettime
2.71 199.867690 8802 22706 recvfrom
2.10 154.843342 37841 4092 poll
1.14 84.282371 580 145307 130153 stat
users mailing list