Tengo el mismo problema. Mi porcentaje de CPU volvió a la normalidad después de eliminar todos mis volúmenes.

 docker system prune --volumes

También eliminé manualmente algunos volúmenes con nombre:

 docker volume rm NameOfVolumeHere

Eso no resuelve el problema general de no poder usar volúmenes con Docker para mac. En este momento, solo estoy teniendo cuidado con la cantidad de volúmenes que uso y cierro el escritorio de Docker cuando no está en uso.

Esta es una pequeña secuencia de comandos de dTrace que utilizo para encontrar dónde pasa el tiempo el kernel (es de Solaris y se remonta a los primeros días de Solaris 10):

 #!/usr/sbin/dtrace -s profile:::profile-1001hz /arg0/ { @[ stack() ] = count(); }

Simplemente toma muestras de los rastros de la pila del kernel y cuenta cada uno que encuentra en la agregación @ .

Ejecutarlo como root:

 ... # ./kernelhotspots.d > /tmp/kernel_hot_spots.txt

Deje que se ejecute durante un tiempo decente mientras tiene problemas con la CPU, luego presione CTRL-C para romper el script. Emitirá todos los rastros de la pila del kernel que encuentre, el último más común. Si necesita más (o menos) marcos de pila de los predeterminados con

 @[ stack( 15 ) ] = count();

Eso mostrará un marco de pila de 15 llamadas de profundidad.

Los últimos rastros de la pila serán donde su kernel pasa la mayor parte de su tiempo. Eso puede o no ser informativo.

Esta secuencia de comandos hará lo mismo para los seguimientos de la pila en el espacio del usuario:

 #!/usr/sbin/dtrace -s profile:::profile-1001hz /arg1/ { @[ ustack() ] = count(); }

Ejecútelo de manera similar:

 ... # ./userspacehotspots.d > /tmp/userspace_hot_spots.txt

ustack() es un poco más lento: para emitir los nombres de funciones reales, dTrace tiene que hacer mucho más trabajo para obtenerlos de los espacios de direcciones de los procesos apropiados.

Deshabilitar la Protección de integridad del sistema podría ayudarlo a obtener mejores seguimientos de pila.

Consulte Conceptos básicos de la acción de DTrace para obtener más detalles.

Mi sospecha es que el problema está relacionado con IO. Con los volúmenes de MacOS, esto involucra osxfs donde hay algunos ajustes de rendimiento que puede realizar. Principalmente, si puede aceptar menos comprobaciones de coherencia, puede establecer el modo de volumen en delegated para un rendimiento más rápido. Consulte los documentos para obtener más detalles: https://docs.docker.com/docker-for-mac/osxfs-caching/ . Sin embargo, si su imagen contiene una gran cantidad de archivos pequeños, el rendimiento se verá afectado, especialmente si también tiene muchas capas de imágenes.

También puede probar el siguiente comando para depurar cualquier problema de proceso dentro de la máquina virtual integrada que usa la ventana acoplable:

 docker run -it --rm --pid host busybox top

(Para salir, use <ctrl>-c )

Para rastrear si es IO, también puede probar lo siguiente:

 $ docker run -it --rm --pid host alpine /bin/sh $ apk add sysstat $ pidstat -d 5 12

Eso se ejecutará dentro del contenedor alpine que se ejecuta en el espacio de nombres pid de VM, mostrando cualquier IO que ocurra desde cualquier proceso, ya sea que ese proceso esté o no dentro de un contenedor. Las estadísticas son cada 5 segundos durante un minuto (12 veces) y luego le dará una tabla promedio por proceso. Luego puede <ctrl>-d para destruir el contenedor alpino.

A partir de los comentarios y ediciones, estas estadísticas pueden comprobarse. Un MBP de 4 núcleos tiene 8 subprocesos, por lo que la utilización total de la CPU debería ser del 800 % si MacOS informa lo mismo que otros sistemas basados en Unix. Dentro de la máquina virtual, se muestra más del 100 % de carga en el comando superior para el promedio en el último minuto (aunque menos de los promedios de 5 y 15), que es aproximadamente lo que ve para el proceso de hiperkit en el host. El uso instantáneo es superior al 12% desde arriba, no al 3%, ya que debe agregar los porcentajes del sistema y del usuario. Y los números de IO que se muestran en pidstat se alinean aproximadamente con lo que ve escrito en la imagen qcow2.

Si el propio motor de la ventana acoplable está fallando (p. ej., reiniciando contenedores o ejecutando muchas comprobaciones de estado), entonces puede depurarlo observando el resultado de:

 docker events

Cambiar los volúmenes para usar una configuración delegada funcionó para mí y resultó en una caída drástica en el uso de la CPU. consulte el documento: https://docs.docker.com/docker-for-mac/osxfs-caching/#delegated

cómo configurar en mi docker-compose.yml:

 version: "3" services: my_service: image: python3.6 ports: - "80:10000" volumes: - ./code:/www/code:cached

Para mí esto funcionó, macOS 10.15.5, Docker Desktop 2.3.0

deshabilitar use gRPC FUSE for file sharing podría no ser una buena idea. Encontré los comentarios de otro problema realizado por la comunidad docker. Ver abajo:

 So we'll look into that. However, osxfs will not be supported long term. We can't maintain two solutions. Sin embargo, So we'll look into that. However, osxfs will not be supported long term. We can't maintain two solutions.

hier to docker tema hilo

EDITAR: después de algunas semanas, mis problemas con la CPU han regresado, por lo que las soluciones a continuación probablemente no valgan la pena

Mi CPU siempre funcionaba a un nivel muy alto y no era E/S, según lo determinado mediante docker stats

Hice un montón de cosas, pero de repente disminuyó a niveles razonables y permaneció así durante más de una semana, después de hacer lo siguiente:

• Asegúrese de tener el número correcto de CPU configurado, no lo que tiene, sino la MITAD de esa cantidad. El mío era más de la mitad, y creo que ese era el verdadero problema, en Preferences | Resources
• disminuir el número de recursos compartidos de archivos si es posible - Preferences | Resources , /privado, /tmp/, /var/carpetas
• deshabilitar use gRPC FUSE for file sharing - Preferences | Resources

La solución que encontré fue aumentar los recursos dados a Docker. Aumenté la memoria de 2 GB a 8 GB, el intercambio de 1 GB a 2 GB y el tamaño de la imagen del disco a 160 GB. Resolvió completamente el problema para mí, y es fácil de probar para los lectores.