¿Cuál es el número máximo de hilos que puede crear un proceso en Linux?
¿Cómo (si es posible) se puede modificar este valor?
¿Cuál es el número máximo de hilos que puede crear un proceso en Linux?
¿Cómo (si es posible) se puede modificar este valor?
Respuestas:
Linux no tiene un subproceso separado por límite de proceso, solo un límite en el número total de procesos en el sistema (los subprocesos son esencialmente solo procesos con un espacio de direcciones compartido en Linux) que puede ver así:
cat /proc/sys/kernel/threads-max
El valor predeterminado es el número de páginas de memoria / 4. Puede aumentar esto como:
echo 100000 > /proc/sys/kernel/threads-max
También hay un límite en el número de procesos (y, por lo tanto, subprocesos) que puede crear un solo usuario; consulte los ulimit/getrlimitdetalles sobre estos límites.
E667: Fsync failedcuando intento guardar en vi.
Esto es INCREÍBLE al decir que LINUX no tiene hilos separados por límite de proceso.
¡Linux implementa un número máximo de hilos por proceso indirectamente!
number of threads = total virtual memory / (stack size*1024*1024)
Por lo tanto, el número de subprocesos por proceso puede aumentarse aumentando la memoria virtual total o disminuyendo el tamaño de la pila. Pero, disminuir demasiado el tamaño de la pila puede conducir a la falla del código debido al desbordamiento de la pila, mientras que la memoria virtual máxima es igual a la memoria de intercambio.
Comprueba tu máquina:
Memoria virtual total: ulimit -v(el valor predeterminado es ilimitado, por lo tanto, debe aumentar la memoria de intercambio para aumentar esto)
Tamaño total de la pila: ulimit -s(el valor predeterminado es 8Mb)
Comando para aumentar estos valores:
ulimit -s newvalue
ulimit -v newvalue
* Reemplace el nuevo valor con el valor que desea poner como límite.
Referencias
http://dustycodes.wordpress.com/2012/02/09/increasing-number-of-threads-per-process/
ulimit -s. Es muy posible (no sensible, pero posible) crear tantos subprocesos como posibles ID de subproceso. Bajo Linux de 64 bits, es incluso "posible" crear fácilmente más hilos que ID de hilos (por supuesto, no es posible, pero en lo que respecta a la pila, sí lo es). 3. Stack reserve, commit y VM son cosas diferentes, especialmente con OC.
En términos prácticos, el límite generalmente está determinado por el espacio de pila. Si cada subproceso obtiene una pila de 1 MB (no recuerdo si ese es el valor predeterminado en Linux), entonces un sistema de 32 bits se quedará sin espacio de direcciones después de 3000 subprocesos (suponiendo que el último gb esté reservado para el núcleo) .
Sin embargo, lo más probable es que experimente un rendimiento terrible si usa más de unas pocas docenas de hilos. Tarde o temprano, obtienes demasiada sobrecarga de cambio de contexto, demasiada sobrecarga en el planificador, etc. (Crear una gran cantidad de subprocesos hace poco más que consumir mucha memoria. Pero muchos subprocesos con un trabajo real que hacer va a ralentizarlo mientras luchan por el tiempo de CPU disponible)
¿Qué haces donde este límite es relevante?
hilos 100k adecuados en Linux:
ulimit -s 256
ulimit -i 120000
echo 120000 > /proc/sys/kernel/threads-max
echo 600000 > /proc/sys/vm/max_map_count
echo 200000 > /proc/sys/kernel/pid_max
./100k-pthread-create-app
Actualización 2018 de @Thomas, en sistemas systemd:
/etc/systemd/logind.conf: UserTasksMax=100000
@dragosrsupercool
Linux no usa la memoria virtual para calcular el máximo de subprocesos, sino la memoria ram física instalada en el sistema
max_threads = totalram_pages / (8 * 8192 / 4096);
http://kavassalis.com/2011/03/linux-and-the-maximum-number-of-processes-threads/
kernel / fork.c
/* The default maximum number of threads is set to a safe
* value: the thread structures can take up at most half
* of memory.
*/
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
Entonces, thread Max es diferente entre cada sistema, porque la memoria RAM instalada puede ser de diferentes tamaños, sé que Linux no necesita aumentar la memoria virtual, porque en 32 bits obtuvimos 3 GB de espacio de usuario y 1 GB para el núcleo, en 64 bits tenemos 128 TB de memoria virtual, eso sucede en Solaris, si desea aumentar la memoria virtual necesita agregar espacio de intercambio.
Para recuperarlo:
cat /proc/sys/kernel/threads-max
Para configurarlo:
echo 123456789 > /proc/sys/kernel/threads-max
123456789 = # de hilos
>) parte pierde el sudo: tryecho 12345678 | sudo tee -a /proc/sys/kernel/threads-max
Límite de conteo de hilos:
$ cat /proc/sys/kernel/threads-max
Cómo se calcula:
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
y: el tamaño de página x86_64 (PAGE_SIZE) es 4K; Como todas las demás arquitecturas, x86_64 tiene una pila de kernel para cada hilo activo. Estas pilas de hilos son THREAD_SIZE (2 * PAGE_SIZE) grandes;
para mempages:
cat /proc/zoneinfo | grep spanned | awk '{totalpages=totalpages+$2} END {print totalpages}';
así que en realidad el número no está relacionado con la limitación del tamaño de la pila de memoria de hilo ( ulimit -s).
PD: la limitación de la pila de memoria de subprocesos es de 10 M en mi máquina virtual rhel, y para la memoria de 1.5G, ¿esta VM solo puede permitirse 150 subprocesos?
Para cualquiera que esté viendo esto ahora, en los sistemas systemd (en mi caso, específicamente Ubuntu 16.04) hay otro límite impuesto por el parámetro cgroup pids.max.
Esto se establece en 12,288 por defecto, y se puede anular en /etc/systemd/logind.conf
Todavía se aplican otros consejos, incluidos pids_max, threads-max, max_maps_count, ulimits, etc.
compruebe el tamaño de la pila por hilo con ulimit, en mi caso Redhat Linux 2.6:
ulimit -a
...
stack size (kbytes, -s) 10240
Cada uno de sus hilos obtendrá esta cantidad de memoria (10 MB) asignada para su pila. Con un programa de 32 bits y un espacio de direcciones máximo de 4 GB, ¡eso es un máximo de solo 4096 MB / 10 MB = 409 hilos! Código de programa menos, menos espacio de montón probablemente conducirá a un máximo observado. de 300 hilos.
Debería poder plantear esto compilando y ejecutando en 64 bits o configurando ulimit -s 8192 o incluso ulimit -s 4096. Pero si esto es aconsejable es otra discusión ...
Probablemente no debería importar. Obtendrá un rendimiento mucho mejor al diseñar su algoritmo para usar un número fijo de subprocesos (por ejemplo, 4 u 8 si tiene 4 u 8 procesadores). Puede hacer esto con colas de trabajo, E / S asíncronas o algo así como liberador.
Depende de su sistema, simplemente escriba un programa de muestra [creando procesos en un ciclo] y verifique usando ps axo pid, ppid, rss, vsz, nlwp, cmd. Cuando ya no pueda crear hilos, verifique nlwp count [nlwp es el número de hilos] voila, obtuvo su respuesta a prueba de tontos en lugar de pasar por libros
Para establecer permanentemente,
vim /etc/sysctl.conf
y añadir
kernel.threads-max = "value"
Podemos ver el número máximo de hilos definidos en el siguiente archivo en Linux
cat / proc / sys / kernel / threads-max
(O)
sysctl -a | grep threads-max
Puede ver el valor actual con el siguiente comando: cat / proc / sys / kernel / threads-max
También puede establecer el valor como
echo 100500> / proc / sys / kernel / threads-max
El valor que establezca se verificará con las páginas RAM disponibles. Si las estructuras de hilos ocupan más de 1/8) de las páginas RAM disponibles, thread-max se reduciría en consecuencia.
Sí, para aumentar el número de subprocesos necesita aumentar la memoria virtual o disminuir el tamaño de la pila. En Raspberry Pi no encontré una manera de aumentar la memoria virtual, si disminuye el tamaño de la pila de 8MB a 1MB por defecto Es posible obtener más de 1000 hilos por proceso, pero disminuya el tamaño de la pila con el comando "ulimit -s" hacer esto para todos los hilos. Entonces, mi solución fue usar la instancia "pthread_t" instancia "clase de hilo" porque pthread_t me permitió establecer el tamaño de la pila por cada hilo. Finalmente, estoy disponible para archivar más de 1000 hilos por proceso en Raspberry Pi, cada uno con 1 MB de pila.