ZeroMQ/Python - CPU 亲和力问题？
ZeroMQ/Python - CPU affinity hickup?
我有以下奇怪的情况。
我们有一个进程，称为 Distributor，它通过 ZeroMQ/TCP 从客户端接收任务，并将它们累积在队列中。有一个 Worker 进程，它通过 ZeroMQ/IPC 与 Distributor 进行对话。 Distributor 将每个传入的任务转发给 Worker，并等待答复。一旦 Worker 回答，它就会向它发送另一个任务（如果同时收到一个任务），并 returns 向 Client 发送答案（通过单独的 ZeroMQ/TCP 连接）。如果任务未在 10 毫秒内处理，则将其从队列中删除。
1个Worker，系统可以处理~3,500 requests/sec。客户端发送 10,000 requests/sec，因此丢弃了 6,500 个请求。
但是 - 当我 运行 服务器上的一些不相关进程占用 100% CPU（繁忙的等待循环，或其他） - 然后，奇怪的是，系统突然可以处理 ~7,000 requests/sec。当进程停止时，它 returns 回到 3,500。服务器有4个核心。
当 运行 2、3 或 4 个工人（连接到同一个分销商）时会发生同样的情况，但数量略有不同。
分发服务器是用 C++ 编写的。 Worker 是用 Python 编写的，并使用 pyzmq 绑定。 worker进程是一个简单的算术进程，除Distributor外不依赖任何外部I/O
有一种理论认为，这与 ZeroMQ 在服务器空闲时在单独的 CPU 上使用线程有关，而在服务器繁忙时使用相同的 CPU 线程。如果是这种情况，我将很感激如何配置 ZeroMQ 的 thread/CPU 亲和力以使其正常工作（没有 运行 后台繁忙循环）。
是否有任何 ZeroMQ 设置可以解释/修复此问题？
编辑：
用 C++ 编写的 Worker 不会发生这种情况。
这确实是一个 CPU 亲和力问题。事实证明，在工作人员处理输入并等待下一个输入的设置中使用 ZeroMQ，如果上下文切换导致它切换到另一个进程，则会在复制 ZeroMQ 数据上浪费大量时间。
运行 工人
taskset -c 1 python worker.py
解决问题。
我有以下奇怪的情况。
我们有一个进程，称为 Distributor，它通过 ZeroMQ/TCP 从客户端接收任务，并将它们累积在队列中。有一个 Worker 进程，它通过 ZeroMQ/IPC 与 Distributor 进行对话。 Distributor 将每个传入的任务转发给 Worker，并等待答复。一旦 Worker 回答，它就会向它发送另一个任务（如果同时收到一个任务），并 returns 向 Client 发送答案（通过单独的 ZeroMQ/TCP 连接）。如果任务未在 10 毫秒内处理，则将其从队列中删除。
1个Worker，系统可以处理~3,500 requests/sec。客户端发送 10,000 requests/sec，因此丢弃了 6,500 个请求。
但是 - 当我 运行 服务器上的一些不相关进程占用 100% CPU（繁忙的等待循环，或其他） - 然后，奇怪的是，系统突然可以处理 ~7,000 requests/sec。当进程停止时，它 returns 回到 3,500。服务器有4个核心。
当 运行 2、3 或 4 个工人（连接到同一个分销商）时会发生同样的情况，但数量略有不同。
分发服务器是用 C++ 编写的。 Worker 是用 Python 编写的，并使用 pyzmq 绑定。 worker进程是一个简单的算术进程，除Distributor外不依赖任何外部I/O
有一种理论认为，这与 ZeroMQ 在服务器空闲时在单独的 CPU 上使用线程有关，而在服务器繁忙时使用相同的 CPU 线程。如果是这种情况，我将很感激如何配置 ZeroMQ 的 thread/CPU 亲和力以使其正常工作（没有 运行 后台繁忙循环）。
是否有任何 ZeroMQ 设置可以解释/修复此问题？
编辑：
用 C++ 编写的 Worker 不会发生这种情况。
这确实是一个 CPU 亲和力问题。事实证明，在工作人员处理输入并等待下一个输入的设置中使用 ZeroMQ，如果上下文切换导致它切换到另一个进程，则会在复制 ZeroMQ 数据上浪费大量时间。
运行 工人
taskset -c 1 python worker.py
解决问题。