Risoluzione dell'host virtuale molto lenta su Mac OS X Lion


26

Dall'aggiornamento a Mac OS X Lion (da Snow Leopard), ho notato che la risoluzione su un host virtuale è molto lenta (tra circa 3 secondi). Ho trovato una serie di suggerimenti (ad esempio, non usando il TLD .local) che potrebbero risolvere questo problema, ma non si applicano alla mia configurazione.

La mia configurazione è abbastanza semplice: - Apache 2 (fornito con Lion) - abilitato PHP - aggiunti alcuni host virtuali - installati pacchetti Posta e SMTP Pear

Il file hosts di Apache è simile al seguente:

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

E il file degli host virtuali di Apache è simile al seguente:

<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 configurazione è sostanzialmente identica alla mia configurazione su Snow Leopard, ma le prestazioni di Apache per la risoluzione di host virtuali sono significativamente diverse. Corro Mac OS X Lion 10.7.2, ma il problema era già presente durante l'esecuzione di 10.7.1.

Questo potrebbe sembrare un piccolo problema, ma quando accedi a host virtuali alcune centinaia di volte al giorno, ciò si traduce in una significativa perdita di tempo, come puoi immaginare.


Non vedo nulla nella descrizione del problema che abbia escluso problemi ordinari come il caricamento del sistema, l'utilizzo della rete, l'utilizzo della memoria. Dici che la risoluzione di un host virtuale è lenta. Da dove? Il comando host o la visualizzazione di una pagina servita dal server? Se è puramente correlato a DNS / host, puoi cronometrare le prestazioni in questo modo sulla riga di comando: time host snd.dev
labradort,

Risposte:


22

I timeout DNS lunghi sono quasi sempre un segno di problemi IPv6.

Hai bisogno della connettività IPv6 per apache?

In caso contrario, suggerisco di cambiare

<VirtualHost *:80>

in

<VirtualHost 0.0.0.0:80>

O disabilitare del tutto la connettività IPv6.


3
+1: le ricerche DNS ipv6 sono un grave problema su OSX. Per qualche oscura ragione, OSX prima cerca ipv6. In tal caso (30 secondi circa) continuerà con v4. OSX non sembra controllare prima / etc / hosts prima di v6, ma per v4, ma solo dopo il timeout di v6. Se non riesci a disabilitare v6, assicurati di avere una configurazione v6 completamente funzionante, incluso DNS v6.
Tonny

Grazie per la risposta. Non sono sicuro che questo sia l'unico problema che sta svolgendo un ruolo qui, ma il tempo necessario per risolvere un host virtuale locale è diminuito la maggior parte del tempo.
Bart Jacobs,

La mia ricerca DNS stava impiegando circa 2-5 secondi per risolversi, non 30. Quindi, non sono sicuro di quale fosse il mio problema poiché è improbabile che sia un timeout. Indipendentemente da ciò, ora è istantaneo da quando ho apportato le modifiche a questa risposta.
Giustino,

22

Mi sono imbattuto anche in questo.

Questo imposterà IPv6 nella configurazione di rete su Off ...

# 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

Ma .. sfortunatamente questo non ha risolto il problema di risoluzione DNS per me (forse dopo il riavvio del sistema). Ciò che ha davvero aiutato è stato l'aggiunta di IP in stile ipv6 a / etc / hosts in questo modo:

# 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 ora mostra istantaneamente

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

invece di rimanere in sospeso per 5 secondi su Resolving project.local.


Il tuo consiglio era tutto ciò di cui avevo bisogno: ho appena aggiunto le voci IPv6 al mio file hosts insieme allo standard 127.0.0.1e il problema è stato completamente risolto.
Kirk Woll,

Sìì! Questo aiuta in OS X 10.8 (Mountain Lion). Dopo l'aggiornamento dalla 10.6 direttamente alla 10.8 ho trovato le ricerche dei miei host locali troppo per sempre ... come se stessero scadendo prima di risolversi. Ciò ha risolto il problema per me. Grazie!
Lothar_Grimpsenbacher,

Di recente ho riscontrato questo problema e le voci IPv6 in / etc / hosts lo hanno risolto perfettamente.
Neil Albrock,

questo funziona, funziona ora per me su Max OS 10.10.1
ezmilhouse

10

Su MacOSX Lion il .local dominio è stato "riservato" per Multicast DNS Resolver (bonjour).

Ciò significa che la ricerca di qualsiasi dominio che termina con .local comporterà la ricerca mDNS (fino a 5 secondi) prima di / etc / hosts.

correzioni:

  1. Cambia i tuoi domini di prova in altri TLD (es. .dev)
  2. Utilizzare lo strumento dscl per aggiungere un'eccezione.

Ha funzionato anche per me ... mi stava facendo impazzire che solo alcuni dei miei siti di sviluppo hanno fatto questo ... basso ed ecco ... tutti quelli che finiscono in .local! questo non ha cominciato a succedere a me fino a quando non ho effettuato l'aggiornamento a High Sierra ... grazie a @artur
Mfoo,

1
dsclla strategia delle eccezioni è piuttosto ingegnosa. @ artur-bodera il tuo link è scaduto, ma hanno archiviato il loro vecchio blog su github github.com/icebourg/itandme-archive/blob/master/posts/2011/08/…
lkraav

Nota anche che .local è uno standard proposto con IETF: tools.ietf.org/html/rfc6762 È anche una buona idea registrare semplicemente un nome di dominio se hai bisogno di un dominio "test", dato che hai il pieno controllo di come è configurato in DNS. È molto probabile che creare un nome di dominio provochi strani conflitti con altre parti del sistema di dominio (come mDNS in questo caso.)
James Tikalsky,

3

Dai un'occhiata a questo blog per vedere se aiuta, evidenziando in particolare il problema n. 2:

Apparentemente, il terminale e alcuni degli strumenti Unix BSD usano correttamente /etc/resolv.conf e prima l'ordine corretto di / etc / hosts e poi i server DNS. Tuttavia, tutto il resto su OS X Lion, comprese tutte le tue applicazioni, fallo all'indietro!


1

Funziona.

Uso questa soluzione

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

Lo stesso bug su Mavericks.

Risolto quando ho messo le definizioni dei miei host locali all'inizio di /etc/hosts, in questo modo:

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

Proverei a cambiare:

::1             localhost 
fe80::1%lo0 localhost

a

::1             localhost6 
fe80::1%lo0 localhost6

1
Sfortunatamente, questo non risolve il problema. Puoi dire qual è la logica dietro il tuo suggerimento? Grazie per la tua risposta però.
Bart Jacobs,

Di recente ho combattuto tempi straordinariamente lunghi per le risposte snmp da macchine che non eseguono IPV6 ma che hanno voci simili in / etc / hosts. Ora la cosa che viene in mente è un timeout del nameserver - un po 'strano, perché gli host dovrebbero avere la precedenza sul bind. (Configurabile, ovviamente).
Alien Life Form,

Davvero molto strano. A volte, la risoluzione in un host è istantanea (come ci si aspetta) e in altre può richiedere diversi secondi.
Bart Jacobs,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.