GNU / Linux có đếm các tiến trình và luồng với nhau khi tôi giới hạn số lượng của chúng không?


11

Tôi muốn giới hạn số lượng quy trình trên mỗi người dùng trên máy của mình /etc/security/limits.confvà với giá trị nproc.

Tôi đã đọc ở đây rằng Linux không phân biệt giữa các tiến trình và luồng?

Giới hạn nproc hiện tại của tôi cho mỗi người dùng là 1024, nhưng nếu điều này bao gồm cả các luồng, thì theo quan điểm của tôi là quá thấp. Trang con người limits.confchỉ đề cập đến "quy trình" cho nproc và không có gì khác.

// chỉnh sửa // mã mẫu trong C ++ với Boost // 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;
}

kiểm tra (loại bỏ một số dòng):

$ 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)

Máy tính xách tay của tôi sử dụng ~ 130 quy trình trong khi không sử dụng. Vì vậy, nproc hoặc Linux trong một cái nhìn rộng hơn, không phân biệt giữa các quy trình và luồng. Điều này có vẻ hợp lý với tôi, bởi vì các chủ đề cũng có thể cạn kiệt, không chỉ các quá trình.

Câu trả lời:


14

Các nprocgiới hạn bạn đang nói về áp dụng đối với các đối tượng Runnable , do đó nó được giới hạn chủ đề (và do đó, quy trình chứa chúng) . Mỗi tiến trình có ít nhất một luồng (luồng chính), do đó chỉ các luồng có thể được chạy . Nói đúng ra, các quy trình không phải là "runnable".

Câu trả lời này giải thích sự khác biệt thực sự giữa các luồng và tiến trình trong Linux.

Tôi đã kiểm tra mã trong câu trả lời của daya (cũng được thêm sleep(1);vào mã chủ đề) và không giống như anh ấy (?!), Tôi đã đạt đến giới hạn khi có quá nhiều chủ đề được tạo: pthread_create()đang quay trở lại EAGAIN. Các pthread_create(3)tài liệu nói như sau về lỗi này:

EAGAIN

Không đủ tài nguyên để tạo một luồng khác hoặc giới hạn áp đặt của hệ thống đối với số lượng luồng đã gặp phải. Trường hợp thứ hai có thể xảy ra theo hai cách: đã đạt đến giới hạn tài nguyên mềm RLIMIT_NPROC (được đặt qua setrlimit (2)), giới hạn số lượng quy trình cho ID người dùng thực, đã đạt được; hoặc giới hạn toàn hệ thống của kernel về số lượng luồng, / Proc / sys / kernel / thread-max, đã đạt được.

Tôi không thấy đề cập đến giới hạn mỗi luồng cụ thể trong nguồn kernel , tôi chỉ thấy RLIMIT_NPROCở đó, đó là giới hạn bạn có thể thay đổi trong limits.conf(với nproc), ulimit -uhoặc setrlimit(2).


0

ulimit giới hạn số lượng quá trình chỉ. Do đó, một giá trị được đặt bằng cách sử dụng

ulimit -u 1024

sẽ giới hạn số lượng các thủ tục.

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;
}

đặt ulimit và kiểm tra

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$ 

giới hạn quá trình được đặt thành 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$ 

ở đây 50 chủ đề có thể được tạo ra.


3
Thoạt nhìn mã và lý do của bạn có vẻ đúng, nhưng tôi sợ mã và lý do của bạn sai. Chủ đề của bạn đang trở lại ngay lập tức, với một giấc ngủ (5) hoặc thời gian khác yêu cầu trong bài kiểm tra () mã của bạn sẽ thất bại.
Peter Weber

Vâng, tôi đã thêm một lúc (1) {} trong test () và tôi vẫn nhận được kết quả như trên.
daya

Tôi đã chỉnh sửa yêu cầu của tôi. Bạn cũng có thể kiểm tra mã của tôi. Câu trả lời đầu tiên của bạn "Có hệ thống linux đếm các luồng POSIX và các quy trình cùng nhau" trông hoàn toàn chính xác.
Peter Weber

Vâng, đó là những gì tôi nghĩ cho đến khi tôi thử nó trong một chương trình.
daya

2
Tôi không đồng ý với kết luận của bạn . Khi tôi thử chương trình của bạn, tôi đã đạt đến giới hạn khi có quá nhiều chủ đề được tạo. Giới hạn Linux không áp dụng cho các luồng. Xem câu trả lời của tôi .
Totor
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.