Linux中的线程/套接字限制 [英] Threads/Sockets limits in Linux

问题描述

首先：对不起我的英语。
我有一个麻烦与POSIX套接字和/或pthreads。我在嵌入式设备（ARM9 CPU）上开发。在设备上将工作多线程tcp服务器。它将能够处理很多传入的连接。服务器从客户端获取连接并增加计数器变量（unsigned int counter）。客户端例程将在单独的线程中运行。所有客户端将使用1个singleton类实例（在此类中将打开和关闭相同的文件）。客户端使用文件，然后客户端线程关闭连接套接字，并调用pthread_exit（）。
所以，我的tcp服务器不能处理超过250个线程（counter = 249 +1（服务器线程）。我有资源临时不可用。有什么问题？

First of all: sorry for my english. Guys, I have a trouble with POSIX sockets and/or pthreads. I'm developing on embedded device(ARM9 CPU). On the device will work multithread tcp server. And it will be able to process a lot of incoming connections. Server gets connection from client and increase counter variable(unsigned int counter). Clients routines will run in separate threads. All clients will use 1 singleton class instance(in this class will be opened and closed same files). Clients works with files, then client thread closes connection socket, and calls pthread_exit(). So, my tcp server can't handle more than 250 threads(counter = 249 +1(server thread). And I got "Resource temporary unavailable". What's the problem?

推荐答案

每当你的线程限制 - 或者提到的虚拟进程地址空间由于线程数量的运行 - 你是...做错了更多的线程不能扩展，特别是在嵌入式编程的时候，你可以在线程池中处理请求，使用 poll（2） 来处理很少的线程上的许多连接，这是漂亮的领域和库（如ACE，asio）这个模型有很好的理由

Whenever you hit the thread limit - or as mentioned run out of virtual process address space due to the number of threads - you're.... doing it wrong. More threads don't scale. Especially not when doing embedded programming. You can handle requests on a thread pool instead. Use poll(2) to handle many connections on fewer threads. This is prettty well-trod territory and libraries (like ACE, asio) have been leveraging this model for good reason

'thread-per-request'模型主要受欢迎，因为它是（感知的）简单的设计。

The 'thread-per-request' model is mainly popular because of it's (perceived) simple design.

只要在单个逻辑线程（有时称为 strand ）上保持连接，就没有什么区别。

As long as you keep connections on a single logical thread (sometimes known as a strand) there is no real difference, though.

另外，如果一个请求的处理不涉及阻塞操作，你永远不能比单个线程上轮询和处理更好：你可以使用bind的'backlog'特性/接受让内核担心您的待处理连接！ （注意：假定单核CPU，在双核CPU上，这种处理是最佳的，每个CPU有一个线程）

Also, if the handling of a request involves no blocking operations, you can never do better than polling and handling on a single thread after all: you can use the 'backlog' feature of bind/accept to let the kernel worry about pending connections for you! (Note: this assumed a single core CPU, on a dual core CPU this kind of processing would be optimal with one thread per CPU)

编辑添加Re：

ulimit显示操作系统能处理多少线程，对吧？如果是的话，ulimit不能解决我的问题，因为我的应用程序在同一时间使用〜10-15个线程。

ulimit shows how much threads can OS handle, right? If yes, ulimit does not solve my problem because my app uses ~10-15 threads in same time.

你应该仔细检查你是否正在加入或正确分离所有线程。也想到同步对象;如果你一直忘记调用相关的pthread * _destroy函数，你会遇到极限，即使不需要它。这当然是一个资源泄漏。一些工具可能能够帮助你找到它们（vlagrind / helgrind想起）

If that's the case, you should really double check that you are joining or detaching all threads properly. Also think of the synchronization objects; if you consistently forget to call the relevant pthread *_destroy functions, you'll run into the limits even without needing it. That would of course be a resource leak. Some tools may be able to help you spot them (vlagrind/helgrind come to mind)

这篇关于Linux中的线程/套接字限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！