当我限制进程和线程的数量时,GNU / Linux是否将它们同时计数?


11

我想用/etc/security/limits.conf和nproc值限制我的计算机上每个用户的进程数。

我在这里读到Linux不能区分进程和线程吗?

我当前的每位用户nproc限制为1024,但是如果这还包括线程,那么从我的角度来看,它太低了。的手册页limits.conf仅提及nproc的“过程” ,仅此而已。

//使用Boost //在C ++中编辑示例代码// g ++ -o boost_thread boost_thread.cpp -lboost_thread

#include <unistd.h>
#include <iostream>
#include <boost/thread.hpp>
using namespace std;

int counter;

void print_thread(int i) {
    counter++;
    cout << "thread(" << i << ") counter " << counter << "\n";
    sleep(5);
    counter--;
}

int main() {
    int i = 0;
    int max = 1000000;

    while (i < max) {
        boost::thread(print_thread, i);
        i++;
    }

    return 0;
}

测试(删除了一些行):

$ ulimit -u
1024
$ ./thread 
...
...
...
thread(828) counter 828
thread(829) counter 829
thread(830) counter 830
thread(831) counter 831
thread(832) counter 832
thread(610) counter thread(833833) counter 834

thread(834) counter 835
thread(835) counter 836
thread(836) counter 837
thread(837) counter 838
thread(838) counter 839
thread(839) counter 840
thread(840) counter 841
thread(841) counter 842
thread(842) counter 843
thread(843) counter 844
thread(844) counter 845
thread(845) counter 846
thread(846) counter 847
thread(847) counter 848
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >'
  what():  boost::thread_resource_error
Aborted (core dumped)

我的笔记本电脑闲置时使用约130个进程。因此,nproc或更广泛的Linux不会区分进程和线程。在我看来,这是合理的,因为线程不仅会耗尽进程,还会耗尽资源。

Answers:


14

nproc您正在讨论的限制适用于可运行的实体,因此它限制了线程(因此限制了包含它们的进程)。每个进程都有至少一个线程(主线程),因此只能运行线程。严格来说,进程不是“可运行的”。

这个答案解释了Linux中线程和进程之间的真正区别。

我在daya的答案中测试了代码(也添加sleep(1);在线程代码中),与他不同(?!),当创建了太多线程时,我达到了极限:pthread_create()正在返回EAGAIN。该pthread_create(3)文件说,有关此错误的情况如下:

易高

资源不足,无法创建另一个线程,或者遇到了系统施加的线程数限制。后一种情况可能以两种方式发生:达到了RLIMIT_NPROC软资源限制(通过setrlimit(2)设置),该限制限制了实际用户ID的进程数。或达到了内核在系统范围内对线程数的限制,即/ proc / sys / kernel / threads-max。

我没有在内核源代码中提到具体的每线程限制,仅在那里看到了,这是您可以在(with )或中更改的限制。RLIMIT_NPROClimits.confnproculimit -usetrlimit(2)


0

ulimit仅限制进程数。因此,使用

ulimit -u 1024

将限制处理的数量。

eg.

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

void* test(void *ptr){
   return 0;
}



int main()
{
        pthread_t thread[50];
        int i=0;

      for(i=0;i<50;i++){
      if(!pthread_create( &thread[i], NULL,test,NULL))
         printf("%d ",i);

       }


      for(i=0;i<50;i++)
       pthread_join( thread[i], NULL);
       return 0;
}

设置ulimit并检查

lab@x:/tmp$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
lab@x:/tmp$ 
lab@x:/tmp$ 
lab@x:~$ cd /home/x
lab@x:/home/x$ ./thread 
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 lab@x:/home/x$ 
lab@x:/home/x$ 
lab@x:/home/x$ ulimit -u 10
lab@x:/home/x$ 

进程限制设置为10

lab@x:/home/x$ ./thread 
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 lab@x:/home/x$ 
lab@x:/home/x$ 

在这里可以创建50个线程。


3
乍一看,您的代码和原理看起来是正确的,但恐怕您的代码和原理是错误的。您的线程将立即返回,并带有sleep(5)或test()中需要的其他时间,代码将失败。
彼得·韦伯

好吧,我确实在test()中添加了while(1){},但仍然得到与上述相同的结果。
Daya 2012年

我已经编辑了我的要求。您也可以测试我的代码。您的第一个答案“是的,Linux系统将POSIX线程和进程结合在一起”看起来非常正确。
彼得·韦伯

是的,这就是我一直想的,直到我在程序中尝试过为止。
Daya 2012年

2
我不同意你的结论。当我尝试您的程序时,创建过多线程时达到了极限。Linux限制确实适用于线程。看我的回答
Totor
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.