Résolution sur l'hôte virtuel très lente sur Mac OS X Lion


26

Depuis la mise à niveau vers Mac OS X Lion (à partir de Snow Leopard), j'ai remarqué que la résolution vers un hôte virtuel est très lente (entre environ 3 secondes). J'ai trouvé un certain nombre de conseils (par exemple, ne pas utiliser le TLD .local) qui pourraient résoudre ce problème, mais ils ne s'appliquent pas à ma configuration.

Ma configuration est assez simple: - Apache 2 (livré avec Lion) - PHP activé - ajouté quelques hôtes virtuels - Mail et SMTP Pearson installés

Le fichier hosts d'Apache ressemble à ceci:

127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost 
fe80::1%lo0 localhost
127.0.0.1   tbi.dev
127.0.0.1   www.tbi.dev
127.0.0.1   test1.tbi.dev
127.0.0.1   test2.tbi.dev
127.0.0.1   psa.dev
127.0.0.1   snd.dev

Et le fichier des hôtes virtuels d'Apache ressemble à ceci:

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/tbi"
    ServerName tbi.dev
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/tbi"
    ServerName tbi.dev
    ServerAlias *.tbi.dev www.tbi.dev
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/psa"
    ServerName psa.dev
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/Bart/Sites/sandbox"
    ServerName snd.dev
</VirtualHost>

La configuration est fondamentalement identique à ma configuration sur Snow Leopard, mais les performances d'Apache pour la résolution des hôtes virtuels sont considérablement différentes. J'exécute Mac OS X Lion 10.7.2, mais le problème était déjà présent lors de l'exécution de 10.7.1.

Cela peut sembler être un petit problème, mais lorsque vous accédez à des hôtes virtuels plusieurs centaines de fois par jour, cela représente une perte de temps considérable, comme vous pouvez l'imaginer.


Je ne vois rien dans la description du problème qui a exclu des problèmes ordinaires comme la charge du système, l'utilisation du réseau, l'utilisation de la mémoire. Vous dites que la résolution d'un hôte virtuel est lente. D'où? La commande hôte, ou l'affichage d'une page servie par le serveur? S'il est purement lié à DNS / hôte, vous pouvez chronométrer les performances comme ceci sur la ligne de commande: time host snd.dev
labradort

Réponses:


22

Les longs délais d'attente DNS sont presque toujours un signe de problèmes IPv6.

Avez-vous besoin d'une connectivité IPv6 pour apache?

Sinon, je suggère de changer

<VirtualHost *:80>

dans

<VirtualHost 0.0.0.0:80>

Ou désactivez complètement la connectivité IPv6.


3
+1: Les recherches DNS ipv6 sont un problème majeur sur OSX. Pour une raison obscure, OSX commence par rechercher ipv6. Si cela arrive à expiration (environ 30 secondes), il continuera avec la v4. OSX ne semble pas vérifier / etc / hosts d'abord vor v6, il le fait pour v4, mais seulement après expiration du délai pour v6. Si vous ne pouvez pas désactiver la v6, assurez-vous que votre configuration v6 fonctionne correctement, y compris la v6 DNS.
Tonny

Merci d'avoir répondu. Je ne sais pas si c'est le seul problème qui joue un rôle ici, mais le temps nécessaire pour résoudre un hôte virtuel local a chuté la plupart du temps.
Bart Jacobs

Ma recherche DNS prenait environ 2 à 5 secondes à résoudre, pas 30. Donc, je ne sais pas quel était mon problème car il est peu probable que ce soit un délai d'attente. Quoi qu'il en soit, c'est maintenant instantané depuis que vous avez apporté les modifications à partir de cette réponse.
Justin

22

Je suis tombé sur ça tout à l'heure aussi.

Cela définira IPv6 dans la configuration du réseau sur Désactivé ...

# list all network interfaces to get their names
networksetup -listallnetworkservices
# disable the one you want, in my case it's WiFi
networksetup -setv6off Wi-Fi

Mais .. malheureusement, cela n'a pas résolu le problème de résolution DNS pour moi (peut-être après le redémarrage du système). Ce qui a vraiment aidé, c'était d'ajouter des IP de style ipv6 à / etc / hosts comme ceci:

# my original /etc/hosts ...
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1             localhost 
fe80::1%lo0 localhost

