9 votos

¿Cómo evitar que mDNSResponder utilice el 90-100% de la CPU continuamente en Catalina?

Acabo de actualizar mi MacBook Pro de 15" de 2018 de Mojave a Catalina (10.15.4). Han pasado unas horas.

Una de las primeras cosas que hice tras la actualización fue editar un vídeo con la nueva versión de prueba gratuita de Final Cut Pro X. Los ventiladores de mi portátil funcionaban a toda velocidad todo el tiempo, pero siempre había renderización de fondo, así que supuse que era normal.

Cuando terminé y salí de FCP, los ventiladores no giraron, así que revisé el Monitor de Actividad y descubrí que mDNSResponder está tomando el 90-100% de la CPU continuamente. La columna de hilos en el Monitor de Actividad indica 3-4 hilos la mayor parte del tiempo; el 100% se reparte entre todos ellos, y no están todos en el mismo núcleo. No estoy seguro de cómo se las arregla para hacer eso y seguir sentado en o justo por debajo del 100% la mayor parte del tiempo, pero eso es lo que está haciendo.

screenshot of Activity Monitor

El portátil tiene seis núcleos (12 lógicos), por lo que tener un núcleo totalmente ocupado no supone una diferencia notable en el rendimiento (a no ser que empiece a medir lo que tardan las cosas, pero eso es notar que los números son diferentes, ¡no que el rendimiento sea diferente!)

Nota: En el conjunto, los gráficos de barras muestran la utilización de más de un núcleo completo. Esto es de esperar. Tengo una búsqueda aplicada en mi captura de pantalla del Monitor de Actividad, y hay un montón de otras cosas en marcha - Slack está abierto, Chrome con oncecientos millones de pestañas, IntelliJ IDEA probablemente está indexando algo, y así sucesivamente.

Intenté reiniciar mDNSResponder usando estos comandos:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

He visto desaparecer el proceso, así que sé que el comando ha funcionado, pero inmediatamente ha vuelto a utilizar el 100% de la CPU cuando lo he vuelto a iniciar. mDNSResponderHelper no se detuvo, así que lo intenté de nuevo, insertando sudo killall mDNSResponderHelper como paso intermedio. Esto hizo que ambos procesos desaparecieran como pretendía, pero siguió sin solucionar el problema.

También intenté enviar una señal HUP a mDNSResponder de la siguiente manera:

sudo killall -HUP mDNSResponder

Esto tampoco tuvo ningún efecto.

Abrí la Consola, introduje mdnsresponder en el campo de búsqueda, y observé los mensajes durante uno o dos minutos. Algunas cosas sobre Bonjour, MUCHAS <private> y un registro de consultas DNS de aspecto bastante normal. Intenté desactivar tanto el Bluetooth como el Wifi con la esperanza de que afectara a Bonjour, pero estoy en una conexión Ethernet por cable (que no desconecté) y no pareció tener ningún efecto.

Después de escribir esto, me di cuenta de que cloudphotosd también estaba ocupando una buena parte de la CPU. Supuse que se trataba del famoso proceso de reindexación que ocurre con frecuencia después de las actualizaciones del sistema operativo, revisando mi (bastante grande) biblioteca de fotos, actualizando los metadatos en base a las nuevas características que vienen con Catalina, y subiendo esos cambios a iCloud. Eso explicaría alguna actividad constante en la red, y entonces pensé que tal vez eso explicaría la actividad de mDNSResponder. Así que dejé esta ventana abierta sin enviar y esperé un rato para ver si cloudphotosd se calmaba. Lo hizo, pero mDNSResponder no. Hasta aquí la corazonada.

Finalmente, probé a reiniciar mi Mac; mDNSResponder no perdió tiempo en volver a funcionar. Sin ninguna aplicación en marcha después de un nuevo arranque, ya estaba constantemente sentado en o justo por debajo del 100%, al igual que antes.

Este es un sitio de preguntas y respuestas, y no he hecho ninguna pregunta, así que aquí va: ¿cómo puedo averiguar qué está haciendo y cómo puedo hacer que deje de hacerlo?

ACTUALIZACIÓN: ya han pasado casi 48 horas y sigue funcionando. La vida de mi batería es una mierda ahora. He observado que cerrar la tapa del portátil parece hacer que se detenga, pero vuelve enseguida cuando la abro de nuevo. También he notado un síntoma adicional: las primeras búsquedas de DNS después de un reinicio tardan ~2 segundos (yo esperaría <200ms). No estoy seguro de si eso es simplemente un efecto secundario de mDNSResponder estar tan ocupado haciendo lo que sea que está haciendo o si está relacionado con la causa.

ACTUALIZACIÓN 2: han pasado más de tres semanas. He añadido una recompensa de 100 puntos. El retraso en la búsqueda de DNS ha aumentado; a menudo tarda entre 20 y 30 segundos, y aunque parece que hay algo de caché, creo que tiene una caducidad basada en el tiempo, porque el retraso vuelve a producirse más tarde sin reiniciar. Estoy encantado de interactuar directamente con alguien con conocimientos suficientes para depurar y diagnosticar este problema. Estoy en el horario de verano de los Estados Unidos (UTC-4) y generalmente estoy disponible durante las horas de trabajo.

