Existe uma linha de comando equivalente a gnome-disks?

11

Gnome Discos ( gnome-disks - anteriormente conhecido como palimpsest ) fornece informações de benchmarking SMART e algumas. Pelo que eu sei, costumava ser baseado em uma ferramenta de linha de comando udisks , mas esses projetos parecem ter se fundido.

O novo utilitário Gnome Disks aparece apenas para mostrar os resultados average dos testes de benchmarking. Nas capturas de tela, as versões anteriores do palimpsest parecem ter respostas máxima e mínima nos resultados também.

Estou interessado em todos os resultados do benchmarking - especificamente, estou tentando encontrar discos que estão tendo um efeito negativo nos usuários eliminando discos com I / O lenta no pior caso. Eu também quero mapear esses dados ao longo do tempo, então eu preciso ser capaz de processar / exportar de forma programática.

Eu olhei para udisksctl (no pacote udisks2), mas parece ser apenas informação geral sobre os discos e algumas informações da SMART.

Existe uma ferramenta de linha de comando que executa o antigo relatório de benchmarking udisks style e também retorna valores mínimos e máximos?

    
por tudor 16.12.2016 / 02:05

1 resposta

7

Eu não posso falar com o relatório de benchmark antigo do udisks, mas talvez fio seja útil para você. O fio está atualmente disponível para todas as versões do Ubuntu a partir de Precise To Zesty

Você pode instalá-lo com sudo apt-get install fio após ativar o repositório Universe

Alguns testes rápidos indicam que você pode escolher a partição para testar simplesmente garantindo que o pwd (Diretório de Trabalho Atual) esteja na partição que você deseja testar.

Por exemplo, aqui estão os resultados que eu coloco na minha partição raiz que está em um 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%

A execução no meu diretório inicial que está em um disco rígido Western Digital WD2003FZEX-00Z4SA0 com o mesmo comando resulta na seguinte saída:

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%

Reduzi a saída produzida enquanto ela está em execução para manter essa resposta em um tamanho legível.

Explicação da saída que achei interessante:

Você pode ver que obtemos min, média máxima e desvio padrão para todas essas métricas.

slat indica latência de envio -

clat indica a latência de conclusão. Este é o tempo que passa entre o envio para o kernel e quando o IO está completo, não incluindo a latência de envio. Em versões mais antigas do fio, essa foi a melhor métrica para aproximar a latência em nível de aplicativo.

lat parece ser relativamente novo. Parece que esta métrica começa no momento em que a estrutura de IO é criada no fio e é concluída logo após a clat, tornando-a a que melhor representa o que as aplicações irão experimentar. Este é o que você provavelmente vai querer representar graficamente.

bw A largura de banda é bastante auto-explicativa, exceto para o per = part. Os documentos dizem que ele serve para testar um único dispositivo com várias cargas de trabalho, para que você possa ver quanto do IO foi consumido por cada processo.

Quando o fio é executado em vários dispositivos, como eu fiz para essa saída, ele pode fornecer uma comparação útil, independentemente do fato de que sua finalidade seja testar uma carga de trabalho específica.

Tenho certeza de que não é surpresa que a latência no disco rígido seja muito maior que a da unidade de estado sólido.

Fontes:

link

link

    
por Elder Geek 15.02.2017 / 21:47