Esiste una riga di comando equivalente ai dischi gnome?


10

Gnome Disks ( gnome-disks- precedentemente noto come palimpsest) fornisce SMART e alcune informazioni di benchmarking. Da quello che raccolgo, si basava su uno strumento da riga di comando udisksma questi progetti sembrano essersi uniti.

La nuova utility Dischi Gnome sembra mostrare solo i risultati medi dei test di benchmarking. Dagli screenshot, anche le versioni precedenti di palinsesto sembrano avere risposte massime e minime nei risultati.

Sono interessato a tutti i risultati nel benchmarking - in particolare sto cercando di trovare dischi che abbiano un effetto negativo sugli utenti eliminando i dischi con I / O lento nel peggiore dei casi. Voglio anche mappare questi dati nel tempo, quindi devo essere in grado di elaborarli / esportarli in modo programmatico.

Ho guardato udisksctl(nel pacchetto udisks2) ma sembra essere solo informazioni generali sui dischi e alcune informazioni SMART.

Esiste uno strumento da riga di comando che esegue il udisksreport di benchmarking vecchio stile e restituisce anche minimi e massimi?


Quale versione di Ubuntu stai usando?
SeiAGitForNotUsingGit il

Una miscela, ogni versione non accantonata tra il 12.04 e il 16.10.
tu-Reinstate Monica-dor duh,

Risposte:


7

Non posso parlare con il vecchio rapporto di benchmarking di udisks, ma forse fioti sarà utile. fioè attualmente disponibile per tutte le versioni di Ubuntu da Precise To Zesty

È possibile installarlo con sudo apt-get install fiodopo aver attivato il repository Universe

Alcuni test rapidi indicano che è possibile scegliere la partizione da testare semplicemente assicurando che la pwd(Directory di lavoro attuale) sia sulla partizione che si desidera testare.

Ad esempio, ecco i risultati che ottengo eseguendolo sulla mia partizione di root che si trova su un SSD Toshiba THNSNH128GBST (my / dev / sda)

$ sudo fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=256M --numjobs=8 --runtime=60 --group_reporting randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=1 ...

  randwrite: (groupid=0, jobs=8): err= 0: pid=15096: Wed Feb 15 13:58:31 2017
  write: io=2048.0MB, bw=133432KB/s, iops=33358, runt= 15717msec
    slat (usec): min=1, max=223379, avg=232.82, stdev=4112.31
    clat (usec): min=0, max=16018, avg= 0.30, stdev=22.20
     lat (usec): min=1, max=223381, avg=233.25, stdev=4112.55
    clat percentiles (usec):
     |  1.00th=[    0],  5.00th=[    0], 10.00th=[    0], 20.00th=[    0],
     | 30.00th=[    0], 40.00th=[    0], 50.00th=[    0], 60.00th=[    0],
     | 70.00th=[    0], 80.00th=[    1], 90.00th=[    1], 95.00th=[    1],
     | 99.00th=[    1], 99.50th=[    1], 99.90th=[    2], 99.95th=[    3],
     | 99.99th=[   31]
    bw (KB  /s): min= 3473, max=241560, per=12.42%, avg=16577.30, stdev=28056.68
    lat (usec) : 2=99.79%, 4=0.18%, 10=0.02%, 20=0.01%, 50=0.01%
    lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%
    lat (msec) : 20=0.01%
  cpu          : usr=0.52%, sys=1.08%, ctx=3235, majf=0, minf=228
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=524288/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=2048.0MB, aggrb=133432KB/s, minb=133432KB/s, maxb=133432KB/s, mint=15717msec, maxt=15717msec

Disk stats (read/write):
  sda: ios=0/197922, merge=0/84378, ticks=0/37360, in_queue=37324, util=93.41%

L'esecuzione nella mia directory home che si trova su un HDD Western Digital WD2003FZEX-00Z4SA0 con lo stesso comando produce il seguente output:

randwrite: (groupid=0, jobs=8): err= 0: pid=15062: Wed Feb 15 13:53:32 2017
  write: io=1299.6MB, bw=22156KB/s, iops=5538, runt= 60062msec
    slat (usec): min=1, max=200040, avg=1441.http://meta.stackexchange.com/questions/122692/moderator-tools-make-merging-questions-a-little-easier74, stdev=11322.69
    clat (usec): min=0, max=12031, avg= 0.41, stdev=32.24
     lat (usec): min=1, max=200042, avg=1442.29, stdev=11323.05
    clat percentiles (usec):
     |  1.00th=[    0],  5.00th=[    0], 10.00th=[    0], 20.00th=[    0],
     | 30.00th=[    0], 40.00th=[    0], 50.00th=[    0], 60.00th=[    0],
     | 70.00th=[    0], 80.00th=[    1], 90.00th=[    1], 95.00th=[    1],
     | 99.00th=[    2], 99.50th=[    2], 99.90th=[    3], 99.95th=[    9],
     | 99.99th=[   14]
    bw (KB  /s): min=  426, max=282171, per=13.12%, avg=2906.99, stdev=17280.75
    lat (usec) : 2=98.88%, 4=1.03%, 10=0.05%, 20=0.04%, 50=0.01%
    lat (usec) : 100=0.01%, 250=0.01%
    lat (msec) : 10=0.01%, 20=0.01%
  cpu          : usr=0.09%, sys=0.25%, ctx=7912, majf=0, minf=227
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=332678/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=1299.6MB, aggrb=22155KB/s, minb=22155KB/s, maxb=22155KB/s, mint=60062msec, maxt=60062msec

Disk stats (read/write):
  sdb: ios=0/94158, merge=0/75298, ticks=0/116296, in_queue=116264, util=98.40%

Ho eliminato l'output prodotto mentre è in esecuzione per mantenere questa risposta di dimensioni leggibili.

Spiegazione dell'output che ho trovato interessante:

Puoi vedere che otteniamo una deviazione minima, massima e standard per tutte queste metriche.

stecca indica la latenza di invio -

clat indica latenza di completamento. Questo è il tempo che passa tra l'invio al kernel e il completamento dell'IO, esclusa la latenza di invio. Nelle versioni precedenti di fio, questa era la migliore metrica per l'approssimazione della latenza a livello di applicazione.

lat sembra essere abbastanza nuovo. Sembra che questa metrica abbia inizio nel momento in cui la struttura IO viene creata in fio e viene completata subito dopo il clat, rendendola quella che rappresenta meglio ciò che le applicazioni sperimenteranno. Questo è quello che probabilmente vorrai rappresentare graficamente.

bw La larghezza di banda è piuttosto autoesplicativa, tranne per la parte per =. I documenti dicono che è pensato per testare un singolo dispositivo con più carichi di lavoro, quindi puoi vedere quanta parte dell'Io è stata consumata da ogni processo.

Quando fio viene eseguito su più dispositivi, come ho fatto per questo output, può fornire un confronto utile indipendentemente dal fatto che lo scopo previsto sia testare un carico di lavoro specifico.

Sono sicuro che non sorprende che la latenza sul disco rigido sia molto superiore a quella del disco a stato solido.

fonti:

https://tobert.github.io/post/2014-04-17-fio-output-explained.html

https://github.com/axboe/fio/blob/master/README

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.