Est-ce que quelqu'un sait quelle est la taille limite théorique de /etc/hosts sur un système Linux avant de commencer à voir une dégradation des performances ?
En outre, quelqu'un peut-il m'indiquer une source officielle qui indique quelle est la limite prévue ?
Utilisez la source , Mike.
Le résolveur utilise une recherche linéaire dans le fichier texte pour localiser les entrées. C'est une base de données sans index. Donc, en l'absence d'une capacité supplémentaire de mise en cache, le coût des recherches sera de O(n). Quant à savoir quand cela entraînera une dégradation des performances, c'est une question à laquelle il est impossible de répondre - cela devient plus lent avec chaque enregistrement.
Si vous parlez à un programmeur ou à un administrateur de base de données, vous obtiendrez des chiffres différents quant au moment où une consultation d'index (O(log2(n)) est moins chère qu'un balayage complet de la table, mais la réponse sera généralement de l'ordre de 20 à 100 enregistrements.
Tout système linux ayant besoin de résoudre un grand nombre de noms (pas seulement des noms d'hôtes). Il devrait exécuter nscd ou un programme similaire. La plupart de ces caches indexeront eux-mêmes les données, ce qui annulera la question des performances, cependant...
Il ne fournit aucun moyen de gérer des ensembles de données complexes/grands - si vous avez un hôte avec plus d'une adresse IP, les recherches via le fichier hosts retourneront toujours la première entrée.
Pour boucler la boucle, nous avons ajouté 1,7 million d'enregistrements au fichier hosts et avons estimé que cela ajoutait 0,5 seconde à chaque consultation. Dans cet environnement, 0,5 seconde est négligeable. Je pense qu'un serveur DNS reste une meilleure solution, mais le client veut ce qu'il veut.
Un peu d'histoire de l'Internet -- avant le déploiement du DNS en 1984, le fichier d'hôtes était le seul moyen de résoudre les noms, et il n'y avait pas beaucoup d'hôtes sur le réseau -- 325 en février 1983 (RFC 847) . Il existe des copies de HOSTS.TXT (qui ne sont pas lisibles par une machine) datant de 1982 dans la base de données des archive de la liste de l'histoire de l'internet . Il y avait même un autre HOSTS.TXT. (celui de Geoff Goodfellow) .
Techniquement, il n'y a pas de limite supérieure. Cependant, chaque consultation du DNS aboutira à ce fichier, alors pourquoi s'exposer à ce risque ?
Pour ce que ça vaut, le plus grand /etc/hosts Le plus gros fichier que j'ai distribué dans mes environnements était de 1 200 lignes. Et cela fonctionnait bien pour l'application que je gérais. Le DNS n'était pas une option dans cet environnement particulier.
Disons-le autrement. S'il n'y a pas d'indexation dans le noyau, chaque accès effectuera une recherche linéaire qui dépendra de la taille du cache en termes de temps.
J'utilise un fichier hosts populaire trouvé sur internet, il y a 15 430 lignes et je ne remarque aucune dégradation réelle des performances de navigation sur le web.
@DeerHunter Je ne pense pas qu'il y ait quoi que ce soit dans le noyau Unix qui effectue la recherche de noms d'hôtes.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
8 votes
Cela me fait penser que vous faites quelque chose de fou ou que vous êtes loin des meilleures pratiques. Quels sont les détails ?
3 votes
Il semble bien que le déploiement d'un résolveur DNS léger soit une meilleure solution dans ce cas.
1 votes
J'ai un client qui en fait la demande. J'espérais trouver une documentation qui me permettrait de lui montrer pourquoi cela pose des problèmes, au lieu de devoir l'essayer sur une machine de test et d'en faire la démonstration.
1 votes
Le fichier hosts est une relique de l'époque pré-DNS des années 1970 et du début des années 1980. Avoir des centaines d'entrées dans un fichier hosts était considéré comme une mauvaise idée. si loin en arrière . Si vous avez plus de 10 entrées dans le vôtre, vous êtes probablement sur la mauvaise voie.