Numero massimo di thread per processo in Linux?

Qual è il numero massimo di thread che possono essere creati da un processo sotto Linux?

In che modo (se ansible) questo valore può essere modificato?

Linux non ha un thread separato per limite di processo, solo un limite sul numero totale di processi sul sistema (i thread sono essenzialmente solo processi con uno spazio di indirizzi condiviso su Linux) che puoi visualizzare in questo modo:

cat /proc/sys/kernel/threads-max 

Il valore predefinito è il numero di pagine di memoria / 4. Puoi aumentare questo come:

 echo 100000 > /proc/sys/kernel/threads-max 

C’è anche un limite al numero di processi (e quindi di thread) che un singolo utente può creare, vedere ulimit/getrlimit per i dettagli su questi limiti.

È SBAGLIATO dire che LINUX non ha un thread separato per limite di processo.

Linux implementa il numero massimo di thread per processo indirettamente !!

 number of threads = total virtual memory / (stack size*1024*1024) 

Pertanto, il numero di thread per processo può essere aumentato aumentando la memoria virtuale totale o diminuendo le dimensioni dello stack. Tuttavia, una riduzione eccessiva delle dimensioni dello stack può portare a un errore del codice a causa di un sovraccarico dello stack mentre la memoria virtuale massima è uguale alla memoria di scambio.

Controlla la tua macchina:

Memoria virtuale totale: ulimit -v (l’impostazione predefinita è illimitata, quindi è necessario aumentare la memoria di scambio per aumentarla)

Dimensione totale dello stack: ulimit -s (il valore predefinito è 8Mb)

Comando per aumentare questi valori:

 ulimit -s newvalue ulimit -v newvalue 

* Sostituisci nuovo valore con il valore che vuoi mettere come limite.

Riferimenti:

http://dustycodes.wordpress.com/2012/02/09/increasing-number-of-threads-per-process/

In termini pratici, il limite è solitamente determinato dallo spazio in pila. Se ogni thread riceve uno stack da 1MB (non riesco a ricordare se questo è l’impostazione predefinita su Linux), allora un sistema a 32 bit esaurirà lo spazio degli indirizzi dopo 3000 thread (supponendo che l’ultimo gb sia riservato al kernel) .

Tuttavia, è molto probabile che si verifichino prestazioni terribili se si utilizzano più di alcune decine di thread. Presto o tardi, si ottiene un sovraccarico di commutazione del contesto eccessivo, un sovraccarico eccessivo nello scheduler e così via. (Creare un numero elevato di thread fa poco più che consumare molta memoria, ma un sacco di thread con un lavoro reale da fare ti rallenterà mentre stanno lottando per il tempo di CPU disponibile)

Cosa stai facendo dove questo limite è anche rilevante?

filetti 100k corretti su 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 

Aggiornamento 2018 da @Thomas, su sistemi systemd:

 /etc/systemd/logind.conf: UserTasksMax=100000 

@dragosrsupercool

Linux non usa la memoria virtuale per calcolare il massimo di thread, ma la RAM fisica installata sul 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); 

Quindi thread max è diverso tra ogni sistema, perché la ram installata può essere di diverse dimensioni, so che Linux non ha bisogno di aumentare la memoria virtuale, perché su 32 bit abbiamo 3 GB per lo spazio utente e 1 GB per il kernel, su 64 bit abbiamo 128 TB di memoria virtuale, cosa che succede su Solaris, se vuoi aumentare la memoria virtuale devi aggiungere lo spazio di swap.

Per recuperarlo:

 cat /proc/sys/kernel/threads-max 

Per impostarlo:

 echo 123456789 > /proc/sys/kernel/threads-max 

123456789 = numero di thread

Limite del numero di thread: $ cat / proc / sys / kernel / threads-max

Come viene calcolato: max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE); e: la dimensione della pagina x86_64 (PAGE_SIZE) è 4K; Come tutte le altre architetture, x86_64 ha uno stack del kernel per ogni thread attivo. Questi stack di thread sono THREAD_SIZE (2 * PAGE_SIZE) grandi;

