ZeroMQ/Python - CPU亲和力hickup？

Question

我有以下奇怪的情况.

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

使用1个Worker,系统能够处理~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 数据上浪费大量时间。

运行工人

taskset -c 1 python worker.py

解决了问题。