Das Auflösen auf einen virtuellen Host erfolgt unter Mac OS X Lion sehr langsam


26

Seit dem Upgrade auf Mac OS X Lion (von Snow Leopard) ist mir aufgefallen, dass das Auflösen auf einen virtuellen Host sehr langsam ist (zwischen ca. 3 Sekunden). Ich habe eine Reihe von Tipps gefunden (z. B. keine Verwendung der lokalen TLD), die das Problem möglicherweise beheben, sie gelten jedoch nicht für mein Setup.

Mein Setup ist recht einfach: - Apache 2 (im Lieferumfang von Lion enthalten) - PHP aktiviert - einige virtuelle Hosts hinzugefügt - Mail- und SMTP-Pear-Pakete installiert

Die Hosts-Datei von Apache sieht folgendermaßen aus:

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

Und die virtuelle Hosts-Datei von Apache sieht folgendermaßen aus:

<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>

Das Setup ist im Wesentlichen identisch mit meinem Setup auf Snow Leopard, aber die Leistung von Apache zum Auflösen virtueller Hosts ist erheblich unterschiedlich. Ich verwende Mac OS X Lion 10.7.2, aber das Problem war bereits beim Ausführen von 10.7.1 vorhanden.

Dies scheint ein kleines Problem zu sein, aber wenn Sie ein paar hundert Mal am Tag auf einen virtuellen Host zugreifen, bedeutet dies eine erhebliche Zeitverschwendung, wie Sie sich vorstellen können.


Ich sehe in der Problembeschreibung nichts, was gewöhnliche Probleme wie Systemlast, Netzwerkauslastung und Speicherauslastung ausgeschlossen hätte. Sie sagen, dass das Auflösen eines virtuellen Hosts langsam ist. Wovon? Der Host-Befehl oder das Anzeigen einer vom Server gelieferten Seite? Wenn es sich nur um DNS / Host handelt, können Sie die Leistung in der Befehlszeile wie folgt zeitlich festlegen: time host snd.dev
labradort

Antworten:


22

Lange DNS-Zeitüberschreitungen sind fast immer ein Zeichen für IPv6-Probleme.

Benötigen Sie IPv6-Konnektivität für Apache?

Wenn nicht, schlage ich vor, zu ändern

<VirtualHost *:80>

in

<VirtualHost 0.0.0.0:80>

Oder deaktivieren Sie die IPv6-Konnektivität vollständig.


3
+1: IPv6-DNS-Lookups sind unter OSX ein großes Problem. Aus irgendeinem unbekannten Grund führt OSX zuerst eine IPv6-Suche durch. Wenn das Zeitlimit überschritten wird (ca. 30 Sekunden), wird mit Version 4 fortgefahren. OSX scheint / etc / hosts nicht zuerst vor v6 zu prüfen, sondern erst nach Ablauf der Zeit für v4. Wenn Sie v6 nicht besser deaktivieren können, stellen Sie sicher, dass Sie ein voll funktionsfähiges v6-Setup einschließlich v6-DNS haben.
Tonny

Danke für die Antwort. Ich bin nicht sicher, ob dies das einzige Problem ist, das hier eine Rolle spielt, aber die Zeit, die zum Auflösen eines lokalen virtuellen Hosts benötigt wird, ist die meiste Zeit gesunken.
Bart Jacobs

Die DNS-Suche dauerte etwa 2-5 Sekunden, nicht 30 Sekunden. Ich bin mir also nicht sicher, was für ein Problem ich hatte, da dies wahrscheinlich keine Zeitüberschreitung darstellt. Unabhängig davon ist es jetzt sofort, da die Änderungen aus dieser Antwort vorgenommen wurden.
Justin

22

Ich bin auch gerade darauf gestoßen.

Dadurch wird IPv6 in der Netzwerkkonfiguration auf Aus gesetzt.

# 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

Aber leider konnte das Problem mit der DNS-Auflösung für mich nicht gelöst werden (möglicherweise nach einem Neustart des Systems). Was wirklich geholfen hat, war das Hinzufügen von IPs im IPv6-Stil zu / etc / hosts wie folgt:

# 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 wird jetzt sofort angezeigt

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

Anstatt 5 Sekunden bei Resolving project.local zu hängen.


