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-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.Réponses:
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 ).
la source
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 deaptcommandes aveceatmydatapeut 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)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:
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) est12.7%, ce qui correspond à un cœur utilisé à 100%, ce qui représente également 1/8 de toutes les ressources du processeur:On peut également noter que la commande a une valeur de
100%dans laCPU%colonne, c'est parce qu'elle est relative à un cœur et non à tous les cœurs.la source
/dev/zero > /dev/nullun meilleur exemple, puisque urandom va épuiser le pool d'entropie?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?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% suruser+system+iowait, pour des valeurs de 100% divisées par votre nombre de cœurs comme décrit par AL, je ne dis pas quetopc'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 ).
la source
iotop --onlyl'--onlyoption de montrer que des processus ou des fils en train de faire d' E / S .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.
la source