¿GNU / Linux cuenta procesos y subprocesos juntos cuando limito su número?


11

Quiero limitar el número de procesos por usuario en mi máquina, con /etc/security/limits.confy el valor nproc.

¿He leído aquí que Linux no distingue entre procesos y subprocesos?

Mi límite actual de nproc por usuario es 1024, pero si esto incluye también hilos, en mi punto de vista es demasiado bajo. La página de manual de limits.confsolo menciona "proceso" para nproc y nada más.

// editar // código de muestra en 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;
}

prueba (eliminó algunas líneas):

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

Mi computadora portátil utiliza ~ 130 procesos mientras está inactiva. Entonces , nproc , o Linux en una vista más amplia, no se distingue entre procesos y subprocesos. Lo que me parece razonable, porque los hilos también podrían agotar, no solo los procesos.

Respuestas:


14

El nproclímite del que habla se aplica a las entidades ejecutables , por lo tanto, limita los hilos (y, por lo tanto, los procesos que los contienen) . Cada proceso tiene al menos un subproceso (el subproceso principal), por lo que solo se pueden ejecutar subprocesos . Estrictamente hablando, los procesos no son "ejecutables".

Esta respuesta explica la diferencia real entre hilos y procesos en Linux.

Probé el código en la respuesta de daya (también agregado sleep(1);en el código del hilo) y, a diferencia de él (?!), Llegué al límite cuando se crearon demasiados hilos: pthread_create()estaba regresando EAGAIN. La pthread_create(3)documentación dice lo siguiente sobre este error:

EAGAIN

Se encontraron recursos insuficientes para crear otro subproceso o un límite impuesto por el sistema en el número de subprocesos. El último caso puede ocurrir de dos maneras: se alcanzó el límite de recursos blandos RLIMIT_NPROC (establecido a través de setrlimit (2)), que limita el número de procesos para una ID de usuario real; o se alcanzó el límite de todo el sistema del núcleo en el número de subprocesos, / proc / sys / kernel / threads-max.

No veo ninguna mención de un límite específico por subproceso en la fuente del núcleo , solo veo RLIMIT_NPROCallí, que es el límite que puede cambiar en limits.conf(con nproc), ulimit -uo setrlimit(2).


0

ulimit limita solo el número de procesos. Por lo tanto, un valor establecido usando

ulimit -u 1024

limitará el número de procesos.

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

establecer ulimit y verificar

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$ 

el límite del proceso se establece en 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$ 

Aquí se pueden crear 50 hilos.


3
A primera vista, su código y justificación parecen correctos, pero me temo que su código y justificación están equivocados. Sus subprocesos regresan inmediatamente, con un sueño (5) o algo más de tiempo que requiere en la prueba (), su código debería fallar.
Peter Weber

Bueno, agregué un rato (1) {} en test () y aún así obtengo el mismo resultado que el anterior.
daya

He editado mi solicitud. Podrías probar mi código, también. Su primera respuesta "Sí, Linux Systems cuenta los hilos y procesos POSIX juntos" parece perfectamente correcta.
Peter Weber

Sí, eso es lo que pensé hasta que lo probé en un programa.
daya

2
No estoy de acuerdo con tu conclusión . Cuando probé su programa, llegué al límite cuando se crearon demasiados hilos. El límite de Linux no se aplica a las roscas. Mira mi respuesta .
Totor
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.