Ihr Rat war alles, was ich brauchte - fügten Sie einfach die IPv6-Einträge neben dem Standard zu meiner Hosts-Datei hinzu, 127.0.0.1und das Problem wurde vollständig gelöst.
Kirk Woll

Yay! Dies hilft in OS X 10.8 (Mountain Lion). Nachdem ich von 10.6 direkt auf 10.8 aktualisiert hatte, stellte ich fest, dass meine lokalen Host-Suchvorgänge für immer zu lang waren ... als ob sie vor dem Lösen eine Zeitüberschreitung aufwiesen. Dies hat das Problem für mich behoben. Vielen Dank!
Lothar_Grimpsenbacher

Ich bin vor kurzem auf dieses Problem gestoßen und die IPv6-Einträge in / etc / hosts haben es perfekt behoben.
Neil Albrock

Das funktioniert jetzt für mich unter Max OS 10.10.1
ezmilhouse

10

Unter MacOSX wurde die Lion- .local Domain für Multicast-DNS-Resolver (bonjour) "reserviert".

Dies bedeutet, dass das Suchen von Domains, die mit .local enden, zu einer mDNS-Suche (bis zu 5 Sekunden) vor / etc / hosts führt.

Korrekturen:

  1. Ändern Sie Ihre Testdomains auf eine andere TLD (dh .dev)
  2. Verwenden Sie das Tool dscl , um eine Ausnahme hinzuzufügen.

Arbeitete auch für mich ... machte mich verrückt, dass nur einige meiner Entwickler-Sites dies taten ... leise und siehe da ... all die, die mit .local enden! das passierte mir erst, als ich auf High Sierra umgestiegen
bin

1
dsclAusnahmestrategie ist ziemlich geschickt. @ artur-bodera dein link ist abgelaufen, aber sie haben ihren alten blog auf github github.com/icebourg/itandme-archive/blob/master/posts/2011/08/…
lkraav

Beachten Sie auch, dass .local ein vorgeschlagener Standard für die IETF ist: tools.ietf.org/html/rfc6762 Es ist auch eine gute Idee, nur einen Domainnamen zu registrieren, wenn Sie eine "Test" -Domain benötigen, da Sie die volle Kontrolle darüber haben, wie sie ist in DNS konfiguriert. Es ist sehr wahrscheinlich, dass die Erstellung eines Domainnamens zu seltsamen Konflikten mit anderen Teilen des Domain-Systems führt (wie in diesem Fall mDNS.)
James Tikalsky,

3

Schauen Sie sich diesen Blog an, um zu sehen, ob er hilft, und heben Sie insbesondere Problem 2 hervor:

Anscheinend verwenden das Terminal und einige der BSD-Unix-Tools /etc/resolv.conf und die richtige Reihenfolge von / etc / hosts zuerst und dann DNS-Servern. Alles andere unter OS X Lion, einschließlich aller Ihrer Anwendungen, funktioniert jedoch rückwärts!


1

Es klappt.

Ich benutze diese Lösung

##
# 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

Gleicher Bug bei Mavericks.

Behoben, wenn ich meine lokalen Hosts-Definitionen an den Anfang von setze /etc/hosts:

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

Ich würde versuchen zu ändern:

::1             localhost 
fe80::1%lo0 localhost

zu

::1             localhost6 
fe80::1%lo0 localhost6

1
Leider löst dies das Problem nicht. Können Sie sagen, welche Logik hinter Ihrem Vorschlag steckt? Vielen Dank für Ihre Antwort.
Bart Jacobs

Ich habe kürzlich übermäßig lange um snmp-Antworten von Rechnern gekämpft, auf denen IPV6 nicht ausgeführt wird, die aber ähnliche Einträge in / etc / hosts haben. Das andere, was mir in den Sinn kommt, ist ein Nameserver-Timing-Out - allerdings etwas merkwürdig, da Hosts Vorrang vor Bind haben sollten. (Natürlich konfigurierbar).
Alien Life Form

Sehr merkwürdig. In einigen Fällen erfolgt die Auflösung auf einen Host sofort (wie erwartet), in anderen Fällen kann dies mehrere Sekunden dauern.
Bart Jacobs
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.