我正在尝试从 C 中的同一上下文创建具有 inproc:// 传输类的套接字。
我可以创建 2036 个套接字，当我尝试创建更多 zmq_socket() 返回 NULL 并且 zmq_errno 表示 24 'Too many open files'。
如何创建超过 2036 个套接字？尤其是inproc 强迫我只使用一个上下文。
有几件事我不明白：
- 套接字最终转向inproc，为什么会占用文件？
- 增加 ZMQ_MAX_SOCKETS 没有帮助，系统文件限制似乎是限制因素
- 我无法在我的 Mac 上使用 ulimit 增加文件限制，没有解决方法有帮助。
// 代码实际上是在 cython 中，可以在这里找到：
【问题讨论】：
标签： zeromq
使用zmq_ctx_set()：
zmq_ctx_set (context, ZMQ_MAX_SOCKETS, 256);
【讨论】：
您可以使用 sysctl 更改这些（在 Yosemite 和 El Capitan 上尝试过），但问题是要更改什么。这是关于此主题的帖子：Increasing the maximum number of tcp/ip connections in linux
这是在 Linux 上的，Mac 基于 BSD 4.x，但 BSD 上的 sysctl 的手册页可在线获得。
注意：sysctl是iOS上的私有接口。
【讨论】：
inproc 不会强迫您拥有一个通用的 Context() 实例，但拥有一个很方便，因为信令/消息传递无需任何数据传输，只需零-对内存中的内存块进行复制、指针操作，速度非常快。
我开始收集 ZeroMQ 相关的事实，即在 O/S 内核设置的支持下，有大约 70.000 ~ 200.000 个可用于“套接字”的文件描述符，但您发布的目标更高。 更高。
鉴于您在 git 上发布的 Multi-agent ABCE 项目论文指的是纳秒剃须，HPC 域级解决方案具有（添加引用/强调：）
庞大的1.073.545.225 的数量，比即使是最复杂的超级计算机的内存还要多的代理，一些小的数十万个文件描述符并不值得花时间花时间。
您的项目同时面临多个麻烦。
让我们一步一步地剥离问题层：
查看实际的原样状态：
编辑/etc/sysctl.conf文件
# vi /etc/sysctl.conf
如下添加配置指令：
fs.file-max = 100000
保存并关闭文件。
用户需要注销并重新登录才能使更改生效或只需键入以下命令：
# sysctl -p
使用命令验证您的设置：
# cat /proc/sys/fs/file-max
每个用户还有一组( 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 附近的任何地方增长。
但仍然应该重新定义多代理项目应用程序架构，以免在极端资源分配上失败（只是因为语法简单）。
专业的多代理模拟器是正确的，因为在每个代理实例资源锁定方面非常、非常保守的极端扩展。
因此，当使用直接内存映射操作时，可以预期最好的结果（性能方面和延迟方面）。 ZeroMQ inproc:// 传输类很好，不需要 Context() 实例来分配 IO 线程（因为根本没有数据泵，如果只使用 inproc:// 传输类)，这对于快速原型设计阶段非常有效。如果将规模扩大到生产中的预期水平，同样的方法将变得有风险。
延迟削减和加速时间模拟器操作吞吐量扩展是下一组目标，用于提高基于多代理的模拟静态扩展并提高模拟器性能。
要么预先分配（作为 RTOS 域中的常见最佳实践）并且根本不分配，要么遵循John's fabulous testing-supported insights presented on ACCU 2017.
【讨论】：