2016-04-19 4:43 GMT+02:00 Rowan Worth <rowanw at dugeo.com>: > 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. >
?OK, I will take you word for it. This is new territory for me, so what looks strange to me can be completely normal. Something else I have to learn about. :-) -- Cecil Westerhof
