Perché apt-get NON usa il 100% (CPU o disco O rete)?

21

Perché apt-get non usare il 100% di CPU, disco o rete - o addirittura vicino ad esso? Anche su un sistema lento (Raspberry Pi 2+) sto ricevendo al massimo il 30% del carico della CPU. Sto solo pensando che o viene strozzato artificialmente, o dovrebbe massimizzare qualcosa mentre sta funzionando ... o dovrebbe essere in grado di fare le sue cose più velocemente di quanto non faccia.

Modifica: sto solo misurando approssimativamente tramite monitor cpu / disk / net nel mio pannello e l'app System Monitor di Ubuntu MATE.

Per favore, spiega perché mi sbaglio. :-)

Aggiornamento: capisco che apt-getdeve recuperare i suoi aggiornamenti (e potrebbe essere limitato dalla larghezza di banda upstream / provider). Ma una volta "decompresso" e così via, l'utilizzo della CPU dovrebbe almeno salire (se non al massimo). Sulla mia postazione di lavoro abbastanza decente, che utilizza un SSD per l'unità principale e un ramdisk per / tmp, non è così.

O forse devo dare un'occhiata più da vicino.

apt cpu-usage

— KlaymenDK
fonte

Come si misura il carico del disco e della rete?

— JigglyNaga,

1

Disk IO è proprio come l'IO di rete, però. Bloccherà comunque l'app, impedendole di utilizzare la CPU. Ahimè, apt-getnon è particolarmente bravo a ottimizzarlo. Immagino che potrebbe installarsi mentre scarica in modo che al termine del download la maggior parte del payload possa essere già installata, ma, sfortunatamente, non lo è. In ogni caso, le installazioni standalone estraggono principalmente i dati sul disco. Tali operazioni sono intrinsecamente legate all'IO e semplicemente non c'è molto altro da fare che attendere sull'unità disco per terminare la lettura o la scrittura.

— PSkocik,

Come hai ottenuto il numero di caricamento della CPU del 30% ?

— AL

1

@PSkocik "Immagino che possa essere installato mentre scarica" apt-get solo download, installazioni dpkg. E dpkg è più intelligente di apt-get nell'ordine in cui dovrebbero essere installati un sacco di pacchetti, che potrebbero non essere gli stessi che apt-get li scarica.

— Braiam,

Si noti che un'applicazione con il 100% di CPU associato per mezzo tick e quindi con il 100% di I / O per l'altra metà non apparirà né CPU né IO.

— Sali

28

Le app massimizzeranno la CPU solo se l'app è associata alla CPU . Un'app è associata alla CPU se riesce a ottenere rapidamente tutti i suoi dati e ciò che attende è il processore per elaborare i dati.

apt-getd'altra parte, è IO-bound . Ciò significa che può elaborare i suoi dati piuttosto rapidamente, ma il caricamento dei dati (dal disco o dalla rete) richiede tempo, durante il quale il processore può fare altre cose o restare inattivo se nessun altro processo ne ha bisogno.

In genere, tutte le richieste I / O (disco, rete) sono lente e ogni volta che un thread dell'applicazione ne crea uno, il kernel lo rimuoverà dal processore fino a quando i dati non vengono caricati nel kernel (= queste richieste I / O vengono chiamate richieste di blocco ).

— PSkocik
fonte

6

Con i aptcomandi, è aggravato dal fatto che molti file sono aperti in modalità di sincronizzazione o con frequenti flush espliciti su disco richiesti per garantire che i dati sul disco rimangano in uno stato coerente poiché un arresto anomalo del sistema potrebbe avere gravi conseguenze altrimenti. L'esecuzione di aptcomandi eatmydatapuò spesso migliorare notevolmente le prestazioni a scapito della ridotta affidabilità (per non parlare del fatto che i servizi avviati come parte dell'installazione dei pacchetti erediteranno le impostazioni di Eatmydata)

— Stéphane Chazelas,

Lol a quell'ultimo punto :). Qualcuno ha numeri per eatmydata dal 2010 commesso in bugs.debian.org/cgi-bin/bugreport.cgi?bug=578635 ? Non so se "drammaticamente" sia ancora la parola giusta.

— sourcejedi,

Ah, forse è (almeno su alcuni provider cloud) bugs.launchpad.net/cloud-init/+bug/1236531/comments/6

— sourcejedi

1

@sourcejedi Su un Raspberry Pi2 con una scheda SD relativamente di fascia alta (ma ancora una scheda SD, non un SSD di fascia alta), considero "drammaticamente" un eufemismo. Le prestazioni di dpkg su supporti flash fanno davvero schifo.

— Gilles 'SO- smetti di essere malvagio'

1

Se è associato a I / O del disco, perché non utilizza la larghezza di banda del disco al 100%?

— user253751,

15

