Causas para I / O ineficiente?

Question

Estou rsync 'em uma pasta enorme de um disco rígido externo de 3,5 "interno, ambos 5.400 rpm. Ao usar dstat para dar uma olhada na taxa de transferência atual, eu regularmente vejo padrões como este :

--total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 20   6  34  40   0|  98M   90M|1272B 3652B|   0     0 |1702  4455 
 21   6  37  37   0| 121M   90M|1646B 4678B|   0     0 |2057  6488 
 17  24  29  30   0|  77M   95M| 630B 2416B|   0     0 |1581  4644 
 20   5  33  43   0|  86M   84M|1372B 2980B|   0     0 |1560  4146 
 20   6  30  44   0|  80M   75M| 700B 2722B|   0     0 |1484  3942 
 11   2  47  39   0|  39M   65M| 642B 1332B|   0     0 | 765  1507 
  0   0  50  50   0|   0    91M|  70B  354B|   0     0 | 136    70 
  0   0  50  49   0|   0    71M| 306B  346B|   0     0 | 146   119 
  0   0  50  50   0|   0    83M|  70B  346B|   0     0 | 145    60 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  36    84 
  0   0  50  50   0|   0     0 | 164B  646B|   0     0 |  35    71 
  0   0  50  50   0|   0     0 | 140B  802B|   0     0 |  30    64 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  27    68 
  0   0  50  50   0|   0    34M| 134B  346B|   0     0 |  86    68 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  30    71 
  0   0  50  50   0|   0     0 |2320B  346B|   0     0 |  40    76 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  29    71 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  25    50 
 -----------------------------[snip]------------------------------
  0   0  50  50   0|   0     0 |2230B  346B|   0     0 |  35    61 
  0   0  50  50   0|   0    60M|  70B  346B|   0     0 | 118    83 
  1   7  42  50   0| 256k  104M| 230B  500B|   0     0 | 281   480 
 21   5  31  42   0| 117M   76M|1120B 3392B|   0     0 |1849  4309 
 23   5  36  36   0| 137M   56M|1202B 3958B|   0     0 |2149  5782 
 24   5  36  35   0| 138M  100M|1284B 4112B|   0     0 |2174  6021 

Digamos que, por vários segundos até um minuto, a taxa de leitura e gravação caia para zero. Qual é o gargalo aqui?

Quero dizer, como as duas unidades têm a mesma velocidade, nenhuma delas deve ficar ociosa por muito tempo. Ainda mais, pelo menos uma unidade deve estar sempre lendo ou escrevendo. O que o sistema está esperando?

O sistema está ocioso, só que comer cpu é a tarefa rsync . A memória é de 8 GB, a CPU é um 7-gen i5 quad-core. O HDD interno é conectado via SATA à placa-mãe, um Gigabyte G170X-Ultra Gaming. O sistema de arquivos é ext4 em ambos os casos, criptografado com dmcrypt / LUKS no lado interno (gravação). Pode ser essa a causa? Em caso afirmativo, como verificar o desempenho do dmcrypt? Eu vejo, a CPU está 50% ociosa 50% esperando quando a transferência cai. O que posso concluir disso?

É um Archlinux atualizado com a versão do kernel 4.13.11-1-ARCH . Qualquer coisa para procurar? Agradecemos antecipadamente.

ATUALIZAÇÃO: iotop foi apontado como mais preciso do que dstat . Infelizmente, iotop mostra taxa zero também quando dstat cai para zero. Eu fiz um screencast para mostrá-lo.

    

Answer 1

Existem dois conjuntos de ferramentas para obter estatísticas de dispositivos em nível de bloco. O primeiro é iolatency de Brendan Gregg perf tools . Ele produz um histograma simples de latência de operação do disco, como:

>=(ms) .. <(ms)   : I/O      |Distribution                          |
     0 -> 1       : 1913     |######################################|
     1 -> 2       : 438      |#########                             |
     2 -> 4       : 100      |##                                    |
     4 -> 8       : 145      |###                                   |
     8 -> 16      : 43       |#                                     |
    16 -> 32      : 43       |#                                     |
    32 -> 64      : 1        |#                                     |

Outro script no conjunto de ferramentas é iosnoop , que mostra comandos e suas operações, por exemplo:

COMM         PID    TYPE DEV      BLOCK        BYTES     LATms
/usr/bin/mon 31456  R    8,0      9741888      4096       2.14
/usr/bin/mon 31456  R    8,0      9751408      4096       0.16
/usr/bin/mon 31456  R    8,0      20022728     4096       1.44
/usr/bin/mon 31456  R    8,0      19851752     4096       0.26
jbd2/sda3-41 416    WS   8,0      130618232    65536      1.89
jbd2/sda3-41 416    WS   8,0      209996928    65536      1.92
jbd2/sda3-41 416    WS   8,0      210006528    8192       1.94

Em seguida, há o blktrace pacote que registra operações de bloco de baixo nível com blktrace e, em seguida, mostra todos os tipos de informações com blkparse e muitos outros comandos, incluindo o resumo simples de btt (pdf guia do usuário ):

$ sudo blktrace /dev/sda  # ^C to stop
=== sda ===
  CPU  0:                  180 events,        9 KiB data
  CPU  1:                 1958 events,       92 KiB data
  Total:                  2138 events (dropped 0),      101 KiB data
$ ls -ltra # one file per cpu
-rw-r--r--    1 root   root       8640 Nov  5 10:16 sda.blktrace.0
-rw-r--r--    1 root   root      93992 Nov  5 10:16 sda.blktrace.1
$ blkparse -O -d combined.output  sda.blktrace.*  # combine cpus
$ btt -i combined.output 
    ALL           MIN           AVG           MAX           N
Q2Q               0.000001053   0.106888548   6.376503027         253
Q2G               0.000000795   0.000002266   0.000011060         184
G2I               0.000000874   0.000979485   0.002588781         328
Q2M               0.000000331   0.000000599   0.000002716          70
I2D               0.000000393   0.000480112   0.002435491         328
M2D               0.000002044   0.000028418   0.000126845          70
D2C               0.000080986   0.001925224   0.010111418         254
Q2C               0.000087025   0.002603157   0.010120629         254
...

D2C, por exemplo, é quanto tempo leva o dispositivo de hardware para fazer uma operação.

Você também pode executar sudo smartctl -a /dev/sda em cada disco para ver se há falhas.

    

Answer 2

Eu acho que dstat usa estatísticas de E / S no nível do descritor de arquivo, ou seja, o aplicativo chama write() e, assim que o syscall retorna, os dados que dstat aumentam.

Mas isso não significa que os dados foram realmente escritos. Eu acho que essas pausas aparentes são as fases em que os buffers são gravados no dispositivo de bloco. Faz sentido que durante esses tempos o valor de espera de E / S seja ainda maior do que durante as fases nas quais dstat mede a transferência de dados.

iotop informa as gravações e leituras do disco e do cache. Talvez essa ferramenta possa fornecer informações adicionais interessantes.