127.0.0.1 project.local

# adding this solved resolving:
fe80::1%lo0 project.local

wget http: //project.local s'affiche maintenant instantanément

Resolving project.local... 127.0.0.1
Connecting to project.local|127.0.0.1|:80... connected.

au lieu de suspendre pendant 5 secondes sur Resolving project.local.


Vos conseils étaient tout ce dont j'avais besoin - je viens d'ajouter les entrées IPv6 à mon fichier d'hôtes aux côtés de la norme 127.0.0.1et le problème a été complètement résolu.
Kirk Woll

Yay! Cela aide dans OS X 10.8 (Mountain Lion). Après la mise à niveau de 10.6 directement vers 10.8, j'ai trouvé mes recherches d'hôte local trop éternellement ... comme si elles expiraient avant la résolution. Cela a résolu le problème pour moi. Merci!
Lothar_Grimpsenbacher

J'ai rencontré ce problème récemment et les entrées IPv6 dans / etc / hosts l'ont parfaitement corrigé.
Neil Albrock

ça, ça marche maintenant pour moi sur Max OS 10.10.1
ezmilhouse

10

Sur MacOSX, le .local domaine Lion a été "réservé" au résolveur DNS multidiffusion (bonjour).

Cela signifie que la recherche de tout domaine se terminant par .local entraînera une recherche mDNS (jusqu'à 5 s) avant / etc / hosts.

Correctifs:

  1. Modifiez vos domaines de test en un autre TLD (par exemple .dev)
  2. Utilisez l'outil dscl pour ajouter une exception.

Cela a aussi fonctionné pour moi ... me rendait fou que seuls quelques-uns de mes sites de développement l'ont fait ... bas et voici ... tous ceux qui se terminent par .local! cela n'a pas commencé à m'arriver jusqu'à ce que je passe à High Sierra ... grâce à @artur
Mfoo

1
dsclla stratégie d'exception est assez astucieuse. @ artur-bodera votre lien a expiré, mais ils ont archivé leur ancien blog sur github github.com/icebourg/itandme-archive/blob/master/posts/2011/08/…
lkraav

Notez également que .local est une norme proposée avec l'IETF: tools.ietf.org/html/rfc6762 C'est aussi une très bonne idée de simplement enregistrer un nom de domaine si vous avez besoin d'un domaine "test", puisque vous obtenez un contrôle total sur la façon dont il configuré dans DNS. La création d'un nom de domaine est très susceptible de provoquer des conflits étranges avec d'autres parties du système de domaine (comme mDNS dans ce cas.)
James Tikalsky

3

Jetez un oeil à ce blog pour voir si cela aide, en mettant particulièrement en évidence le problème # 2:

Apparemment, le terminal et certains des outils BSD Unix utilisent correctement /etc/resolv.conf et l'ordre correct de / etc / hosts d'abord, puis les serveurs DNS. Cependant, tout le reste sur OS X Lion, y compris toutes vos applications, faites-le à l'envers!


1

Ça marche.

J'utilise cette solution

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost
255.255.255.255 broadcasthost
::1             localhost6
fe80::1%lo0 localhost

1

Même bug sur Mavericks.

Résolu lorsque je mets mes définitions d'hôtes locaux au début de /etc/hosts, comme ceci:

127.0.0.1 localhost project1.dev project2.dev
127.0.0.1 project3.dev project4.dev
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0     localhost

0

J'essaierais de changer:

::1             localhost 
fe80::1%lo0 localhost

à

::1             localhost6 
fe80::1%lo0 localhost6

1
Malheureusement, cela ne résout pas le problème. Pouvez-vous dire quelle est la logique derrière votre suggestion? Merci pour votre réponse.
Bart Jacobs

J'ai récemment combattu des temps excessivement longs pour les réponses snmp des machines n'utilisant pas IPV6 mais ayant des entrées similaires dans / etc / hosts. Maintenant, ce qui me vient à l'esprit, c'est un temporisation du serveur de noms - un peu étrange cependant, car les hôtes devraient avoir la priorité sur bind. (Configurablement, bien sûr).
Formulaire Alien Life

Très étrange en effet. Parfois, la résolution à un hôte est instantanée (comme on s'y attend) et dans d'autres, cela peut prendre plusieurs secondes.
Bart Jacobs,
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.