在Linux上的C中处理1024个以上的文件描述符
我正在使用epoll（边缘触发）和线程在线程网络服务器上工作，并且正在使用httperf对服务器进行基准测试。
到目前为止，它的性能确实非常好，或者几乎完全按照发送请求的速度执行。直到1024屏障为止，那里的所有内容都减慢到大约30个请求/秒。
在64位Ubuntu 9.04上运行。
我已经尝试过：
- 成功增加文件描述符的ulimit数量。只是并不能提高1024个并发连接以上的性能。
andri @ filefridge：〜/ Dropbox /学校/ Group 452 /代码/服务器$ ulimit -n
20000
我很确定这种速度减慢正在操作系统中发生，因为它是在事件发送到epoll之前发生的（是的，我也增加了epoll的限制）。
我需要基准测试程序可以减慢多少并发连接，直到它开始变慢（不影响操作系统）。
如何使程序运行超过1024个文件描述符？
这个限制可能是有原因的，但是出于基准测试的目的，我需要将其删除。
更新资料
感谢您的所有回答，但我想我已经找到了罪魁祸首。在我的程序中重新定义__FD_SETSIZE之后，所有东西开始以更快的速度移动。当然，还需要提高ulimit，但是如果没有__FD_SETSIZE，我的程序就永远不会利用它。
问题答案：
感谢您的所有回答，但我想我已经找到了罪魁祸首。在我的程序中重新定义__FD_SETSIZE之后，所有东西开始以更快的速度移动。当然，还需要提高ulimit，但是如果没有__FD_SETSIZE，我的程序就永远不会利用它。
-
处理文件描述符 尽管很不像，但是在大多操作系统中，标准输入输出流 stdin 和 stdout 虽然叫做「流」，但它们都有文件的接口。我们同样也会将它们实现成为文件。 但是不用担心，作为文件的许多功能，stdin 和 stdout 都不会支持。我们只需要为其实现最简单的读写接口。 进程打开的文件 操作系统需要为进程维护一个进程打开的文件清单。其中，一定存在的是 stdin stdout 和 std
-
问题内容： 我有一个正在Linux上运行的C ++应用程序，我正在对其进行优化。如何确定我的代码哪些区域运行缓慢？ 问题答案： 如果您的目标是使用探查器，请使用建议的探查器之一。 但是，如果您急于在主观上很慢的情况下在调试器下手动中断程序，则有一种简单的方法可以查找性能问题。 暂停几次，每次查看调用堆栈。如果有一些代码浪费了一定百分比的时间（20％或50％或其他），那么这就是您在每次采样时都将其捕
-
问题内容： 是否有使用C 读取用于Linux的INI文件等配置的标准方法？ 我正在基于Linux的手持设备上工作，并用C编写代码。 否则，我想知道其他选择。 最终更新： 我已经探索甚至使用过LibConfig。但是占用空间很大，而且我的用法太简单了。因此，为了减少占用空间，我推出了自己的实现。该实现不是太通用，实际上到目前为止已经相当耦合了。启动应用程序时，配置文件将被解析一次，并设置为一些全局变
-
问题内容： 是否可以在C中获取文件描述符（Linux）的文件名？ 问题答案： 您可以使用在其中NNN是文件描述符。这将为您提供文件打开时的名称- 但是，如果此后文件被移动或删除，它可能不再准确（尽管Linux在某些情况下可以跟踪重命名）。要进行验证，请提供给定的文件名和fd，并确保和相同。 当然，并非所有文件描述符都引用文件，对于那些文件描述符，您会看到一些奇怪的文本字符串，例如。由于所有真实文件
-
问题内容： 我想找到在Linux中为某个进程打开的所有fds。 我可以使用glib库函数吗？ 问题答案： 由于您使用的是Linux，因此（几乎可以肯定）已挂载了文件系统。这意味着最简单的方法是获取清单的内容; 其中的每个文件都以FD命名。（当然，请使用，并列出信息。） 否则获取信息会有些尴尬（例如，没有有用的POSIX API；这是一个尚未标准化的领域）。
-
问题内容： 使用posix的read（）write（）linux调用，可以确保如果我以串行方式通过一个文件描述符进行写入并通过另一个文件描述符进行读取，以使两个动作彼此互斥…读取文件描述符将始终看到写入文件描述符最后写入的内容？ 我相信是这种情况，但我想确定一下，手册页对此没有太大帮助 问题答案： 这取决于您在哪里获得了两个文件描述符。如果它们来自dup（2）调用，则它们共享文件的偏移量和状态，因