Hallvard B Furuseth wrote:
Howard Chu writes:
I guess so. We can try to minimize that by assigning jobs to the shortest queues. On a lightly loaded server, there will probably be at least one empty queue, so jobs will always be dispatched quickly.
Great...
On a heavily loaded server, all jobs are going to experience longer delays anyway, so I don't think the worst case can deviate very far from the average case.
It can if one uses one slow and one fast backend.
True. Well as Rick suggested, we don't have to go to the extreme of one queue per thread, we can go part way and use one queue per N threads.
Or with operations like adding a member to a 20000-member posixGroup. I just did that, it took 0.7 seconds with back-bdb.
Did you try that with sorted values?
In the mean time, slapd sent 350 other results (not counting search result entries) and accepted 65 connections. Mostly for operations against another database. I don't know how similar the relative times would be on a heavily loaded server though.
We could identify slow operations and avoid them. Just stamp each op with a counter when it gets queued. On each pass thru the queues looking for the shortest queue, we can also notice if the active op's stamp is too old. E.g., with 16 threads running an equal distribution of jobs, all the active ops' stamps should be within a span of 16. Any stamp outside that range indicates an op that has run for longer than the average time.
BTW, is the problem that each operation locks pool->ltp_mutex 2-3 times, or is it the amount of time it is kept locked? Most tests which pool_<submit/wrapper>() do with ltp_mutex locked, could be precomputed.
Both I think. I haven't set up Dtrace on the T5120 yet to get better info, but oprofile on Linux shows that pthread_mutex_lock is taking too much CPU time (vying with the ethernet driver for #1 consumer). And realistically, a single shared resource like this is just a really bad idea.