2voto

bdonlan Puntos 508

Esta es mi recomendación:

  1. Veamos qué es mDNSResponder está haciendo realmente . Aquí hay una utilidad para desactivar/activar la censura detrás del <private> etiqueta. Asegúrate de volver a encenderlo una vez que hayas terminado. Es posible que encuentres algo como que el proceso se cuelga de algo y hace un bucle continuo, o algo así. https://georgegarside.com/blog/MacOS/sierra-console-private/

  2. Obtenga una captura de paquetes de su red mientras realiza una solicitud de DNS. Tome Wireshark Si no lo hace, inicie una captura en la interfaz que está utilizando (ya sea ethernet o WiFi; pero asegúrese de que la(s) que no está utilizando está(n) apagada(s)/desenchufada(s)). Yo haría esto primero en el entorno en el que tarda 20-30s, y luego de nuevo después de un reinicio cuando las condiciones son tales que sólo tarda 2-3s. Cuanto menos puedas tener usando la red, mejor mientras ejecutas estas capturas de paquetes, ya que se harán grandes rápidamente. Esto debería mostrarnos la solicitud de DNS, así como las solicitudes hacia y desde los propios sitios web, para que podamos ver dónde están los retrasos. Si no hay retrasos en la red, entonces miraríamos los procesos en su lugar.

  3. Sube las partes relevantes de los registros y/o la(s) captura(s) de paquetes a algún lugar para que las veamos. Asegúrate de censurar o eliminar cualquier dato privado.

  4. Y, por último, ten en cuenta que esto puede resolverse más rápidamente haciendo una reinstalación del sistema operativo en el lugar. Eso puede oponerse a sus opiniones sobre poder para arreglar su equipo, sabiendo lo que pasa con su equipo, etc., pero si el objetivo es que mDNSResolver vuelva a la cordura lo más rápido posible, una reinstalación del SO en el lugar puede ser el camino más rápido hacia allí.

EDITAR: He podido recrear el problema y capturar el tráfico de red relacionado. Muchas secciones de RFC 6762 (DNS multidifusión) parecen relevantes - no voy a publicar extractos aquí, pero específicamente encontré partes de las secciones 3, 5, 5.2 y 10.2, muy relevantes.

Esto es lo que creo que está pasando.

Al crear estos alias lo0, el tráfico se genera constantemente con una bandera "cache flush". El RFC no entra en suficiente detalle para que yo pueda estar seguro, pero parece que cada una de las direcciones loopback se anuncian como el que puede responder a las consultas realizadas al nombre de host de la máquina, por lo que los dispositivos de escucha deben vaciar sus cachés internas y actualizarlas con la nueva dirección IP.

Piénsalo, si la red cree que eres hostname.local en 192.168.44.111 y tu dirección IP cambia, el mDNS emitirá un mensaje de "vaciar tus cachés", hostname.local es ahora 192.168.44.123 !" en 224.0.0.251 . Esta es una circunstancia en la que mDNS anunciará proactivamente una nueva IP, y es la razón por la que la navegación en red funciona tan bien, es decir, las impresoras en red según el RFC.

Lo que no tiene mucho sentido para mí, es que hay partes de la RFC que me hacen pensar que múltiples direcciones loopback activas en la misma máquina no estarían haciendo spam de la forma en que lo hacen - pero entonces puede que no esté entendiendo bien la RFC. En cualquier caso, me parece claro que la mDNSResponder proceso es un bucle a través de cada interfaz de bucle de retorno y decirle a todos en 224.0.0.251 para no tener en cuenta al último que se hizo cargo, este ¡es la nueva dirección IP asignada a mi nombre de host!

No tengo muy claro por qué esto ralentiza las consultas regulares de DNS, excepto si mDNSResponder es responsable de enviar y recibir las consultas DNS regulares, bueno, está atado en todo este sinsentido con las otras interfaces. Y/o, tal vez las consultas DNS salgan y vuelvan a entrar en cualquier interfaz que se haya hecho cargo del nombre de host más recientemente. Eso, podría ver realmente causando retrasos, porque en el tiempo que una solicitud de DNS a través de la WAN vuelve, la interfaz loopback que responde sería diferente de la que salió. Pero en este momento sólo estoy haciendo conjeturas.

Además, en lugar de tener que reiniciar, puedes cambiar ligeramente tu script. Si ifconfig lo0 alias "$ADDR" up se utilizó para hacer aparecer un nuevo alias de interfaz, entonces ifconfig lo0 -alias "$ADDR" se puede utilizar para bajarlo.

-2voto

Protocol96 Puntos 6

Puede tratarse de muchas cosas, pero todas ellas implican el uso remoto/compartido a través de Internet.

¿Tienes activadas las funciones de compartir pantalla, inicio de sesión remoto, gestión remota, compartir Bluetooth o incluso Bonjour?

Una de estas cosas podría estar generando todo este tráfico de DNS.

Por otro lado, esto puede ser un Malware. Trate de limpiar toda su caché de DNS y cambiarla a 0.0.0.0

Para vaciar la caché de DNS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X