D'après mon expérience, ma tâche à nombre de processus élevé n'a réussi qu'avec:
kern.maxproc=2500 # This is as big as I could set it.
kern.maxprocperuid=2048
ulimit -u 2048
Les deux premiers peuvent aller dans /etc/sysctl.confet la valeur ulimit dans launchd.conf, pour un réglage fiable.
Puisque tcp / ip faisait partie de ce que je faisais, je devais aussi augmenter
kern.ipc.somaxconn=8192
de son 128 par défaut.
Avant d'augmenter les limites du processus, j'obtenais des échecs «fork», pas assez de ressources. Avant d'augmenter kern.ipc.somaxconn, je recevais des erreurs de "tuyau cassé".
C'était en exécutant un bon nombre (500-4000) de processus détachés sur mon monstre Mac, OS 10.5.7, puis 10.5.8, maintenant 10.6.1. Sous Linux sur l'ordinateur de mes patrons, cela a juste fonctionné.
Je pensais que le nombre de processus serait plus proche de 1000, mais il semble que chaque processus que j'ai commencé comprenait sa propre copie du shell en plus de l'élément réel faisant le travail réel. Très festif.
J'ai écrit un jouet d'affichage qui ressemblait à quelque chose comme:
#!/bin/sh
while[ 1 ]
do
n=netstat -an | wc -l
nw=netstat -an | grep WAIT | wc -l
p=ps -ef | wc -l
psh=ps -ef | fgrep sh | wc -l
echo "netstat: $n wait: $nw ps: $p sh: $psh"
sleep 0.5
done
et regardé le nombre maximum de processus dans ps -ef et traîner dans netstat en attente TIME_WAITd'expiration ... Avec les limites augmentées, j'ai vu plus de 3500 TIME_WAITarticles au maximum.
Avant de relever les limites, je pouvais `` me faufiler '' sur le seuil de défaillance, qui a commencé au-dessous de 1K mais a atteint une valeur élevée de 1190. mis en cache qui s'est étendu à sa limite chaque fois qu'il a échoué.
Bien que mon cas de test ait eu une «attente» comme déclaration finale, il y avait encore BEAUCOUP de processus détachés qui traînaient après sa sortie.
J'ai obtenu la plupart des informations que j'ai utilisées à partir de publications sur Internet, mais elles n'étaient pas toutes exactes. Votre kilométrage peut varier.