在 ZMQ 中创建多个套接字 - 文件过多错误

Posted 2023-04-14

【中文标题】在 ZMQ 中创建多个套接字 - 文件过多错误

【英文标题】：Creating many Sockets in ZMQ - too many files error

【发布时间】：2017-10-31 01:51:29

【问题描述】：

我正在尝试从 C 中的同一上下文创建具有 inproc:// 传输类的套接字。

我可以创建 2036 个套接字，当我尝试创建更多 zmq_socket() 返回 NULL 并且 zmq_errno 表示 24 'Too many open files'。

如何创建超过 2036 个套接字？尤其是inproc 强迫我只使用一个上下文。

有几件事我不明白： - 套接字最终转向inproc，为什么会占用文件？ - 增加 ZMQ_MAX_SOCKETS 没有帮助，系统文件限制似乎是限制因素 - 我无法在我的 Mac 上使用 ulimit 增加文件限制，没有解决方法有帮助。

// 代码实际上是在 cython 中，可以在这里找到：

https://github.com/DavoudTaghawiNejad/ABsinthCE

【参考方案1】：

使用zmq_ctx_set()：

zmq_ctx_set (context, ZMQ_MAX_SOCKETS, 256);

【参考方案2】：

您可以使用 sysctl 更改这些（在 Yosemite 和 El Capitan 上尝试过），但问题是要更改什么。这是关于此主题的帖子：Increasing the maximum number of tcp/ip connections in linux

这是在 Linux 上的，Mac 基于 BSD 4.x，但 BSD 上的 sysctl 的手册页可在线获得。

注意：sysctl是ios上的私有接口。

【参考方案3】：

解决方案很复杂：

inproc 不会强迫您拥有一个通用的 Context() 实例，但拥有一个很方便，因为信令/消息传递无需任何数据传输，只需零-对内存中的内存块进行复制、指针操作，速度非常快。

我开始收集 ZeroMQ 相关的事实，即在 O/S 内核设置的支持下，有大约 70.000 ~ 200.000 个可用于“套接字”的文件描述符，但您发布的目标更高。 更高。

鉴于您在 git 上发布的 Multi-agent ABCE 项目论文指的是纳秒剃须，HPC 域级解决方案具有（添加引用/强调：）

庞大的1.073.545.225 的数量，比即使是最复杂的超级计算机的内存还要多的代理，一些小的数十万个文件描述符并不值得花时间花时间。

您的项目同时面临多个麻烦。

让我们一步一步地剥离问题层：

---

文件描述符 (FD) -- Linux O/S 级别 -- 系统范围的限制：

查看实际的原样状态：

编辑/etc/sysctl.conf文件

# vi /etc/sysctl.conf

如下添加配置指令：

fs.file-max = 100000

保存并关闭文件。

用户需要注销并重新登录才能使更改生效或只需键入以下命令：

# sysctl -p

使用命令验证您的设置：

# cat /proc/sys/fs/file-max

---

( Max ) 用户特定文件描述符 (FD) 限制：

每个用户还有一组( soft-limit, hard-limit )：

# su - ABsinthCE
$ ulimit -Hn
$ ulimit -Sn

但是，您可以通过编辑 /etc/security/limits.conf 文件将您的 ABsinthCE 用户（或任何其他用户）限制为任何特定限制，输入：

# vi /etc/security/limits.conf

您在哪里设置 ABsinthCE 用户根据需要分别设置软限制和硬限制：

ABsinthCE soft nofile 123456
ABsinthCE hard nofile 234567

所有这些都不是免费的——每个文件描述符都会占用一些内核内存，所以在某些时候你可能会耗尽它。几十万个文件描述符对于使用基于事件（Linux 上的 epoll）服务器架构的服务器部署来说不是问题。 但是直接忘记尝试在上述 1.073.545.225 附近的任何地方增长。

---

今天，可以拥有一台私有 HPC 机器（不是云幻象），内存约为 50-500 TB。

但仍然应该重新定义多代理项目应用程序架构，以免在极端资源分配上失败（只是因为语法简单）。

专业的多代理模拟器是正确的，因为在每个代理实例资源锁定方面非常、非常保守的极端扩展。

因此，当使用直接内存映射操作时，可以预期最好的结果（性能方面和延迟方面）。 ZeroMQ inproc:// 传输类很好，不需要 Context() 实例来分配 IO 线程（因为根本没有数据泵，如果只使用 inproc:// 传输类)，这对于快速原型设计阶段非常有效。如果将规模扩大到生产中的预期水平，同样的方法将变得有风险。

延迟削减和加速时间模拟器操作吞吐量扩展是下一组目标，用于提高基于多代理的模拟静态扩展并提高模拟器性能。

---

认真的纳秒狩猎关注杰出的 Bloomberg 大师 John Lakos 对 HPC 的见解。

要么预先分配（作为 RTOS 域中的常见最佳实践）并且根本不分配，要么遵循John's fabulous testing-supported insights presented on ACCU 2017.

【讨论】：

如果您还没有收到回复，请再次给我发电子邮件。将 *** 放入主题行。谢谢达乌德@user3666197