SSD IOPS no linux, DIRECT muito mais rápido que buffered, fio

Question

Eu tenho um sistema RAID-6 de hardware de 30 TB (LSI 9280-8e) de 10 SSDs DC-S4500 da Intel usado para fins de banco de dados. O Debian OS 7.11 com o kernel 3.2. O sistema de arquivos é montado pelo XFS com a opção nobarrier.

Vendo um pouco lento comparando com o desempenho das minhas expectativas em E / S aleatória, comecei a investigar o que está acontecendo, executando benchmarks da empresa. E para minha surpresa, quando eu usei o fio em um arquivo de 1 TB em configurações de leitura aleatória com (iodepth = 32 e ioengine = libaio) recebo ~ 3000 IOPS que é muito menor do que eu esperava.

random-read: (groupid=0, jobs=1): err= 0: pid=128531
  read : io=233364KB, bw=19149KB/s, iops=4787 , runt= 12187msec
  ...
  cpu          : usr=1.94%, sys=5.81%, ctx=58484, majf=0, minf=53
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=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.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=58341/w=0/d=0, short=r=0/w=0/d=0

No entanto, se eu usar a opção direct = 1 (ou seja, ignorando o cache de buffer do Linux), recebo ~ 40000 IOPS, o que eu gostaria de ver.

random-read: (groupid=0, jobs=1): err= 0: pid=130252
  read : io=2063.7MB, bw=182028KB/s, iops=45507 , runt= 11609msec
....
  cpu          : usr=6.93%, sys=23.29%, ctx=56503, majf=0, minf=54
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.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.1%, 64=0.0%, >=64=0.0%
     issued    : total=r=528291/w=0/d=0, short=r=0/w=0/d=0

Eu pareço ter todas as configurações certas para a partição SSD na forma de o agendador, leitura antecipada e configuração rotacional.

root@XX:~# cat /sys/block/sdd/queue/scheduler
[noop] deadline cfq 
root@XX:~# cat /sys/block/sdd/queue/rotational
0
root@XX:~# blockdev --getra /dev/sdd
0

Ainda estou sentindo falta de algo que reduz tanto o desempenho do buffer? Ou espera-se ver tal diferença entre o buffer vs DIRECT?

Também observei a saída do iostat durante duas execuções Isto é quando direto = 1 foi usado:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdd               0.00     0.00 48110.00    0.00 192544.00     0.00     8.00    27.83    0.58    0.58    0.00   0.02  99.60

Esta é uma execução em buffer

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdd               0.00     0.00 4863.00    0.00 19780.00     0.00     8.13     0.89    0.18    0.18    0.00   0.18  85.60

Portanto, parece que a principal diferença é o tamanho da fila (avgqu-sz), que é pequeno ao usar E / S armazenada em buffer. Acho estranho, já que nr_requests e queue_depth são todos altos:

root@XX:~# cat /sys/block/sdd/queue/nr_requests
128
root@XX:~# cat /sys/block/sda/device/queue_depth
256

Algum conselho aqui?

    

Answer 1

Debian 7.11 with 3.2 kernel

Atualize, se possível. Você não apenas obtém melhorias no kernel, mas o Wheezy é o fim da vida.

Sim, você vê maior utilização e profundidade da fila quando direta = 1. O manual do fio chama este caso em particular (ênfase minha):

iodepth=int

Number of I/O units to keep in flight against the file. Note that increasing iodepth beyond 1 will not affect synchronous ioengines (except for small degrees when verify_async is in use). Even async engines may impose OS restrictions causing the desired depth not to be achieved. This may happen on Linux when using libaio and not setting direct=1, since buffered I/O is not async on that OS. Keep an eye on the I/O depth distribution in the fio output to verify that the achieved depth is as expected

Portanto, a libaio requer O_DIRECT para assíncrono, um importante detalhe de implementação a ser conhecido. Alguém perguntou se não era direto com a libaio era uma boa ideia:

Is it valid to set direct=0 when using libaio?

You can do it but I wouldn't recommend it. With today's Linux kernels, libaio submission is likely to become blocking (and thus no longer asynchronous) without O_DIRECT which can limit the amount of parallel I/O achieved. There's a strong argument that fio examples should NOT encourage such a combination of options...

what does "queued" behavior mean in the man doc?

     

Se você quer dizer o   frase "Note que o Linux só pode suportar comportamento em fila com   E / S sem buffer "    link ) Eu acho   está tentando dizer:

     

"Em vez de bloquear no syscall da submissão até que o I / O tenha ido   para baixo e voltar do dispositivo de disco mais baixo (comportamento de bloqueio),   quando usando direto = 1 com libaio você pode enviar um I / O e tê-lo   assincronamente em fila pelo kernel permitindo a submissão syscall para   volte imediatamente e abra a oportunidade para você fazer fila   outros envios antes da conclusão da E / S ".

Tente também um teste de controle com ioengine = psync e direct = 0. Mesmo as gravações síncronas com um cache podem fazer muitas IOPS.

Tudo isso evita a verdadeira pergunta: qual era o problema na carga de trabalho do banco de dados que você estava executando? Sintomas do problema, versões de software, configuração, métricas de desempenho (iostat). A implementação de E / S do SGBD pode ser muito diferente do que você simulou, as chamadas do sistema usadas, vários arquivos e tarefas que executam E / S, qualquer número de coisas. Isso vale a sua própria pergunta se você quiser investigar mais.