Czy GNU / Linux zlicza procesy i wątki razem, gdy ograniczam ich liczbę?

11

Chcę ograniczyć liczbę procesów na użytkownika na moim komputerze za pomocą /etc/security/limits.confi wartości nproc.

Czytałem tutaj, że Linux nie rozróżnia procesów i wątków?

Mój aktualny limit nproc na użytkownika wynosi 1024, ale jeśli obejmuje to również wątki, moim zdaniem jest zbyt niski. Strona limits.confpodręcznika tylko wspomina o „procesie” dla nproc i nic więcej.

// edytuj // przykładowy kod w C ++ z 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;
}

test (usunięto niektóre wiersze):

$ 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ój laptop korzysta z ~ 130 procesów w stanie bezczynności. Tak więc nproc , lub Linux w szerszym ujęciu, nie rozróżnia procesów i wątków. Wydaje mi się to rozsądne, ponieważ wątki mogą również wyczerpać, nie tylko procesy.

Peter Weber
źródło

Odpowiedzi:

14

nprocGranica mówisz dotyczy podmiotów przypisanymi , jest zatem ograniczenie wątki (a więc procesy zawierających je) . Każdy proces ma co najmniej jeden wątek (wątek główny), więc można uruchamiać tylko wątki . Ściśle mówiąc, procesów nie można „uruchomić”.

Ta odpowiedź wyjaśnia prawdziwą różnicę między wątkami i procesami w systemie Linux.

Przetestowałem kod w odpowiedzi dayi (również dodanej sleep(1);w kodzie wątku) i w przeciwieństwie do niego (?!) Osiągnąłem limit, gdy utworzono zbyt wiele wątków: pthread_create()wracał EAGAIN. pthread_create(3)Dokumentacja mówi o tym następujące błędy:

EAGAIN

Wystąpiły niewystarczające zasoby do utworzenia kolejnego wątku lub narzucono systemowe ograniczenie liczby wątków. Ten drugi przypadek może wystąpić na dwa sposoby: Osiągnięto limit zasobów miękkich RLIMIT_NPROC (ustawiony przez setrlimit (2)), który ogranicza liczbę procesów dla rzeczywistego identyfikatora użytkownika; lub osiągnięto ogólnosystemowe ograniczenie liczby wątków jądra / proc / sys / kernel / Thread-max.

Nie widzę wzmianki o konkretnym limicie na wątek w źródle jądra , widzę tylko RLIMIT_NPROCtam, który jest limitem, w którym możesz zmienić limits.conf(za pomocą nproc) ulimit -ulub setrlimit(2).

Totor
źródło
0

ulimit ogranicza tylko liczbę procesów. Dlatego wartość ustawia się za pomocą

ulimit -u 1024

ograniczy liczbę procesów.

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

ustaw ulimit i sprawdź

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$ 

limit procesu jest ustawiony na 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$ 

tutaj można utworzyć 50 wątków.

daya
źródło
3
Na pierwszy rzut oka twój kod i uzasadnienie wygląda dobrze, ale obawiam się, że twój kod i uzasadnienie są błędne. Twoje wątki wracają natychmiast, ze snem (5) lub czymś innym wymagającym czasu w teście () twój kod powinien zawieść.
Peter Weber,
Cóż, dodałem chwilę (1) {} w teście () i nadal otrzymuję taki sam wynik jak powyżej.
daya
Zredagowałem moją prośbę. Możesz także przetestować mój kod. Twoja pierwsza odpowiedź „Tak, systemy linuksowe liczą wątki i procesy POSIX razem” wygląda idealnie poprawnie.
Peter Weber,
Tak właśnie myślałem, dopóki nie wypróbowałem tego w programie.
daya
2
Nie zgadzam się z twoim wnioskiem . Kiedy wypróbowałem twój program, osiągnąłem limit, gdy utworzono zbyt wiele wątków. Limit Linux ma zastosowanie do gwintów. Zobacz moją odpowiedź .
Totor 16.04.13