¿Por qué apt-get NO utiliza el 100% (CPU O disco O red)?

21

¿Por qué apt-get no utiliza el 100% de la CPU, el disco o la red, o incluso cerca de él? Incluso en un sistema lento (Raspberry Pi 2+) obtengo como máximo un 30% de carga de CPU. Solo estoy pensando que o bien está siendo estrangulado artificialmente, o debería maximizar algo mientras está funcionando ... o debería ser capaz de hacer su trabajo más rápido de lo que lo hace.

Editar: solo estoy midiendo aproximadamente a través de monitores cpu / disk / net en mi panel y la aplicación System Monitor de Ubuntu MATE.

Por favor explique por qué estoy equivocado. :-)

Actualización: entiendo que apt-getnecesita obtener sus actualizaciones (y puede estar limitado por el ancho de banda ascendente / del proveedor). Pero una vez que está "desempacando" y así sucesivamente, el uso de la CPU debería al menos aumentar (si no el máximo). En mi estación de trabajo hogareña bastante decente, que usa un SSD para su unidad principal y un disco RAM para / tmp, este no es el caso.

O tal vez necesito echar un vistazo más de cerca.

apt cpu-usage

— KlaymenDK
fuente

¿Cómo estás midiendo el disco y la carga de la red?

— JigglyNaga

1

Sin embargo, Disk IO es como IO de red. Seguirá bloqueando la aplicación, evitando que use la CPU. Por desgracia, apt-getno es particularmente bueno para optimizar esto. Me imagino que podría instalarse a medida que se descarga para que cuando finalice la descarga, la mayor parte de su carga ya esté instalada, pero, desafortunadamente, no lo hace. En cualquier caso, las instalaciones independientes en su mayoría solo extraen datos al disco. Esas operaciones están inherentemente vinculadas a E / S, y simplemente no hay mucho más que hacer sino esperar en la unidad de disco para terminar de leer o escribir.

— PSkocik

¿Cómo obtuvo el número de carga de CPU del 30% ?

— AL

1

@PSkocik "Me imagino que podría instalarse mientras se descarga" apt-get solo descargas, instalaciones dpkg. Y dpkg es más inteligente que apt-get en el orden en que se deben instalar un montón de paquetes, lo que puede no ser lo mismo que apt-get los descarga.

— Braiam

Tenga en cuenta que una aplicación que esté 100% vinculada a la CPU durante medio tick, y luego 100% vinculada a IO para la otra mitad, no aparecerá vinculada a la CPU ni a IO.

— MSalters

28

Las aplicaciones solo maximizarán la CPU si la aplicación está vinculada a la CPU . Una aplicación está vinculada a la CPU si puede obtener rápidamente todos sus datos y lo que espera es que el procesador procese los datos.

apt-get, por otro lado, está sujeto a IO . Eso significa que puede procesar sus datos bastante rápido, pero cargar los datos (desde el disco o desde la red) lleva tiempo, durante el cual el procesador puede hacer otras cosas o permanecer inactivo si ningún otro proceso lo necesita.

Por lo general, todas las solicitudes de E / S (disco, red) son lentas, y cada vez que un subproceso de la aplicación crea una, el núcleo lo eliminará del procesador hasta que los datos se carguen en el núcleo (= estas solicitudes de E / S se denominan solicitudes de bloqueo ).

— PSkocik
fuente

66

Con los aptcomandos, se ve agravado por el hecho de que muchos archivos están abiertos en modo de sincronización, o con frecuentes descargas explícitas al disco que se solicitan para garantizar que los datos en el disco se mantengan en un estado coherente, ya que un bloqueo del sistema podría tener serias consecuencias de lo contrario. La ejecución de aptcomandos a eatmydatamenudo puede mejorar drásticamente el rendimiento a expensas de una confiabilidad reducida (sin mencionar que los servicios iniciados como parte de las instalaciones de paquetes heredarán la configuración de eatmydata)

— Stéphane Chazelas

Lol en ese último punto :). ¿Alguien tiene números para eatmydata desde la confirmación de 2010 en bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635 ? No sé si "dramáticamente" es la palabra correcta todavía.

— sourcejedi

Ah, tal vez sea (al menos en algunos proveedores de la nube) bugs.launchpad.net/cloud-init/+bug/1236531/comments/6

— sourcejedi

1

@sourcejedi En una Raspberry Pi2 con una tarjeta SD relativamente alta (pero aún una tarjeta SD, no una SSD de alta gama), considero que "dramáticamente" es un poco insuficiente. El rendimiento de dpkg en medios flash realmente apesta.

— Gilles 'SO- deja de ser malvado'

1

Si está vinculado a la E / S del disco, ¿por qué no utiliza el 100% del ancho de banda del disco?

— user253751

15

Incluso en un sistema lento (Raspberry Pi 2+) obtengo como máximo un 30% de carga de CPU.

