问题描述
在尽力研究实现消息队列服务器的最佳方法之后，我提出了这个问题.为什么操作系统限制进程和全局系统可以具有的打开文件描述符的数量?我当前的服务器实现使用zeromq，并为每个连接的Websocket客户端打开一个订户套接字.显然，单个进程将只能处理fds的客户端.当我研究该主题时，我发现了很多有关如何将系统限制提高到64k fds级别的信息，但是它从没有提及它如何影响系统性能以及为什么它不超过1k?我当前的方法是尝试在自己的循环中使用协程向所有客户端分发消息，以及所有客户端及其订阅渠道的映射.但是我很想听听关于文件描述符限制的可靠答案，以及它们如何影响那些尝试在具有持久连接的每个客户端级别上使用它们的应用程序?
I ask this question after trying my best to research the best way to implement a message queue server. Why do operating systems put limits on the number of open file descriptors a process and the global system can have?My current server implementation uses zeromq, and opens a subscriber socket for each connected websocket client. Obviously that single process is only going to be able to handle clients to the limit of the fds.When I research the topic I find lots of info on how to raise system limits to levels as high as 64k fds but it never mentions how it affects system performance and why it is 1k and lower to start with?My current approach is to try and dispatch messaging to all clients using a coroutine in its own loop, and a map of all clients and their subscription channels. But I would just love to hear a solid answer about file descriptor limitations and how they affect applications that try to use them on a per client level with persistent connections?
推荐答案
可能是因为文件描述符值是文件描述符表的索引.因此，可能的文件描述符数量将决定表的大小.一般用户不希望文件描述符表用完一半的内存，该文件描述符表可以处理数百万不需要的文件描述符.
It may be because a file descriptor value is an index into a file descriptor table. Therefore, the number of possible file descriptors would determine the size of the table. Average users would not want half of their ram being used up by a file descriptor table that can handle millions of file descriptors that they will never need.
这篇关于为什么操作系统限制文件描述符?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！