per i mempages: cat / proc / zoneinfo | grep spanning | awk ‘{totalpages = totalpages + $ 2} END {print totalpages}’;

quindi in realtà il numero non è correlato con la limitazione della dimensione dello stack di memoria del thread (ulimit -s). ps: la limitazione dello stack di memoria thread è 10M nella mia VM rhel e, per la memoria 1.5G, questa macchina virtuale può permettersi solo 150 thread?

Probabilmente non dovrebbe importare. Otterrai prestazioni molto migliori progettando il tuo algoritmo per utilizzare un numero fisso di thread (ad esempio, 4 o 8 se hai 4 o 8 processori). Puoi farlo con code di lavoro, IO asincrono o qualcosa di simile a libevent.

Utilizzare la nbio i / o nbio non bloccante o qualsiasi altra cosa, se sono necessari più thread per effettuare chiamate I / O che bloccano

controlla la dimensione dello stack per thread con ulimit, nel mio caso Redhat Linux 2.6:

  ulimit -a ... stack size (kbytes, -s) 10240 

A ciascuno dei tuoi thread verrà assegnata questa quantità di memoria (10 MB) per lo stack. Con un programma a 32 bit e uno spazio di indirizzamento massimo di 4 GB, questo è un massimo di soli 4096 MB / 10 MB = 409 thread !!! Il codice del programma meno, meno lo spazio dell’heap probabilmente porterà a un massimo osservato. di 300 thread.

Dovresti essere in grado di risolverlo compilando ed eseguendo su 64bit o impostando ulimit -s 8192 o anche ulimit -s 4096. Ma se questo è consigliabile è un’altra discussione …

Dipende dal tuo sistema, basta scrivere un programma di esempio [creando processi in un loop] e controlla usando ps axo pid, ppid, rss, vsz, nlwp, cmd. Quando non può più creare discussioni controlla il conteggio nlwp [nlwp è il numero di thread] voilà hai la tua risposta a prova di scemo invece di passare attraverso i libri

Per chi guarda questo ora, su sistemi systemd (nel mio caso, in particolare su Ubuntu 16.04) c’è un altro limite applicato dal parametro cgroup pids.max.

Questo è impostato su 12.288 per impostazione predefinita e può essere ignorato in /etc/systemd/logind.conf

Altri consigli si applicano ancora compresi pids_max, threads-max, max_maps_count, ulimits, ecc.

Possiamo vedere il numero massimo di thread definiti nel seguente file in linux

cat / proc / sys / kernel / threads-max

(O)

sysctl -a | grep threads-max

Per impostare in modo permanente,

 vim /etc/sysctl.conf 

e aggiungi

 kernel.threads-max = "value" 

Puoi vedere il valore corrente con il seguente comando: cat / proc / sys / kernel / threads-max

Puoi anche impostare il valore come

echo 100500> / proc / sys / kernel / threads-max

Il valore impostato verrà confrontato con le pagine RAM disponibili. Se le strutture del thread occupano più di 1/8 delle pagine RAM disponibili, thread-max verrebbe ridotto di conseguenza.

Sì, per aumentare il numero di thread necessario per aumentare la memoria virtuale o diminuire le dimensioni dello stack. In Raspberry Pi non ho trovato un modo per aumentare la memoria virtuale, se si riduce la dimensione dello stack da un valore predefinito di 8 MB a 1 MB. È ansible ottenere più di 1000 thread per processo, ma ridurre le dimensioni dello stack con il comando “ulimit -s” fallo per tutti i thread. Quindi, la mia soluzione era usare “pthread_t” instance “thread class” perché pthread_t mi permetteva di impostare la dimensione dello stack per ogni thread. Infine, sono disponibile per archiviare più di 1000 thread per processo in Raspberry Pi ognuno con 1 MB di stack.