Anche su un sistema lento (Raspberry Pi 2+) sto ricevendo al massimo il 30% del carico della CPU.

Il Raspberry Pi 2+ ha 4 core. Per alcuni strumenti di monitoraggio, un utilizzo del 100% corrisponde a tutti i core utilizzati al 100%. Se viene utilizzato un solo core in un processore quad code, il carico della CPU è del 25%. Il carico della CPU del 30% menzionato è all'incirca un core utilizzato al 100% mentre alcuni processi sono in esecuzione su altri core:

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

Poiché apt-getnon è multi-thread, non utilizzerà mai più di un processore, che rappresenta il 25% di tutte le risorse della CPU.

Ecco un esempio sulla mia macchina a 8 core (4 core con Hyper-Threading ) con Ubuntu, ho lanciato un thread con il cat /dev/zero > /dev/nullcomando per creare un processo infinito che utilizza interamente un core.

Ora, se diamo un'occhiata al grafico da htop, possiamo vedere che il carico medio ( Avgbarra) è 12.7%, che corrisponde a un core utilizzato al 100%, che è anche 1/8 di tutte le risorse della CPU:

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

Si può anche notare che il comando ha un valore 100%nella CPU%colonna, questo perché è relativo a un core e non a tutti i core.

— AL
fonte

+1, una percentuale di utilizzo vicina a un multiplo di (100 / nCores) dovrebbe sempre innescare un ulteriore esame. Questo può essere verificato - e in effetti è escluso - utilizzando un monitor in grado di mostrare l'utilizzo per core, dove 0 <= the% <= 100 * nCores

— underscore_d

Non è /dev/zero > /dev/nullun esempio migliore, dal momento che urandom esaurirà il pool di entropia?

— Filip Haglund,

@FilipHaglund cat /dev/zero > /dev/nulldà lo stesso risultato, non conoscevo quel dispositivo, grazie. urandom esaurirà il pool di entropia Non conosco il pool di entropia, come può essere un problema?

— AL

1

Quando i programmi usano crypto, hanno bisogno di dati veramente casuali per generare chiavi di crittografia sicure. Il computer genera entropia guardando il mouse muoversi tra le altre cose. Esistono generatori di numeri casuali hardware, ma la maggior parte dei computer non li possiede. Se l'entropia è esaurita, il codice che necessita dell'entropia sicura deve attendere che ne venga generato altro. Urandom utilizzerà bit veramente casuali, se disponibili, o altrimenti restituirà bit casuali meno sicuri.

— Filip Haglund,

Quando i programmi usano crypto Anche se penso che nessuno eseguirà un benchmark della CPU durante la generazione di una chiave casuale, ho aggiornato la mia risposta come precauzione.

— AL

2

Penso che in realtà non stai misurando l'IO%. Non ho visto un widget IO% Linux. (Sono molto invidioso del task manager di Windows 10 :). Controlla usando il iotopcomando e vedrai 100% IO.

topdovrebbe mostrare il 100% su user+ system+ iowait, per valori del 100% divisi per il numero di core come descritto da AL Non sto dicendo che topsia utile al 100%, ma può essere uno strumento completo davvero utile da imparare.

Il throughput sarà inferiore al massimo, poiché stai scompattando molti file di piccole dimensioni, noti anche come "I / O casuali". Ci sono anche alcuni svuotamenti di sincronizzazione / cache del disco, sebbene dal 2010 su Linux ce ne siano solo alcuni per ogni pacchetto installato. ( Utilizzato per essere uno per file ).

— sourcejedi
fonte

Usa iotop --only, l' --onlyopzione di visualizzare solo i processi o thread in realtà facendo di I / O .

— AL

4

iostat, dstat, in cima ... mostrerà l'utilizzo del disco per disco senza bisogno di privilegi. È per l'utilizzo per attività che sono necessari i privilegi

— Stéphane Chazelas

@ StéphaneChazelas assolutamente corretto. Il punto che stavo cercando di fare (modifica ninja) è che l'OP menziona un paio di strumenti della GUI. E i particolari strumenti della GUI che ho visto, come Gnome System Monitor, mostrano il throughput ma non l'IO%.

— sourcejedi,

2

In realtà, le richieste IO / di rete sono molto lente rispetto alle operazioni della CPU. Ciò significa che mentre la tua scheda di rete sta recuperando dati o il tuo disco sta scrivendo questi dati, la tua CPU non fa assolutamente nulla (per questo processo comunque).

Se il tuo disco rigido è più veloce della tua connessione di rete (il che è probabilmente vero), non scriverà più di quanto abbia ricevuto.

Infine, la percentuale di rete corrisponde al massimo utilizzo possibile della scheda di rete , non alla connessione. Quindi potresti avere una scheda di rete da 1 Gb / s, è molto improbabile che tu abbia una connessione Internet che raggiunge questa larghezza di banda.

— Aymeric R.
fonte