ZeroMQ / Python - CPU亲和力hickup？

Question

我有以下奇怪的情况。

我们有一个进程，称之为Distributor，它通过ZeroMQ / TCP从Client接收任务，并将它们累积在队列中。有一个工作流程，通过ZeroMQ / IPC与分销商进行交流。分发者将每个传入的任务转发给工作者，并等待答案。一旦工作人员回答，它就会向其发送另一个任务（如果在同一时间内收到一个任务），并将答案返回给客户端（通过单独的ZeroMQ / TCP连接）。如果任务未在10毫秒内处理，则会从队列中删除。

使用1个工作人员，系统能够处理 ~3,500个请求/秒。客户端每秒发送10,000个请求，因此会丢弃6,500个请求。

但是 - 当我在服务器上运行一些不相关的进程时，它需要100％的CPU（一个繁忙的等待循环，或者其他） - 然后，奇怪的是，系统可以突然处理 ~7,000个请求/秒即可。当进程停止时，它返回到3,500。服务器有4个核心。

运行2个，3个或4个工人（连接到同一个经销商）时会出现同样的情况，但数字略有不同。

分发服务器是用C ++编写的。 Worker是用Python编写的，并使用pyzmq绑定。工作进程是一个简单的算术过程，不依赖于除分发器之外的任何外部I / O.

有一种理论认为，这与ZeroMQ在服务器空闲时使用独立CPU上的线程有关，而在忙碌时使用相同的CPU。如果是这种情况，我将不胜感激如何配置ZeroMQ的线程/ CPU亲和性，以使其正常工作（不在后台运行繁忙的循环）。

是否有任何ZeroMQ设置可以解释/修复此问题？

编辑：

使用C ++编写的Worker不会发生这种情况。

Answer 1

这确实是CPU亲和力问题。事实证明，在工作者处理输入并等待下一个输入的设置中使用ZeroMQ，如果上下文切换导致它切换到另一个进程，则复制ZeroMQ数据会浪费大量时间。

使用

运行worker

taskset -c 1 python worker.py

解决了这个问题。