El Raspberry Pi 2+ tiene 4 núcleos. Para algunas herramientas de monitoreo, un uso del 100% corresponde a todos los núcleos utilizados al 100%. Si solo se usa un núcleo en un procesador de código cuádruple, la carga de la CPU es del 25%. La carga de CPU del 30% que menciona es aproximadamente un núcleo utilizado al 100% mientras algunos procesos se ejecutan en los otros núcleos:

(100% on one core out of 4 = 100 / 4 = 25%) + some processes ≃ 30%

Como apt-getno es multiproceso, nunca usará más de un procesador, que es el 25% de todos los recursos de la CPU.

Aquí hay un ejemplo en mi máquina de 8 núcleos (4 núcleos con Hyper-Threading ) que ejecuta Ubuntu, lancé un hilo con el cat /dev/zero > /dev/nullcomando para crear un proceso infinito que utiliza un núcleo por completo.

Ahora, si echamos un vistazo al gráfico htop, podemos ver que la carga promedio ( Avgbarra) es 12.7%, que corresponde a un núcleo utilizado al 100%, que también es 1/8 de todos los recursos de la CPU:

(100% = 100 / 8 = 12.5%) + some background processes ≃ 12.7%.

También se puede observar que el comando tiene un valor 100%en la CPU%columna, esto se debe a que es relativo a un núcleo y no a todos los núcleos.

— Alabama
fuente

+1, un% de uso cercano a un múltiplo de (100 / nCores) siempre debe desencadenar un mayor escrutinio. Esto puede verificarse, y de hecho está excluido, mediante el uso de un monitor capaz de mostrar el uso por núcleo, donde 0 <= el% <= 100 * nCores

— subrayado_d

¿No es /dev/zero > /dev/nullun mejor ejemplo, ya que urandom agotará el grupo de entropía?

— Filip Haglund

@FilipHaglund cat /dev/zero > /dev/nullda el mismo resultado, no conocía ese dispositivo, gracias. urandom agotará el grupo de entropía No sé el grupo de entropía, ¿cómo puede ser un problema?

— AL

1

Cuando los programas usan criptografía, necesitan datos verdaderamente aleatorios para generar claves de cifrado seguras. La computadora genera entropía observando el movimiento del mouse, entre otras cosas. Hay generadores de números aleatorios de hardware, pero la mayoría de las computadoras no los tienen. Si la entropía está agotada, el código que necesita entropía segura tiene que esperar a que se genere más. Urandom utilizará bits verdaderamente aleatorios si están disponibles, o devolverá bits aleatorios menos seguros.

— Filip Haglund

Cuando los programas usan criptografía Incluso si creo que nadie realizará un benchmark de CPU mientras genera una clave aleatoria, he actualizado mi respuesta como precaución.

— AL

2

Creo que en realidad no estás midiendo el IO%. No he visto un widget Linux IO%. (Tengo mucha envidia del administrador de tareas de Windows 10 :). Verifique usando el iotopcomando y verá 100% IO.

topdebería mostrar 100% a través de user+ system+ iowait, para valores de 100% divididos por su recuento de núcleo como lo describe AL, no digo que topsea 100% útil, pero puede ser una herramienta versátil realmente útil para aprender.

El rendimiento será inferior al máximo, porque está desempacando muchos archivos pequeños, también conocido como "IO aleatorio". También hay algunas descargas de sincronización de disco / caché, aunque desde 2010 en Linux solo hay unas pocas para cada paquete instalado. ( Solía ser uno por archivo ).

— sourcejedi
fuente

El uso iotop --only, la --onlyopción de mostrar sólo los procesos o hilos realmente hacer E / S .

— AL

44

iostat, dstat, atop ... mostrará la utilización del disco por disco sin necesidad de privilegios. Es para la utilización por tarea que necesita privilegios

— Stéphane Chazelas

@ StéphaneChazelas absolutamente correcto. El punto que estaba tratando de hacer (edición ninja) es que el OP menciona un par de herramientas GUI. Y las herramientas GUI particulares que he visto, como Gnome System Monitor, muestran el rendimiento pero no el IO%.

— sourcejedi

2

En realidad, las solicitudes IO / Network son realmente lentas en comparación con las operaciones de CPU. Esto significa que mientras su tarjeta de red está recuperando datos, o su disco está escribiendo estos datos, su CPU no hace absolutamente nada (para este proceso de todos modos).

Si su disco duro es más veloz que su conexión de red (lo que probablemente sea cierto), no escribirá más de lo que ha recibido.

Finalmente, el porcentaje de red corresponde al uso máximo posible de la tarjeta de red , no a la conexión. Por lo tanto, es posible que tenga un adaptador de red de 1 Gb / s, es muy poco probable que tenga una conexión a Internet que alcance este ancho de banda.

— Aymeric R.
fuente