Resolviendo al host virtual muy lento en Mac OS X Lion


26

Desde la actualización a Mac OS X Lion (desde Snow Leopard), he notado que la resolución a un host virtual es muy lenta (entre aproximadamente 3 segundos). He encontrado una serie de consejos (p. Ej., No usar el .local TLD) que podrían resolver esto, pero no se aplican a mi configuración.

Mi configuración es bastante simple: - Apache 2 (incluido con Lion) - PHP habilitado - Agregué algunos hosts virtuales - Paquetes de correo y SMTP Pear instalados

El archivo de hosts de Apache se ve así:

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

Y el archivo de hosts virtuales de Apache se ve así:

<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 configuración es básicamente idéntica a mi configuración en Snow Leopard, pero el rendimiento de Apache para resolver hosts virtuales es significativamente diferente. Ejecuté Mac OS X Lion 10.7.2, pero el problema ya estaba presente al ejecutar 10.7.1.

Esto puede parecer un problema pequeño, pero cuando accede a un host virtual unos cientos de veces al día, esto se suma a una pérdida de tiempo significativa como puede imaginar.


No veo nada en la descripción del problema que haya descartado problemas comunes como la carga del sistema, la utilización de la red, la utilización de la memoria. Dices que resolver un host virtual es lento. ¿De donde? ¿El comando del host, o está viendo una página servida por el servidor? Si se trata únicamente de DNS / host, puede cronometrar el rendimiento de esta manera en la línea de comando: time host snd.dev
labradort

Respuestas:


22

Los largos tiempos de espera de DNS son casi siempre una señal de problemas de IPv6.

¿Necesita conectividad IPv6 a apache?

Si no, sugiero cambiar

<VirtualHost *:80>

dentro

<VirtualHost 0.0.0.0:80>

O deshabilite la conectividad IPv6 por completo.


3
+1: las búsquedas de DNS ipv6 son un problema importante en OSX. Por alguna oscura razón, OSX primero busca ipv6. Si se agota el tiempo de espera (aproximadamente 30 segundos), continuará con v4. OSX no parece comprobar / etc / hosts primero vor v6, lo hace para v4, pero solo después de que v6 haya expirado. Si no puede deshabilitar v6, asegúrese de tener una configuración de v6 que funcione completamente, incluido v6 DNS.
Tonny

Gracias por la respuesta. No estoy seguro de si este es el único problema que desempeña un papel aquí, pero el tiempo que lleva resolver un host virtual local se ha reducido la mayor parte del tiempo.
Bart Jacobs el

Mi búsqueda de DNS tardó entre 2 y 5 segundos en resolverse, no 30. Por lo tanto, no estoy seguro de cuál fue mi problema, ya que es poco probable que sea un tiempo de espera. De todos modos, ahora es instantáneo desde que realizó los cambios a partir de esta respuesta.
Justin

22

Me he encontrado con esto justo ahora también.

Esto establecerá el IPv6 en la configuración de red en Apagado ...

# 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

Pero ... desafortunadamente esto no resolvió el problema de resolución de DNS para mí (tal vez después de reiniciar el sistema). Lo que realmente ayudó fue agregar IP de estilo ipv6 a / etc / hosts de esta manera:

# 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 ahora se muestra al instante

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

en lugar de colgar durante 5 segundos en Resolving project.local.


Su consejo fue todo lo que necesitaba: solo agregué las entradas de IPv6 a mi archivo de hosts junto con el estándar 127.0.0.1y el problema se resolvió por completo.
Kirk Woll

¡Hurra! Esto ayuda en OS X 10.8 (Mountain Lion). Después de actualizar de 10.6 directamente a 10.8, encontré mis búsquedas de host local demasiado para siempre ... como si estuvieran agotando el tiempo de espera antes de resolverse. Esto solucionó el problema para mí. ¡Gracias!
Lothar_Grimpsenbacher

Encontré este problema recientemente y las entradas de IPv6 en / etc / hosts lo arreglaron perfectamente.
Neil Albrock

esto, ahora funciona para mí en Max OS 10.10.1
ezmilhouse

10

En MacOSX, el .local dominio Lion ha sido "reservado" para la resolución DNS de multidifusión (bonjour).

Esto significa que buscar cualquier dominio que termine con .local dará como resultado una búsqueda de mDNS (hasta 5s) antes de / etc / hosts.

Arreglos:

  1. Cambie sus dominios de prueba a otro TLD (es decir .dev)
  2. Use la herramienta dscl para agregar una excepción.

También funcionó para mí ... me estaba volviendo loco que solo unos pocos de mis sitios de desarrollo hicieran esto ... bajo y he aquí ... ¡todos los que terminan en .local! Esto no comenzó a sucederme hasta que actualicé a High Sierra ... gracias a @artur
Mfoo

1
dsclLa estrategia de excepción es bastante ingeniosa. @ artur-bodera su enlace ha expirado, pero archivaron su antiguo blog en github github.com/icebourg/itandme-archive/blob/master/posts/2011/08/…
lkraav el

Tenga en cuenta también que .local es un estándar propuesto con el IETF: tools.ietf.org/html/rfc6762 También es realmente una buena idea registrar un nombre de dominio si necesita un dominio de "prueba", ya que obtiene el control total de cómo funciona. configurado en DNS. Es muy probable que inventar un nombre de dominio cause conflictos extraños con otras partes del sistema de dominio (como mDNS en este caso)
James Tikalsky

3

Echa un vistazo a este blog para ver si te ayuda, destacando específicamente el problema # 2:

Aparentemente, el terminal y algunas de las herramientas BSD Unix usan correctamente /etc/resolv.conf y el orden correcto de / etc / hosts primero y luego los servidores DNS. Sin embargo, todo lo demás en OS X Lion, incluidas todas sus aplicaciones, ¡lo hacen al revés!


1

Funciona.

Yo uso esta solucion

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

El mismo error en Mavericks.

Se resolvió cuando puse mis definiciones de hosts locales al principio de /etc/hosts, así:

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

Intentaría cambiar:

::1             localhost 
fe80::1%lo0 localhost

a

::1             localhost6 
fe80::1%lo0 localhost6

1
Desafortunadamente, esto no resuelve el problema. ¿Puedes decir cuál es la lógica detrás de tu sugerencia? Gracias de todos modos por tu respuesta.
Bart Jacobs

Recientemente luché mucho tiempo por respuestas snmp de máquinas que no ejecutan IPV6 pero que tienen entradas similares en / etc / hosts. Ahora, lo que viene a la mente es un tiempo de espera del servidor de nombres, aunque un poco extraño, porque los hosts deberían tener prioridad sobre el enlace. (Configurable así, por supuesto).
Alien Life Form

Muy extraño de hecho. En ocasiones, resolver a un host es instantáneo (como uno espera) y en otros puede tomar varios segundos.
Bart Jacobs
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.