web-dev-qa-db-fra.com

Comment définir une limite globale de nofile pour éviter l'erreur "nombreux fichiers ouverts"?

J'ai un service websocket. c'est strage qui ont erreur: "trop ​​de fichiers ouverts", mais j'ai configuré le système configure:

/etc/security/limits.conf
*               soft    nofile          65000
*               hard    nofile          65000

/etc/sysctl.conf
net.ipv4.ip_local_port_range = 1024 65000

ulimit -n
//output 6500

Donc, je pense que mon système configure c'est correct.

Mon service est géré par superviseur, est-ce que des limites de superviseur sont possibles?

vérifier le début du processus par le superviseur:

cat /proc/815/limits
Max open files            1024                 4096                 files

vérifier le démarrage manuel du processus:

cat /proc/900/limits
Max open files            65000                 65000                 files

La raison est utilisé superviseur gérer serivce. si je redémarre le superviseur et redémarre le processus enfant, c'est "max open files" ok (65000) mais incorrect (1024) lorsque le redémarrage du superviseur du système démarre automatiquement. 

Peut-être que le niveau de démarrage du superviseur est trop élevé et que la configuration du système ne fonctionne pas au démarrage du superviseur?

modifier:

système: Ubuntu 12.04 64bit

Ce n'est pas un problème de superviseur, tous les processus démarrant automatiquement après le redémarrage du système ne sont pas utilisés (le nombre maximal de fichiers ouverts = 1024), mais le redémarrage est correct.

mettre à jour

Peut-être que le problème est:

Maintenant, la question est de savoir comment définir une limite globale pour nofile, car je ne souhaite pas définir de limite pour nofile dans chaque script de démarrage dont j'ai besoin.

linuxubuntulinux-kernelupstart
25
leiyonglin

J'ai eu le même problème. Même si ulimit -Sn affiche ma nouvelle limite, l'exécution de supervisorctl restart all et de cat dans les fichiers proc n'affichait pas les nouvelles limites.

Le problème est que supervisord a toujours les limites d'origine. Par conséquent, tous les processus enfants qu'il crée ont toujours les limites d'origine.

La solution consiste donc à tuer et à redémarrer supervisord.

9
Luqmaan

Correction de ce problème en définissant les limites pour tous les utilisateurs du fichier:

$ cat /etc/security/limits.d/custom.conf
* hard nofile 550000
* soft nofile 550000

REDÉMARREZ LE SERVEUR après avoir défini les limites.

TRÈS IMPORTANT: Le dossier /etc/security/limits.d/ contient des limites spécifiques à l'utilisateur. Dans mon cas, les limites relatives au hadoop 2 (cloudera). Ces limites spécifiques à l'utilisateur remplacent les limites globales. Par conséquent, si vos limites ne sont pas appliquées, vérifiez les limites spécifiques à l'utilisateur dans le dossier /etc/security/limits.d/ et dans le fichier /etc/security/limits.conf.

ATTENTION: La définition de limites spécifiques à l'utilisateur est la voie à suivre dans tous les cas. La définition de la limite globale (*) doit être évitée. Dans mon cas, il s’agissait d’un environnement isolé qui devait simplement éliminer le problème des limites de fichiers de mon expérience. 

J'espère que cela épargnera des cheveux à quelqu'un, car j'ai passé trop de temps à me tirer les cheveux en morceaux!

9
OkezieE

À tous les googlers fatigués: vous pouvez rechercher le paramètre minfds dans the supervisor config . Ce paramètre semble prendre effet à la fois pour le processus de supervision et pour les enfants. J'avais un certain nombre d'autres stratégies, notamment le lancement d'un script Shell fixant les limites avant d'exécuter le programme, mais c'était la seule chose qui fonctionnait.

5
Dan

Essayez d’éditer /etc/sysctl.conf et ajustez les limites globalement Par exemple:

Force la limite à 100 000 fichiers. 

vi /etc/sysctl.conf

Ajouter:

fs.file-max = 100000

Enregistrez et fermez le fichier. Les utilisateurs doivent se déconnecter et se reconnecter pour que les modifications prennent effet ou il suffit de taper la commande suivante:

sysctl -p
4
Giovanni Silva

Vous pouvez trouver votre limite avec:

 cat /proc/sys/fs/file-max

ou sysctl -a | grep file

changez-le dans le fichier/proc/sys/fs/file-max ou avec:

sysctl -w fs.file-max=100000
2
Dimitrios

la réponse de luqmaan a été le bon moyen pour moi, sauf une petite mise en garde: le caractère générique * ne s'applique pas à la racine dans Ubuntu (comme décrit dans les commentaires de limits.conf).

Vous devez définir explicitement la limite pour root si supervisord est démarré en tant qu'utilisateur root:

vi /etc/security/limits.conf

root soft nofile 65535
root hard nofile 65535
2
lextoumbourou

Pouvez-vous définir la limite de service de cette manière:

ajouter: LimitNOFILE=65536 dans: /etc/systemd/system/{NameofService}.service

1
Maicon Silva Pinto de Abreu Sa