Nombre maximum de threads par processus sous Linux?

Quel est le nombre maximum de threads pouvant être créés par un processus sous Linux?

Comment (si possible) cette valeur peut-elle être modifiée?

Linux n'a pas de threads séparés par limite de processus, juste une limite sur le nombre total de processus sur le système (les threads sont essentiellement des processus avec un espace d'adressage partagé sur Linux) que vous pouvez afficher comme ceci:

cat /proc/sys/kernel/threads-max

La valeur par défaut est le nombre de pages mémoire / 4. Vous pouvez augmenter cela comme:

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

Il existe également une limite sur le nombre de processus (et donc de threads) qu'un seul utilisateur peut créer, voir ulimit/getrlimitpour plus de détails sur ces limites.

Il est faux de dire que LINUX n'a ​​pas de threads séparés par limite de processus.

Linux implémente indirectement le nombre maximum de threads par processus !!

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

Ainsi, le nombre de threads par processus peut être augmenté en augmentant la mémoire virtuelle totale ou en diminuant la taille de la pile. Mais, une diminution excessive de la taille de la pile peut entraîner une défaillance du code en raison d'un débordement de pile alors que la mémoire virtuelle maximale est égale à la mémoire d'échange.

Vérifiez votre machine:

Mémoire virtuelle totale: ulimit -v(la valeur par défaut est illimitée, vous devez donc augmenter la mémoire de swap pour l'augmenter)

Taille totale de la pile: ulimit -s(la valeur par défaut est 8 Mo)

Commande pour augmenter ces valeurs:

ulimit -s newvalue

ulimit -v newvalue

* Remplacez la nouvelle valeur par la valeur que vous souhaitez mettre comme limite.

Références:

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

En termes pratiques, la limite est généralement déterminée par l'espace de pile. Si chaque thread obtient une pile de 1 Mo (je ne me souviens pas si c'est la valeur par défaut sous Linux), alors vous un système 32 bits manquera d'espace d'adressage après 3000 threads (en supposant que le dernier Go est réservé au noyau) .

Cependant, vous obtiendrez probablement des performances terribles si vous utilisez plus de quelques dizaines de threads. Tôt ou tard, vous obtenez trop de surcharge de changement de contexte, trop de surcharge dans le planificateur, etc. (La création d'un grand nombre de threads ne fait guère plus que consommer beaucoup de mémoire. Mais beaucoup de threads avec un travail réel à faire vont vous ralentir car ils se battent pour le temps CPU disponible)

Que faites-vous lorsque cette limite est même pertinente?

threads 100k appropriés sur 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

Mise à jour 2018 de @Thomas, sur les systèmes systemd:

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

@dragosrsupercool

Linux n'utilise pas la mémoire virtuelle pour calculer le maximum de thread, mais le ram physique installé sur le système

 max_threads = totalram_pages / (8 * 8192 / 4096);

http://kavassalis.com/2011/03/linux-and-the-maximum-number-of-processes-threads/

noyau / 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);

Donc, le thread max est différent entre chaque système, car le ram installé peut être de différentes tailles, je sais que Linux n'a pas besoin d'augmenter la mémoire virtuelle, car sur 32 bits, nous avons 3 Go pour l'espace utilisateur et 1 Go pour le noyau, sur 64 bits, nous avons obtenu 128 To de mémoire virtuelle, ce qui se produit sur Solaris, si vous voulez augmenter la mémoire virtuelle dont vous avez besoin pour ajouter de l'espace de swap.

Pour le récupérer:

cat /proc/sys/kernel/threads-max

Pour le régler:

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

123456789 = # de threads

Limite du nombre de threads:

$ cat /proc/sys/kernel/threads-max 

Comment est-il calculé:

max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);

et: la taille de page x86_64 (PAGE_SIZE) est 4K; Comme toutes les autres architectures, x86_64 a une pile de noyau pour chaque thread actif. Ces piles de threads sont THREAD_SIZE (2 * PAGE_SIZE) big;

pour les mempages:

cat /proc/zoneinfo | grep spanned | awk '{totalpages=totalpages+$2} END {print totalpages}';

donc en fait le nombre n'est pas lié à la limitation de la taille de la pile de la mémoire des threads (ulimit -s ).

PS: la limitation de la pile de mémoire des threads est de 10 Mo dans ma machine virtuelle rhel, et pour la mémoire de 1,5 Go, cette machine virtuelle ne peut se permettre que 150 threads?

Pour quiconque regarde cela maintenant, sur les systèmes systemd (dans mon cas, en particulier Ubuntu 16.04), il existe une autre limite imposée par le paramètre cgroup pids.max.

Il est défini par défaut sur 12 288 et peut être remplacé dans /etc/systemd/logind.conf

D'autres conseils s'appliquent toujours, notamment pids_max, threads-max, max_maps_count, ulimits, etc.

vérifiez la taille de la pile par thread avec ulimit, dans mon cas Redhat Linux 2.6:

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

Chacun de vos threads recevra cette quantité de mémoire (10 Mo) affectée à sa pile. Avec un programme 32 bits et un espace d'adressage maximum de 4 Go, c'est un maximum de seulement 4096 Mo / 10 Mo = 409 threads !!! Un code de programme négatif, un espace de stockage négatif entraînera probablement un maximum observé. de 300 fils.

Vous devriez être en mesure de le faire en compilant et en exécutant sur 64 bits ou en définissant ulimit -s 8192 ou même ulimit -s 4096. Mais si cela est conseillé, c'est une autre discussion ...

Cela ne devrait probablement pas avoir d'importance. Vous obtiendrez de bien meilleures performances en concevant votre algorithme pour utiliser un nombre fixe de threads (par exemple, 4 ou 8 si vous avez 4 ou 8 processeurs). Vous pouvez le faire avec des files d'attente de travail, des E / S asynchrones ou quelque chose comme libevent.

Utilisez une nbio bibliothèque d'E / S non bloquante ou autre, si vous avez besoin de plus de threads pour effectuer des appels d'E / S qui bloquent

Dépend de votre système, il suffit d'écrire un exemple de programme [en créant des processus en boucle] et de vérifier en utilisant ps axo pid, ppid, rss, vsz, nlwp, cmd. Quand il ne peut plus créer de threads, vérifiez le nombre de nlwp [nlwp est le nombre de threads] voila vous avez obtenu votre réponse à toute épreuve au lieu de passer par des livres

Pour définir définitivement,

vim /etc/sysctl.conf

et ajouter

kernel.threads-max = "value"

On peut voir le nombre maximum de threads définis dans le fichier suivant sous linux

cat / proc / sys / kernel / threads-max

(OU)

sysctl -a | grep threads-max

Vous pouvez voir la valeur actuelle par la commande suivante: cat / proc / sys / kernel / threads-max

Vous pouvez également définir la valeur comme

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

La valeur que vous définissez sera vérifiée par rapport aux pages RAM disponibles. Si les structures de thread occupent plus de 1 / 8ème) des pages RAM disponibles, thread-max serait réduit en conséquence.

Oui, pour augmenter le nombre de threads, vous devez augmenter la mémoire virtuelle ou réduire la taille de la pile. Dans Raspberry Pi, je n'ai pas trouvé de moyen d'augmenter la mémoire virtuelle, si vous diminuez la taille de la pile de 8 Mo par défaut à 1 Mo. Il est possible d'obtenir plus de 1000 threads par processus, mais diminuez la taille de la pile avec la commande «ulimit -s» faire cela pour tous les threads. Donc, ma solution était d'utiliser l'instance "pthread_t" "classe de threads" car le pthread_t me permettait de définir la taille de la pile pour chaque thread. Enfin, je suis disponible pour archiver plus de 1000 threads par processus dans Raspberry Pi, chacun avec 1 Mo de pile.