GNU / Linux conta processi e thread insieme quando ne limito il numero?


11

Voglio limitare il numero di processi per utente sulla mia macchina, con /etc/security/limits.confe il valore nproc.

Ho letto qui che Linux non dovrebbe distinguere tra processi e thread?

Il mio attuale limite nproc per utente è 1024, ma se questo include anche i thread, è troppo basso dal mio punto di vista. La pagina di limits.confmanuale menziona solo "processo" per nproc e nient'altro.

// modifica // codice di esempio in C ++ con 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 (rimosso alcune righe):

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

Il mio laptop utilizza ~ 130 processi mentre è inattivo. Quindi nproc , o Linux in una visione più ampia, non distingue tra processi e thread. Il che mi sembra ragionevole, perché i thread potrebbero anche esaurire, non solo i processi.

Risposte:


14

Il nproclimite di cui stai parlando si applica alle entità eseguibili , quindi limita i thread (e quindi i processi che li contengono) . Ogni processo ha almeno un thread (il thread primario), in modo che solo i thread possano essere eseguiti . A rigor di termini, i processi non sono "eseguibili".

Questa risposta spiega la vera differenza tra thread e processi in Linux.

Ho testato il codice nella risposta di daya (aggiunta anche sleep(1);nel codice thread) e, diversamente da lui (?!), Ho raggiunto il limite quando sono stati creati troppi thread: pthread_create()stava tornando EAGAIN. La pthread_create(3)documentazione dice quanto segue su questo errore:

EAGAIN

Risorse insufficienti per creare un altro thread o è stato riscontrato un limite imposto dal sistema sul numero di thread. Quest'ultimo caso può verificarsi in due modi: è stato raggiunto il limite di risorse software RLIMIT_NPROC (impostato tramite setrlimit (2)), che limita il numero di processi per un ID utente reale; oppure è stato raggiunto il limite a livello di sistema del kernel sul numero di thread, / proc / sys / kernel / thread-max.

Non vedo alcuna menzione di un limite per-thread specifico nel sorgente del kernel , vedo solo RLIMIT_NPROClì, che è il limite in cui puoi cambiare limits.conf(con nproc), ulimit -uo setrlimit(2).


0

ulimit limita solo il numero di processi. Pertanto un valore impostato utilizzando

ulimit -u 1024

limiterà il numero di procesi.

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

imposta ulimit e controlla

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$ 

il limite di processo è impostato su 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$ 

qui è possibile creare 50 thread.


3
A prima vista, il codice e la logica sembrano corretti, ma temo che il codice e la logica siano sbagliati. I tuoi thread tornano immediatamente, con uno sleep (5) o qualcos'altro che richiede in test () il tuo codice dovrebbe fallire.
Peter Weber,

Bene, ho aggiunto un po '(1) {} in test () e ancora ottengo lo stesso risultato di cui sopra.
daya,

Ho modificato la mia richiesta. Potresti anche provare il mio codice. La tua prima risposta "Sì, i sistemi Linux contano i thread e i processi POSIX insieme" sembra perfettamente corretto.
Peter Weber,

Sì, è quello che ho pensato fino a quando non l'ho provato in un programma.
daya,

2
Non sono d'accordo con la tua conclusione . Quando ho provato il tuo programma, ho raggiunto il limite quando sono stati creati troppi thread. Il limite di Linux si applica ai thread. Vedere la mia risposta .
Totor
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.