Qual è il numero massimo di thread che possono essere creati da un processo in Linux?
Come (se possibile) è possibile modificare questo valore?
Qual è il numero massimo di thread che possono essere creati da un processo in Linux?
Come (se possibile) è possibile modificare questo valore?
Risposte:
Linux non ha un limite di thread separato per processo, ma solo un limite al numero totale di processi sul sistema (i thread sono essenzialmente solo processi con uno spazio di indirizzi condiviso su Linux) che è possibile visualizzare in questo modo:
cat /proc/sys/kernel/threads-max
L'impostazione predefinita è il numero di pagine di memoria / 4. Puoi aumentare questo come:
echo 100000 > /proc/sys/kernel/threads-max
Esiste anche un limite al numero di processi (e quindi thread) che un singolo utente può creare, vedere i ulimit/getrlimit
dettagli relativi a questi limiti.
E667: Fsync failed
quando provo a salvare su vi.
Ciò è sbagliato per dire che LINUX non ha thread separati per limite di processo.
Linux implementa indirettamente il numero massimo di thread per processo !!
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, la riduzione eccessiva delle dimensioni dello stack può comportare un errore del codice a causa di un overflow 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 swap per aumentarla)
Dimensione totale dello stack: ulimit -s
(il valore predefinito è 8 Mb)
Comando per aumentare questi valori:
ulimit -s newvalue
ulimit -v newvalue
* Sostituisci il nuovo valore con il valore che vuoi mettere come limite.
Riferimenti:
http://dustycodes.wordpress.com/2012/02/09/increasing-number-of-threads-per-process/
ulimit -s
. È molto possibile (non ragionevole, ma possibile) creare tanti thread quanti sono gli ID thread possibili. Sotto Linux a 64 bit, è persino "possibile" facilmente creare più thread di quanti siano gli ID thread (ovviamente non è possibile, ma per quanto riguarda lo stack, lo è). 3. Stack reserve, commit e VM sono cose diverse, specialmente con OC.
In termini pratici, il limite è generalmente determinato dallo spazio dello stack. Se ogni thread ottiene uno stack da 1 MB (non ricordo se quello è il valore predefinito 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 probabilmente sperimenterai prestazioni terribili se usi più di qualche dozzina di thread. Prima o poi, si ottiene un sovraccarico di commutazione del contesto, un sovraccarico eccessivo nello scheduler e così via. (La creazione di un numero elevato di thread fa poco più che consumare molta memoria. Ma molti thread con il lavoro effettivo da svolgere ti rallenteranno mentre si battono per il tempo disponibile della CPU)
Cosa stai facendo laddove questo limite sia persino rilevante?
thread 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 utilizza la memoria virtuale per calcolare il massimo del 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 il thread max è diverso tra ogni sistema, poiché il ram installato può avere dimensioni diverse, so che Linux non ha bisogno di aumentare la memoria virtuale, perché a 32 bit abbiamo 3 GB per lo spazio utente e 1 GB per il kernel, a 64 bit abbiamo 128 TB di memoria virtuale, che si verificano su Solaris, se si desidera aumentare la memoria virtuale è necessario aggiungere spazio di swap.
Per recuperarlo:
cat /proc/sys/kernel/threads-max
Per impostarlo:
echo 123456789 > /proc/sys/kernel/threads-max
123456789 = # di thread
>
) parte perde il sudo
: tryecho 12345678 | sudo tee -a /proc/sys/kernel/threads-max
Limite conteggio discussioni:
$ 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. Queste pile di thread sono THREAD_SIZE (2 * PAGE_SIZE) grandi;
per i mempage:
cat /proc/zoneinfo | grep spanned | awk '{totalpages=totalpages+$2} END {print totalpages}';
quindi in realtà il numero non è correlato con la limitazione della dimensione dello stack della memoria del thread ( ulimit -s
).
PS: la limitazione dello stack di memoria del thread è 10M nella mia VM rhel e per la memoria 1.5G, questa VM può permettersi solo 150 thread?
Per chiunque lo guardi ora, sui sistemi systemd (nel mio caso, in particolare Ubuntu 16.04) c'è un altro limite imposto dal parametro cgroup pids.max.
L'impostazione predefinita è 12.288 e può essere sostituita in /etc/systemd/logind.conf
Altri consigli si applicano ancora, tra cui pids_max, thread-max, max_maps_count, ulimits, ecc.
controlla le dimensioni dello stack per thread con ulimit, nel mio caso Redhat Linux 2.6:
ulimit -a
...
stack size (kbytes, -s) 10240
Ognuno dei tuoi thread riceverà questa quantità di memoria (10 MB) assegnata per il suo stack. Con un programma a 32 bit e uno spazio di indirizzi massimo di 4 GB, questo è un massimo di soli 4096 MB / 10 MB = 409 thread !!! Meno il codice del programma, meno lo spazio dell'heap probabilmente porterà ad un massimo osservato. di 300 fili.
Dovresti essere in grado di aumentare questo compilando ed eseguendo su 64 bit o impostando ulimit -s 8192 o persino ulimit -s 4096. Ma se questo è consigliabile è un'altra discussione ...
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.
Dipende dal tuo sistema, basta scrivere un programma di esempio [creando processi in un ciclo] e controllare usando ps axo pid, ppid, rss, vsz, nlwp, cmd. Quando non è più possibile creare thread controlla nlwp count [nlwp è il numero di thread] voilà hai la tua risposta a prova di stupido invece di passare attraverso i libri
Per impostare in modo permanente,
vim /etc/sysctl.conf
e aggiungi
kernel.threads-max = "value"
Possiamo vedere il numero massimo di thread definiti nel seguente file in linux
cat / proc / sys / kernel / thread-max
(O)
sysctl -a | thread grep-max
È possibile visualizzare il valore corrente dal seguente comando: cat / proc / sys / kernel / thread-max
Puoi anche impostare il valore come
echo 100500> / proc / sys / kernel / thread-max
Il valore impostato verrà verificato rispetto alle pagine RAM disponibili. Se le strutture di thread occupano più di 1/8) delle pagine RAM disponibili, thread-max verrebbe ridotto di conseguenza.
Sì, per aumentare il numero di thread è necessario aumentare la memoria virtuale o ridurre le dimensioni dello stack. In Raspberry Pi non ho trovato il modo di aumentare la memoria virtuale, se si riducono le dimensioni dello stack da 8 MB a 1 MB predefiniti È possibile ottenere più di 1000 thread per processo ma ridurre le dimensioni dello stack con il comando "ulimit -s" fai questo per tutti i thread. Quindi, la mia soluzione era usare l'istanza "pthread_t" "thread class" perché pthread_t mi ha permesso di impostare la dimensione dello stack per ogni thread. Infine, sono disponibile per l'archiviazione di oltre 1000 thread per processo in Raspberry Pi ciascuno con 1 MB di stack.