Limite de taille de / etc / hosts (Linux)

11

Quelqu'un sait-il quelle est la taille limite théorique de / etc / hosts sur un système Linux avant que vous ne constatiez une dégradation des performances?

De plus, quelqu'un peut-il me diriger vers une source officielle qui indique quelle est la limite attendue?

linux hosts

— MikeP90
source

8

Cela me fait penser que vous faites quelque chose de fou ou bien en dehors des meilleures pratiques. Quels sont les détails?

— ewwhite

3

Bien sûr, le déploiement d'un résolveur DNS léger pourrait être une meilleure solution ici.

— Zoredache

1

J'ai un client qui en fait la demande. J'espérais trouver de la documentation que je pourrais leur montrer pourquoi cela causerait des problèmes; au lieu de devoir l'essayer sur une machine de test et de le démontrer.

— MikeP90

1

Le fichier hosts est une relique des jours pré-DNS des années 1970 et du début des années 1980. Avoir des centaines d'entrées dans un fichier hosts a été reconnu comme une mauvaise idée si loin . Si vous avez plus de 10 entrées dans la vôtre, vous êtes probablement sur la mauvaise voie.

— Michael Hampton

9

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. Ainsi, en l'absence de capacité de mise en cache supplémentaire, le coût des recherches sera O (n). Quant à savoir quand cela entraînera une dégradation des performances, c'est une question impossible à répondre - cela devient plus lent à chaque enregistrement.

Si vous parlez à un programmeur ou à un administrateur de base de données, vous obtiendrez des chiffres différents pour le moment où une recherche d'index (O (log2 (n)) est moins chère qu'une analyse de table complète, mais généralement la réponse sera de l'ordre de 20 à 100 enregistrements.

Tout système Linux nécessitant de résoudre un grand nombre de noms (pas seulement les noms d'hôte). Doit exécuter nscd ou similaire. La plupart de ces caches indexeront les données elles-mêmes, ce qui annulerait la question des performances, cependant ...

Il ne fournit aucun moyen de gérer des ensembles de données complexes / volumineux - si vous avez un hôte avec plusieurs adresses IP, les recherches via le fichier hosts renverront toujours la première entrée.

— symcbean
source

1

Pour fermer la boucle, nous avons ajouté 1,7 million d'enregistrements au fichier hosts et avons estimé qu'il ajoutait 0,5 seconde à chaque recherche. Dans cet environnement, 0,5 seconde est négligeable. Je pense qu'un serveur DNS est toujours une meilleure solution, mais le client veut ce qu'il veut.

— MikeP90

5

Un peu d'histoire sur Internet - avant le déploiement de DNS en 1984, le fichier hosts était le seul à 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 y a des copies de HOSTS.TXT (non lisible par machine, cependant) de 1982 dans les archives du mailliste de l'histoire d'Internet . Il y avait même un HOSTS.TXT alternatif (Geoff Goodfellow's) .

— sendmoreinfo
source

3

Techniquement, il n'y a pas de limite supérieure. Cependant, chaque recherche DNS va frapper ce fichier, alors pourquoi vous y laisser ouvert?

Pour ce que ça vaut, le plus gros /etc/hostsfichier que j'ai distribué dans mes environnements était de 1 200 lignes. Et cela a bien fonctionné pour l'application que je gérais. DNS n'était pas une option dans cet environnement particulier.

— ewwhite
source

Mettons les choses autrement. S'il n'y a pas d'indexation dans le noyau, chaque hit fera une recherche linéaire qui dépendra de la taille du cache en ce qui concerne le timing.

— Deer Hunter

4

J'utilise un fichier d'hôtes populaire trouvé sur Internet, il y a 15 430 lignes et je ne constate aucune dégradation réelle des performances de navigation sur le Web.

— Bert

@DeerHunter Je ne pense pas qu'il y ait quoi que ce soit dans le noyau Unix qui effectue une recherche de nom d'hôte.

— Barmar

+1 à la note de Bert. Je viens d'utiliser un fichier personnalisé avec 22 000 lignes et cela n'a pas affecté les performances. Ceci est utile à des fins de test!

— Josh koenig