Pourquoi apt-get n'utilise-t-il PAS 100% (CPU OU disque OU net)?

21

Pourquoi n'utilise-t-il apt-get pas 100% du processeur, du disque ou du réseau - ou même à proximité? Même sur un système lent (Raspberry Pi 2+), je reçois au maximum 30% de charge CPU. Je pense simplement que soit il est étranglé artificiellement, soit il devrait maximiser quelque chose pendant qu'il fonctionne ... ou il devrait être capable de faire son travail plus rapidement qu'il ne le fait.

Edit: je mesure à peu près via les moniteurs cpu / disk / net dans mon panneau et l'application System Monitor d'Ubuntu MATE.

Veuillez expliquer pourquoi je me trompe. :-)

Mise à jour: je comprends qu'il apt-getdoit récupérer ses mises à jour (et peut être limité par la bande passante en amont / fournisseur). Mais une fois qu'il est "déballé" et ainsi de suite, l'utilisation du processeur devrait au moins augmenter (sinon au maximum). Sur mon poste de travail à domicile assez décent, qui utilise un SSD pour son lecteur principal et un ramdisk pour / tmp, ce n'est pas le cas.

Ou peut-être que je dois y regarder de plus près.

apt cpu-usage

— KlaymenDK
source

Comment mesurez-vous la charge du disque et du réseau?

— JigglyNaga

1

Cependant, Disk IO est exactement comme Network IO. Il bloquera toujours l'application, l'empêchant d'utiliser le CPU. Hélas, apt-getn'est pas particulièrement bon pour optimiser cela. J'imagine qu'il pourrait s'installer au fur et à mesure du téléchargement, de sorte qu'au moment où votre téléchargement est terminé, la majeure partie de votre charge utile pourrait déjà être installée, mais ce n'est malheureusement pas le cas. Dans tous les cas, les installations autonomes consistent principalement à extraire des données sur le disque. Ces opérations sont intrinsèquement liées aux entrées-sorties et il n'y a tout simplement pas grand-chose d'autre à faire que d'attendre sur le lecteur de disque pour terminer la lecture ou l'écriture.

— PSkocik

Comment avez-vous obtenu le numéro de charge CPU de 30% ?

— AL

1

@PSkocik "J'imagine qu'il pourrait s'installer au fur et à mesure des téléchargements" apt-get juste des téléchargements, des installations de dpkg. Et dpkg est plus intelligent qu'apt-get dans l'ordre où un paquet de paquets doit être installé, ce qui n'est peut-être pas la même chose qu'apt-get les télécharge.

— Braiam

Notez qu'une application qui est à 100% liée au processeur pendant un demi-tick, puis à 100% liée aux E / S pour l'autre moitié n'apparaîtra ni liée au processeur ni liée aux IO.

— MSalters

28

Les applications ne maximiseront le processeur que si l'application est liée au processeur . Une application est liée au processeur si elle peut obtenir rapidement toutes ses données et qu'elle attend le processeur pour traiter les données.

apt-get, d'autre part, est lié aux entrées-sorties . Cela signifie qu'il peut traiter ses données assez rapidement, mais le chargement des données (à partir du disque ou du réseau) prend du temps, pendant lequel le processeur peut faire d'autres choses ou rester inactif si aucun autre processus n'en a besoin.

En règle générale, toutes les demandes d'E / S (disque, réseau) sont lentes et chaque fois qu'un thread d'application en fait une, le noyau la supprimera du processeur jusqu'à ce que les données soient chargées dans le noyau (= ces demandes d'E / S sont appelées demandes de blocage ).

— PSkocik
source

6

Avec les aptcommandes, cela est aggravé par le fait que de nombreux fichiers sont ouverts en mode de synchronisation, ou avec des vidages explicites fréquents sur le disque demandés pour garantir que les données sur le disque restent dans un état cohérent, car un plantage du système pourrait avoir de graves conséquences autrement. L'exécution de aptcommandes avec eatmydatapeut souvent améliorer considérablement les performances au détriment d'une fiabilité réduite (sans oublier que les services démarrés dans le cadre des installations de packages hériteront des paramètres eatmydata)

— Stéphane Chazelas

Lol à ce dernier point :). Quelqu'un a-t-il des numéros pour eatmydata depuis la validation de 2010 dans bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635 ? Je ne sais pas si "dramatiquement" est toujours le bon mot.

— sourcejedi

Ah, c'est peut-être (au moins sur certains fournisseurs de cloud) bugs.launchpad.net/cloud-init/+bug/1236531/comments/6

— sourcejedi

1

@sourcejedi Sur un Raspberry Pi2 avec une carte SD relativement haut de gamme (mais toujours une carte SD, pas un SSD haut de gamme), je considère que "dramatiquement" est un peu un euphémisme. Les performances de dpkg sur les supports flash sont vraiment nulles.

— Gilles 'SO- arrête d'être méchant'

1

S'il est lié au disque, alors pourquoi n'utilise-t-il pas 100% de bande passante du disque?

— user253751

15

