Подсчитывает ли GNU / Linux процессы и потоки вместе, когда я ограничиваю их количество?


11

Я хочу ограничить число процессов на пользователя на моем компьютере с /etc/security/limits.confпомощью значения nproc.

Я читал здесь, что Linux не различает процессы и потоки?

Мой текущий предел nproc на пользователя составляет 1024, но если он включает в себя также потоки, он слишком низок с моей точки зрения. На странице руководства limits.confтолько упоминается «процесс» для nproc и ничего больше.

// редактировать // пример кода в C ++ с помощью 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;
}

тест (убрал несколько строк):

$ 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 в более широком смысле, не различает процессы и потоки. Что кажется мне разумным, потому что потоки могут также истощать не только процессы.

Ответы:


14

nprocПредел вы говорите применяется к работоспособным лицам , он , таким образом , ограничивая темы (и , следовательно, процессы , их содержащими) . Каждый процесс имеет по меньшей мере один поток (основной поток), так что только потоки могут работать . Строго говоря, процессы не являются «работоспособными».

Этот ответ объясняет реальную разницу между потоками и процессами в Linux.

Я проверил код в ответе Дая (также добавлен sleep(1);в код потока) и, в отличие от него (?!), Я достиг предела, когда было создано слишком много потоков: pthread_create()возвращался EAGAIN. В pthread_create(3)документации сказано следующее об этой ошибке:

EAGAIN

Недостаточно ресурсов для создания другого потока или системное ограничение на количество потоков. Последний случай может происходить двумя способами: достигнут предел мягкого ресурса RLIMIT_NPROC (установленный через setrlimit (2)), который ограничивает количество процессов для реального идентификатора пользователя; или был достигнут общесистемный лимит ядра на число потоков, / proc / sys / kernel / threads-max.

Я не вижу упоминания о конкретном ограничении на поток в исходном коде ядра , я вижу только RLIMIT_NPROCтам, который является пределом, который вы можете изменить limits.confnproc) ulimit -uили setrlimit(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 (), ваш код должен потерпеть неудачу.
Питер Вебер

Ну, я добавил while (1) {} в test () и все равно получаю тот же результат, что и выше.
Дая

Я отредактировал мой запрос. Вы также можете проверить мой код. Ваш первый ответ «Да, системы Linux подсчитывают потоки и процессы POSIX вместе» выглядит совершенно правильно.
Питер Вебер

Да, это то, что я думал, пока не попробовал это в программе.
Дая

2
Я не согласен с вашим выводом . Когда я попробовал вашу программу, я достиг предела, когда было создано слишком много потоков. Ограничение Linux действительно относится к потокам. Смотри мой ответ .
Тотор
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.