On Tue, 2007-08-21 at 22:18 +0100, Andrew Stitcher wrote: > Unless you have another application for the Serializer, I wouldn't spend > the time as I'm planning to take it wholesale out of the critical write > path anyway.
Excellent. I'll spend no more time on it. It was a hack from the beginning. You were wondering about what data structure was growing so big? Guess what: it's the Serializer again. The problem is not the serializer per-se, its a fairness problem. We have an active enqueue and dequeue clients running at approx the same speed (I assume - maybe worth checking) so in principal the broker should never be holding very many messages in queue. However it looks like the enqueue threads are getting way too much CPU time before the any write threads get a chance to drain the queues. Hopefully your planned threading changes will sort this out. One simple measure might be to simply reduce the unit of work a reader thread does before going back to epoll - a single frame, or some bounded number of frames. That way threads would be more frequently made available for fair distribution between competing read & write actions. I'll stay away from performance for a while to focus on clustering, have fun! Cheers, Alan.
