Чи підраховує 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.

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

EAGAIN

Було виявлено недостатньо ресурсів для створення іншого потоку або встановлене системою обмеження кількості потоків. Останній випадок може відбуватися двома способами: досягнуто обмеженого обмеження ресурсів RLIMIT_NPROC (встановленого через setrlimit (2)), що обмежує кількість процесу для реального ідентифікатора користувача; або досягнуто загальносистемного обмеження на кількість потоків / proc / sys / kernel / thread-max.

Я не бачу жодної згадки про певний межу для потоку у джерелі ядра , я бачу лише RLIMIT_NPROCтам, який обмеження можна змінити в limits.confnproc) ulimit -uабо setrlimit(2).


0

обмежити обмеження лише кількості процесів. Тому значення, встановлене з використанням

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
На перший погляд ваш код та обгрунтування виглядають правильно, але я боюся, що ваш код та обгрунтування неправильні. Ваші потоки повертаються негайно, під час сну (5) або чогось іншого, що вимагає тесту (), ваш код повинен вийти з ладу.
Пітер Вебер

Що ж, я додавав деякий час (1) {} у тест (), і все одно я отримую той же результат, що і вище.
день

Я відредагував свій запит. Ви можете також протестувати мій код. Ваша перша відповідь "Так, система Linux підраховує потоки POSIX та обробляє разом" виглядає цілком правильною.
Пітер Вебер

Так, я думав, поки не спробував це в програмі.
день

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