Descripteurs pratiques maximum de fichiers ouverts (ulimit -n) pour un système à volume élevé
Nous avons récemment commencé à tester la charge de notre application et avons remarqué qu'il manquait de descripteurs de fichiers après environ 24 heures.
Nous utilisons RHEL 5 sur un Dell 1955:
CPU: 2 x Dual Core 2,66 GHz 4 Mo 5150/1333 FSB RAM: 8 Go RAM HDD: 2 x 160 Go 2,5 "disques durs SATA
J'ai vérifié la limite de descripteur de fichier et elle a été fixée à 1024. Étant donné que notre application pourrait potentiellement avoir environ 1 000 connexions entrantes ainsi que 1 000 connexions sortantes, cela semble assez faible. Sans parler des fichiers réels qui doivent être ouverts.
Ma première pensée a été d'augmenter simplement le paramètre ulimit -n de quelques ordres de grandeur, puis de relancer le test, mais je voulais connaître les ramifications potentielles d'un réglage trop élevé de cette variable.
Existe-t-il des meilleures pratiques pour définir cela autre que de déterminer le nombre de descripteurs de fichiers que notre logiciel peut théoriquement ouvrir?
Ces limites provenaient d'une époque où plusieurs utilisateurs "normaux" (et non des applications) partageaient le serveur, et nous avions besoin de moyens pour les protéger contre l'utilisation de trop de ressources.
Ils sont très faibles pour les serveurs hautes performances et nous les définissons généralement sur un nombre très élevé. (24k environ) Si vous avez besoin de nombres plus élevés, vous devez également modifier l'option sysctl file-max (généralement limitée à 40k sur ubuntu et 70k sur rhel).
Réglage ulimit:
# ulimit -n 99999
Fichiers Sysctl max:
#sysctl -w fs.file-max=100000
De plus, et c'est très important, vous devrez peut-être vérifier si votre application présente une fuite de descripteur de mémoire/fichier. Utilisez lsof pour voir tout ce qu'elle a ouvert pour voir si elles sont valides ou non. N'essayez pas de changer votre système pour contourner les bogues des applications.
Tu pourrais toujours juste
cat /proc/sys/fs/file-nr
Pendant la situation de "charge élevée" pour voir combien de descripteurs de fichiers sont utilisés.
Quant à un maximum - cela dépend juste de ce que vous faites.
Si les descripteurs de fichiers sont des sockets TCP, etc., vous risquez d'utiliser une grande quantité de mémoire pour les tampons de socket et autres objets du noyau; cette mémoire ne sera pas échangeable.
Mais sinon, non, en principe il ne devrait pas y avoir de problème. Consultez la documentation du noyau pour essayer de déterminer la quantité de mémoire du noyau qu'il utilisera et/ou testez-la.
Nous exécutons des serveurs de bases de données avec des descripteurs de fichiers ~ 10k ouverts (principalement sur des fichiers de disque réels) sans problème majeur, mais ils sont 64 bits et ont beaucoup de RAM.
Le paramètre ulimit est par processus, mais il y a aussi une limite à l'échelle du système (32k je pense par défaut)
Je n'ai personnellement connaissance d'aucune bonne pratique. C'est quelque peu subjectif selon la fonction du système.
N'oubliez pas que 1024 que vous voyez est une limite par utilisateur et non une limite à l'échelle du système. Considérez le nombre d'applications que vous exécutez sur ce système. Est-ce le seul? L'utilisateur qui exécute cette application fait-il autre chose? (IE, avez-vous des humains qui utilisent ce compte pour se connecter et exécuter des scripts qui peuvent potentiellement s'enfuir?)
Étant donné que la boîte n'exécute que cette seule application et que le compte exécutant ladite application est uniquement à cette fin, je ne vois aucun inconvénient à augmenter votre limite comme vous le suggérez. S'il s'agit d'une équipe de développement interne, je demanderais leur avis. S'il s'agit d'un fournisseur tiers, ils peuvent avoir des exigences ou des recommandations spécifiques.
Cela me semble être une de ces questions à laquelle il est préférable de répondre par "tester dans un environnement de développement". Je me souviens il y a des années, Sun est devenu nerveux lorsque vous avez joué avec ça, mais pas avec une telle nervosité. Sa limite à l'époque était également de 1024, donc je suis un peu surpris de voir que c'est la même chose maintenant pour Linux, il semble que cela devrait être plus élevé.
J'ai trouvé le lien suivant éducatif lorsque j'ai recherché sur Google les réponses à votre question: http://www.netadmintools.com/art295.html
Et celui-ci aussi: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible