comprendre les descripteurs de fichiers max pour linux et nginx, et la meilleure valeur pour worker_rlimit_nofile

J'ai eu l'erreur apparemment courante "trop ​​de descripteurs de fichiers" sur nginx. Après de nombreuses recherches, la solution consiste clairement à augmenter le nombre de descripteurs de fichiers disponibles pour nginx. Mais il n'y a pas assez d'informations pour que je me sente à l'aise de le faire de manière significative et sûre. Voici les principaux points abordés par la plupart des discussions de forum / e-mail:

• le système d'exploitation a sa propre limite de descripteur de fichier total (sur mon système, cat /proc/sys/fs/file-maxgénère "100678")
• chaque utilisateur peut aussi avoir sa propre limite (mais sur mon système, il fonctionne ulimitcomme n'importe quel utilisateur génère "illimité" voir la mise à jour en bas avec plus de détails )
• quelques personnes ont dit quelque chose dans le sens de ce que cette personne a dit: 'Directive worker_rlimit_nofile ne spécifie pas "combien", c'est la limite du système d'exploitation qui le fait. La directive worker_rlimit_nofile permet simplement d'élargir cette limite de manière rapide et sale si cela ne suffit pas. Donc, je suppose que l'implication est qu'il est "préférable" de définir la limite pour l'utilisateur du système d'exploitation nginx plutôt que dans la configuration?

Je peux simplement ajouter une valeur worker_rlimit_nofile supérieure au nombre de connexions par travailleur et l'appeler un jour, mais je sens que je ne sais pas vraiment ce qui se passe ici.

• pourquoi la limite par travailleur serait-elle inférieure à la limite du système d'exploitation?
• Comment savoir quelle est ma limite maintenant?

mise à jour : pour root et pour un utilisateur normal, ulimit sort "illimité", MAIS ulimit -Hnet les ulimit -Sndeux sortent 1024

worker_rlimit_nofiledéfinira la limite des descripteurs de fichiers pour les processus de travail comme opposé à l'utilisateur exécutant nginx. Si d'autres programmes exécutés sous cet utilisateur ne seront pas en mesure de gérer correctement le manque de descripteurs de fichiers, vous devez définir cette limite légèrement moins que ce qui est pour l'utilisateur.

Premièrement, à quoi sert vos descripteurs de fichiers?

1. Chaque connexion active à un client
2. Vous utilisez proxy_pass? Cela ouvrira un socket à l'hôte: port gérant ces requêtes
3. Vous utilisez proxy_pass sur un port local? C'est une autre prise ouverte. (Pour le propriétaire de ce processus)
4. fichiers statiques desservis par nginx

Pourquoi la limite par travailleur serait-elle inférieure à la limite du système d'exploitation?

Ceci est contrôlé par le système d'exploitation car le travailleur n'est pas le seul processus en cours d'exécution sur la machine. Pour le changer pour l'utilisateur exécutant nginx, voir ci-dessous. Ce serait très mauvais si vos employés utilisaient tous les descripteurs de fichiers disponibles pour tous les processus, ne définissez pas vos limites pour que ce soit possible.

#/etc/sysctl.conf
#This sets the value you see when running cat  /proc/sys/fs/file-max
fs.file-max = 65536"


#/etc/security/limits.conf
#this sets the defaults for all users
* soft nofile 4096
* hard nofile 4096

#This overrides the default for user `usernamehere`
usernamehere soft nofile 10240
usernamehere hard nofile 10240

Après ces changements de limites de sécurité, je pense que je devais encore augmenter la limite logicielle pour l'utilisateur qui l'utilise ulimit.

Comment savoir quelle est ma limite maintenant?

ulimit -a Affiche toutes les limites associées à l'utilisateur sous lequel vous l'exécutez.

Je dois vérifier la source pour être honnête, mais c'est assez bas.

J'ai utilisé worker_rlimit_nofile 15000;et je n'ai eu aucun problème, vous pouvez l'augmenter en toute sécurité, cependant, la chance de manquer de descripteurs de fichiers est minuscule.