ubuntu - trop de fichiers ouverts?
j'ai un service websocket. c'est strage qui a une erreur:"trop de fichiers ouverts", mais j'ai configuré le système:
/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 le configure correctement.
mon service est géré par superviseur, c'est possible limites de superviseur?
début du processus de vérification par le superviseur:
cat /proc/815/limits
Max open files 1024 4096 files
manuel du processus de vérification début:
cat /proc/900/limits
Max open files 65000 65000 files
la raison est utilisé superviseur de gérer le service. si je redémarre le superviseur et redémarre le processus enfant, c'Est" fichiers ouverts max " ok(65000) mais faux(1024) lorsque le superviseur du système de redémarrage démarre automatiquement.
peut être le niveau de départ du superviseur est trop élevé et la configuration du système ne fonctionne pas quand le superviseur commence?
edit:
système: ubuntu 12.04 64 bits
ce n'est pas un problème de superviseur, tout le processus démarrage automatique après redémarrage du système n'utilisez pas system configure(max open files=1024), mais redémarrez c'est ok.
mise à jour
peut-être que le problème est:
- https://bugs.launchpad.net/ubuntu/+source / upstart/+bug / 938669
- http://bryanmarty.com/blog/2012/02/10/setting-nofile-limit-upstart /
- Augmenter max des fichiers ouverts pour Ubuntu/Upstart (initctl)
maintenant, la question est, comment définir une limite nofile globale parce que je ne veux pas définir la limite nofile dans chaque script upstart dont j'ai besoin.
8 réponses
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 cat dans les fichiers proc ne montre pas les nouvelles limites.
le problème est que supervisord a encore les limites originales. Par conséquent tout processus enfant qu'il crée ont encore les limites originales.
donc, la solution est de tuer et de redémarrer supervisord .
a corrigé ce problème en fixant les limites pour tous les utilisateurs dans le fichier:
$ cat /etc/security/limits.d/custom.conf
* hard nofile 550000
* soft nofile 550000
redémarre 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 hadoop 2 (cloudera) limites connexes. Ces limites spécifiques à l'utilisateur supplanteront les limites globales donc si vos limites ne sont pas appliquées, assurez-vous de vérifier les limites spécifiques à l'utilisateur dans le dossier /etc/security/limits.d/ et dans le dossier /etc/security/limits.conf .
attention: Fixer des limites spécifiques à l'utilisateur est la voie à suivre dans tous les cas. Il faut éviter de fixer la limite globale ( * ). Dans mon cas, il s'agissait d'un environnement isolé et juste nécessaire pour éliminer la question des limites de fichiers de mon expérience.
espérons que cela sauve quelqu'un certains cheveux - que j'ai passé trop de temps à tirer mes cheveux chunk par chunk!
à tous les googleurs fatigués: vous pourriez être à la recherche du paramètre minfds dans la config superviseur . Ce cadre semble s'appliquer à la fois au processus de supervision et aux enfants. J'ai eu un certain nombre d'autres stratégies, dont le lancement d'un script shell qui établissent les limites avant l'exécution du programme, mais c'était la seule chose qui a fonctionné.
Essayez de modifier /etc/sysctl.conf et ajuster les limites globalement Par exemple:
force la limite à 100000 fichiers.
vi /etc/sysctl.conf
ajouter:
fs.file-max = 100000
Enregistrer et fermer le fichier. Les utilisateurs doivent se déconnecter et se reconnecter à nouveau pour que les changements prennent effet ou simplement taper la commande suivante:
sysctl -p
Vous pouvez vous trouver de limite:
cat /proc/sys/fs/file-max
ou sysctl -a | grep file
modifier dans /proc/sys/fs/file-max dossier ou avec:
sysctl -w fs.file-max=100000
la réponse de luqmaan était le billet pour moi, à l'exception d'une petite mise en garde: le Joker * ne s'applique pas à root dans Ubuntu (comme décrit dans les commentaires de limits.conf ).
vous devez définir explicitement la limite pour root si supervisord est lancé en tant qu'utilisateur root:
vi /etc/security/limits.conf
root soft nofile 65535
root hard nofile 65535
pouvez-vous définir la limite de Service de cette façon:
ajouter: LimitNOFILE=65536
in: /etc/systemd/system/{NameofService}.service
je pense que cela n'a rien à voir avec les fichiers ouverts(c'est juste un message d'erreur erroné). Tout port que votre application utilise en cours d'utilisation. 1. Essayez de trouver le numéro de processus avec la commande
ps aux
2. Tuer le processus (par exemple 8572) avec la commande
sudo kill -9 8572
3. Redémarrez votre application.