We have observed two issues, possibly with a common cause, with threading in qpid 0.18.
Issue 1 - Using the C++ broker on an IBM M4, performance is very poor (and CPU utilisation very high) unless the size of the thread pool is reduced by setting worker-threads to a small number. I believe the default is to create one more thread than the number of logical cores, which for this box is 24. So the question here is why having a lot of threads could increase CPU loading. I wondered if it might be that threads were being moved between cores, causing a lot of cache invalidation, but setting hard affinity indicates that this is not the case. Issue 2 - A client process in C++ on Linux RHEL 5.8 creates a number of listener threads, using the messaging interface, all listening to the same on-box broker. Each listener has its own connection, session and receiver. It is observed that each listener gets another thread created in the qpid library. The listeners are configured, and messages sent to the broker, such that some will receive data, and some will not. CPU loading for the active and dormant qpid threads increases with the number of threads. This is not the case when listeners in separate processes are used. It seems, in both cases, as if threads somehow have a dependency on each other, such that for each working thread it has to do some work relating to each other thread, and these other threads somehow get some work to do due to the first. This seems pretty weird to me, I'd be grateful if anyone could shed any light and, even better, suggest a way of avoiding this effect. -- View this message in context: http://qpid.2158936.n2.nabble.com/Potentially-related-issues-between-QPID-threads-tp7595682.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
