我可以防止 ZeroMQ 占用文件描述符吗？

Question

我有一个设置，其中一个主进程正在设置 ZMQ_ROUTER，然后分叉许多子进程，然后连接到该路由器。

每当一个子zmq_connect() 到主控时，就会占用一个文件描述符。

但是，这将交互进程的数量限制为允许的文件描述符的数量（每个进程）。对我（linux）来说，目前只有 1024。

这对于我的预期用途（多智能体/群体模拟）来说太小了。

---

回答：

您不能，除非使用线程间套接字类型（使用 inproc:// 传输类）。所有其他协议每个连接使用一个文件描述符。

如果该应用程序有多个服务（例如可以建立多个tcp://<address:port> 连接），则减少每个应用程序所需文件描述符数量的一种新方法似乎是使用资源属性resource property，它允许一种将多个服务组合到一个端点。

Answer 1

虫群优先：

首先，大量代理的智能解决方案需要灵活性（在 swarm 框架设计中用于添加功能）和效率（对于 >scalability 和 speed ) 以实现尽可能快的模拟运行时间，尽管有 PTIME 和 PSPACE 障碍物，在更复杂的代理间通信方案中可能会进入 EXPTIME 区域。

---

效率下一个：

一开始，我的猜测是宁愿使用和定制一个轻量级的基于 POSIX 的信号/消息传递框架nanomsg -- a younger sister of ZeroMQ from Martin SUSTRIK, co-father of ZeroMQ——其中一个 Context() 更少的设计加上像 SURVEY 和 BUS 消息原型这样的附加功能，对于使用您自己的软件设计的问题域特定消息/信令协议的群特别有吸引力：

---

100k+ file_descriptors

嗯，你需要勇气。可行，但要袖手旁观，这将需要在内核中进行手动操作，调整系统设置，并且您将通过增加开销来为这样的规模付出代价。

Andrew Hacking has explained both the PROS and CONS of the "just" increasing fd count ( not only on the kernel side of the system tuning and configuration ).

其他需要考虑的因素是，虽然某些软件可能使用 sysconf(OPEN_MAX) 来动态确定进程可能打开的文件数量，但许多软件仍然使用 @ 987654337@ 库的默认 FD_SETSIZE，通常是 1024 个描述符，因此无论管理上定义的上限如何，打开的文件都不会超过那么多.

Andrew has also directed your kind attention to this, that may serve as an ultimate report on how to setup a system for 100k-200k connections.

---

每台主机超过 100k 的静态规模是否对群体模拟有任何实际意义？

虽然“技术上”仍然可行，但还有更多限制——即使 nanomsg 也无法推送超过 1.000.000 [MSGs/s]，这对于大多数应用程序来说已经足够好了，但不能跟上消息发送的本机速度。引用说明了一些 ~6 [us] 用于 CPU 内核到 CPU 内核的传输延迟，如果用户设计的群处理应用程序无法在某些 3-4 [us] 下进行发送循环性能上限不会引起问题。

---

如何扩大规模？

分布式多主机处理是攻击群体静态规模的第一个维度。接下来需要引入 RDMA 注入，以便摆脱分布式消息/信令实现中任何堆栈处理的性能瓶颈。是的，这可以将您的 Swarm 系统移动到纳秒级延迟区域，但代价是构建 HPC/高科技计算基础架构（如果您的项目发起人可以调整，这将是一个很棒的项目此类项目的融资 -- + 请让我知道如果是，我会非常渴望加入这样的群体智能 HPC 实验室），但值得在决定架构之前了解这个含义并了解最终限制是从一开始就做好的关键。