Même sur un système lent (Raspberry Pi 2+), je reçois au maximum 30% de charge CPU.

Le Raspberry Pi 2+ possède 4 cœurs. Pour certains outils de surveillance, une utilisation à 100% correspond à tous les cœurs utilisés à 100%. Si un seul cœur dans un processeur quadruple code est utilisé, la charge CPU est de 25%. La charge CPU de 30% que vous mentionnez est à peu près un cœur utilisé à 100% tandis que certains processus s'exécutent sur les autres cœurs:

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

Comme il apt-getn'est pas multi-thread, il n'utilisera jamais plus d'un processeur, ce qui représente 25% de toutes les ressources CPU.

Voici un exemple sur ma machine à 8 cœurs (4 cœurs avec Hyper-Threading ) exécutant Ubuntu, j'ai lancé un thread avec la cat /dev/zero > /dev/nullcommande afin de créer un processus infini qui utilise un seul cœur.

Maintenant, si nous regardons le graphique htop, nous pouvons voir que la charge moyenne ( Avgbarre) est 12.7%, ce qui correspond à un cœur utilisé à 100%, ce qui représente également 1/8 de toutes les ressources du processeur:

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

On peut également noter que la commande a une valeur de 100%dans la CPU%colonne, c'est parce qu'elle est relative à un cœur et non à tous les cœurs.

— AL
source

+1, un% d'utilisation proche d'un multiple de (100 / nCores) devrait toujours déclencher un examen plus approfondi. Cela peut être vérifié - et en fait est exclu - en utilisant un moniteur capable d'afficher l'utilisation par cœur, où 0 <= le% <= 100 * nCores

— underscore_d

N'est-ce pas /dev/zero > /dev/nullun meilleur exemple, puisque urandom va épuiser le pool d'entropie?

— Filip Haglund

@FilipHaglund cat /dev/zero > /dev/nulldonne le même résultat, je ne connaissais pas cet appareil, merci. urandom va épuiser le pool d'entropie Je ne connais pas le pool d'entropie, comment cela peut-il être un problème?

— AL

1

Lorsque les programmes utilisent la cryptographie, ils ont besoin de données vraiment aléatoires pour générer des clés de chiffrement sécurisées. L'ordinateur génère l'entropie en regardant la souris se déplacer entre autres. Il existe des générateurs de nombres aléatoires matériels, mais la plupart des ordinateurs n'en ont pas. Si l'entropie est entièrement utilisée, le code qui a besoin d'une entropie sécurisée doit attendre que plus soit généré. Urandom utilisera des bits vraiment aléatoires s'ils sont disponibles, ou retournera autrement des bits aléatoires moins sécurisés.

— Filip Haglund

Lorsque les programmes utilisent la cryptographie Même si je pense que personne n'effectuera un test de performance du processeur lors de la génération d'une clé aléatoire, j'ai mis à jour ma réponse par précaution.

— AL

2

Je pense que vous ne mesurez pas vraiment IO%. Je n'ai pas vu de widget Linux IO%. (Je suis très jaloux du gestionnaire de tâches de Windows 10 :). Vérifiez en utilisant la iotopcommande et vous verrez 100% IO.

topdevrait afficher 100% sur user+ system+ iowait, pour des valeurs de 100% divisées par votre nombre de cœurs comme décrit par AL, je ne dis pas que topc'est 100% utile, mais cela peut être un outil complet très utile à apprendre.

Le débit sera inférieur au maximum, car vous déballez de nombreux petits fichiers, alias "IO aléatoire". Il existe également des vidages de synchronisation / cache de disque, bien que depuis 2010 sur Linux, il n'y en ait que quelques-uns pour chaque package installé. ( Auparavant un par fichier ).

— sourcejedi
source

Utilisez iotop --onlyl' --onlyoption de montrer que des processus ou des fils en train de faire d' E / S .

— AL

4

iostat, dstat, atop ... affichera l'utilisation du disque par disque sans avoir besoin de privilèges. C'est pour l'utilisation par tâche que vous avez besoin de privilèges

— Stéphane Chazelas

@ StéphaneChazelas absolument correct. Le point que j'essayais de faire (édition ninja) est que l'OP mentionne quelques outils GUI. Et les outils GUI particuliers que j'ai vus, comme Gnome System Monitor, montrent le débit mais pas IO%.

— sourcejedi

2

En fait, les demandes d'E / S / réseau sont vraiment lentes par rapport aux opérations CPU. Cela signifie que pendant que votre carte réseau récupère des données ou que votre disque écrit ces données, votre CPU ne fait absolument rien (pour ce processus de toute façon).

Si votre disque dur est plus rapide que votre connexion réseau (ce qui est probablement vrai), il n'écrira pas plus qu'il n'en a reçu.

Enfin, le pourcentage du réseau correspond à l'utilisation maximale possible de la carte réseau , pas à la connexion. Donc, vous pouvez avoir une carte réseau 1 Gbit / s, vous avez très peu de chances d'avoir une connexion Internet qui atteint cette bande passante.

— Aymeric R.
source