On 19 April 2016 at 02:01, Cecil Westerhof <cldwesterhof at gmail.com> wrote:
> 2016-04-18 4:04 GMT+02:00 Rowan Worth <rowanw at dugeo.com>: > > > On 18 April 2016 at 06:55, Cecil Westerhof <cldwesterhof at gmail.com> > wrote: > > > > > ?I put a strace on it. This was what I got: > > > Process 26455 attached with 20 threads > > > % time seconds usecs/call calls errors syscall > > > ------ ----------- ----------- --------- --------- ---------------- > > > 99.80 11245.498406 42527 264435 130887 futex > > > 0.09 10.480000 3493333 3 fsync > > > 0.08 8.886784 0 39275508 read > > > 0.02 2.552284 0 16397440 write > > > 0.00 0.367716 0 50708676 lseek > > > ------ ----------- ----------- --------- --------- ---------------- > > > 100.00 11267.833632 106646970 130895 total > > > > It's not like the futex calls are wasting CPU (in this case) - the > threads > > are idle until the kernel wakes them up. > > ?99.8 percent of the time is spend on futex. That seems a tad much. > If you have a lot of idle threads of course you'll see a lot of time spent in futex. The threads aren't *doing* anything or using resources in that time, just waiting for something to happen. I would wager at least 130,800 of those "errors" were ETIMEDOUT. It's like stracing bash and going "wow, look at how much time is spent in read() and wait() those syscalls must be really inefficient". Your syscall results are entirely unsurprising. The appearance of 20 threads in a single threaded java code is mildly surprising, but on an 8 core machine you may have 16 garbage collection threads. Then there's the main thread, and your sqlite binding may create another, so there's not too much left to account for. -Rowan
