Le plus grand nombre maximum autorisé de fichiers ouverts sous Linux

10

Y a-t-il une limite (technique ou pratique) à la taille que vous pouvez configurer le nombre maximum de fichiers ouverts sous Linux? Y a-t-il des effets négatifs si vous le configurez à un très grand nombre (disons 1-100M)?

Je pense à l'utilisation du serveur ici, pas aux systèmes embarqués. Les programmes utilisant d'énormes quantités de fichiers ouverts peuvent bien sûr consommer de la mémoire et être lents, mais je m'intéresse aux effets indésirables si la limite est configurée beaucoup plus grande que nécessaire (par exemple, la mémoire consommée par la configuration uniquement).

linux files limit open-files Sampo
la source
En théorie, vous pourriez calculer le nombre de descripteurs de fichiers que votre système pourrait gérer en fonction de la mémoire disponible et de l'affirmation selon laquelle chaque fd consomme 1 Ko
Alastair McCormack

Réponses:

10

Je soupçonne que la raison principale de la limite est d'éviter une consommation excessive de mémoire (chaque descripteur de fichier ouvert utilise la mémoire du noyau). Il sert également de protection contre les applications boguées qui fuient les descripteurs de fichiers et consomment des ressources système.

Mais étant donné l'absurdité des systèmes modernes de RAM par rapport aux systèmes d'il y a 10 ans, je pense que les valeurs par défaut aujourd'hui sont assez faibles.

En 2011, la limite stricte par défaut pour les descripteurs de fichiers sous Linux est passée de 1024 à 4096 .

Certains logiciels (par exemple MongoDB) utilisent beaucoup plus de descripteurs de fichiers que la limite par défaut. Les gens de MongoDB recommandent d'augmenter cette limite à 64 000 . J'ai utilisé un rlimit_nofilede 300 000 pour certaines applications.

Tant que vous gardez la limite souple à la valeur par défaut (1024), il est probablement assez sûr d'augmenter la limite dure. Les programmes doivent appeler setrlimit()afin d'élever leur limite au-dessus de la limite souple, et sont toujours plafonnés par la limite dure.

Voir aussi quelques questions connexes:

UN B
la source
6
Cela n'a pas répondu à la question, cependant, qui demandait s'il y avait une limite technique ou pratique à la hauteur à laquelle on peut fixer la limite stricte . Oui, mais cette réponse ne le mentionne pas du tout.
JdeBP
Je trouve impossible d'élever la limite au-delà d'environ 1 million. Je pense qu'il pourrait être codé en dur dans le noyau, car malgré la modification de nombreuses configurations, je ne peux pas dépasser ce niveau. superuser.com/questions/1468436/…
Pavel Komarov
3

L'impact ne serait normalement pas observable, mais le module IO du noyau devra prendre en charge tous ces descripteurs de fichiers ouverts et ils pourraient également avoir un impact sur l'efficacité du cache.

De telles limites ont l'avantage de protéger l'utilisateur contre ses propres erreurs (ou celles de tiers). Par exemple, si vous exécutez un petit programme ou script qui bifurque indéfiniment, il finira par bloquer sur l'un des ulimits et empêchera donc un gel informatique plus intense (éventuellement irrécupérable).

Sauf si vous avez des raisons précises d'augmenter l'une de ces limites, vous devez l'éviter et mieux dormir.

Julie Pelletier
la source
2

Il est techniquement limité à la valeur maximale du long non signé (C Lang) soit 4 294 967 295

Référence: fs.hfichier

/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
  unsigned long nr_files;   /* read only */
  unsigned long nr_free_files;  /* read only */
  unsigned long max_files;    /* tunable THIS IS OUR VALUE */
};
Leonard T
la source
2
Avez-vous des références à ce sujet?
Tim
C'est également la valeur maximale pour un entier signé 32 bits, la valeur maximale d'un entier non signé 32 bits est 4 294 967 295.
Sampo
Tu as raison, Sampo. Mon erreur.
Leonard T
0

Je pense que votre préoccupation est compréhensible, mais très probablement Linux ne consommera pas beaucoup de mémoire pour les descripteurs de fichiers configurés (mais pas utilisés) :)

Je ne me souviens pas d'un tel problème dans ma carrière professionnelle depuis 10 ans.

Cordialement.

Tim Connor
la source
0

Calme tard mais cela devrait aider tout le monde à obtenir la réponse à cette question. La limite pratique du nombre de fichiers ouverts sous Linux peut également être comptée en utilisant le nombre maximum de descripteurs de fichiers qu'un processus peut ouvrir.

J'ai vu des limites changer de système en système. Dans la page de manuel getlimit , vous pouvez voir qui RLIMIT_NOFILE-1spécifie les limites en interne.

Pour vérifier la valeur RLIMIT_NOFILE, vous pouvez utiliser l'instruction ci-dessous pour obtenir un tuple

python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"

Le tuple renvoie les résultats sous la forme (Soflimit, hardlimit). Pour moi fonctionnant sur plusieurs systèmes, les résultats sont comme ci-dessous

(1024, 1048576) # on UBUNTU linux 
(65536, 65536)  # on amazon linux 
(1024, 9223372036854775807) # on macos

Remarque: 9223372036854775807 ce nombre signifie simplement l'infini. Vous atteindrez toujours d'autres limites de ressources avant de toucher cela. Si vous avez modifié le hardlimit sur un système au-delà de ce qu'il est, vous devrez modifier les paramètres du noyau.

Ankit Kulkarni
la source