Nombre maximal de threads par processus sous Linux?
Quel est le nombre maximal 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 limite de threads distinct par processus, mais une limite sur le nombre total de processus sur le système (les threads sont essentiellement des processus avec un espace d'adressage partagé sous Linux) que vous pouvez afficher comme suit:
cat /proc/sys/kernel/threads-max
La valeur par défaut est le nombre de pages de mémoire/4. Vous pouvez augmenter ceci 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/getrlimit pour plus de détails sur ces limites.
Cela est FAUX de dire que LINUX n’a pas de limite de threads séparée par processus.
Linux implémente le nombre maximum de threads par processus indirectement !!
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. Cependant, une réduction excessive de la taille de la pile peut entraîner une défaillance du code en raison d'un débordement de la pile alors que la mémoire virtuelle maximale correspond à 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 d'échange pour augmenter cette valeur)
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 définir 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 plus si c'est la valeur par défaut sous Linux), alors un système 32 bits manquera d'espace d'adressage après 3 000 threads (en supposant que le dernier Go est réservé au noyau). .
Toutefois, vous obtiendrez très probablement des performances médiocres si vous utilisez plus de quelques dizaines de threads. Tôt ou tard, vous aurez trop de temps de commutation de contexte, de temps système dans le planificateur, etc. (Créer un grand nombre de threads ne consomme que beaucoup de mémoire. Mais beaucoup de threads avec un travail à faire vont vous ralentir car ils se battent pour le temps CPU disponible.)
Que faites-vous là où cette limite est même pertinente?
100k threads 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 threads, 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, 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 128 TB de mémoire virtuelle, cela se produit sous Solaris. Si vous souhaitez augmenter la mémoire virtuelle, vous devez ajouter de l'espace d'échange.
Pour le récupérer:
cat /proc/sys/kernel/threads-max
Pour le définir:
echo 123456789 > /proc/sys/kernel/threads-max
123456789 = # de threads
Nombre de threads limite:
$ cat /proc/sys/kernel/threads-max
Comment est-il calculé:
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
et: x86_64 la taille de la page (PAGE_SIZE) est 4K; Comme toutes les autres architectures, x86_64 possède une pile de noyau pour chaque thread actif. Ces piles de threads ont la valeur THREAD_SIZE (2 * PAGE_SIZE);
pour les mempages:
cat /proc/zoneinfo | grep spanned | awk '{totalpages=totalpages+$2} END {print totalpages}';
donc, en réalité, le nombre n’est pas lié à la limitation de la taille de la pile mémoire (ulimit -s).
P.S: La limite de pile de mémoire de threads est de 10 M dans ma VM rhel, et pour une mémoire de 1,5 G, ce VM ne peut se permettre que 150 threads?
Cela ne devrait probablement pas avoir d'importance. Vous allez obtenir 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, des E/S asynchrones ou quelque chose comme libevent.
Utilisez la bibliothèque nbio Non bloquante des entrées-sorties .__
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) attribuée à sa pile. Avec un programme 32 bits et un espace d’adresse maximal de 4 Go, c’est un maximum de seulement 4096 Mo/10 Mo = 409 threads !!! Moins de code de programme, moins de heap-space conduira probablement à un maximum observé. de 300 fils.
Vous devriez pouvoir soulever cela en compilant et en exécutant 64bit ou en plaçant ulimit -s 8192 ou même ulimit -s 4096. Mais si cela est souhaitable, c'est une autre discussion ...
Dépend de votre système, écrivez simplement un exemple de programme [en créant des processus en boucle] et vérifiez-le en utilisant ps axo pid, ppid, rss, vsz, nlwp, cmd. Quand il ne peut plus créer de threads, vérifiez nlwp count [nlwp est le nombre de threads] voila vous avez votre réponse à toute épreuve au lieu d'aller dans des livres
Pour ceux qui regardent cela maintenant, sur les systèmes systemd (dans mon cas, en particulier Ubuntu 16.04), une autre limite est imposée par le paramètre cgroup pids.max.
Ceci est défini sur 12 288 par défaut 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.
Pour définir en permanence,
vim /etc/sysctl.conf
et ajouter
kernel.threads-max = "value"
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 à 1 Mo par défaut, il est possible d’obtenir plus de 1 000 threads par processus, mais de diminuer la taille de la pile avec la commande «ulimit -s». faites ceci pour tous les threads. Ma solution a donc été d'utiliser l'instance «pthread_t», «classe de threads», car pthread_t m'a laissé 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.
Nous pouvons voir le nombre maximal 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 à l'aide de 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 fil occupent plus de 1/8e des pages RAM disponibles, thread-max serait réduit en conséquence.