Má desempenho de SSD de leitura aleatória no Linux

Question

Recentemente, recebi uma Intel SSD da série 320 e estou com dificuldades para alcançar as 38O IOPS anunciadas para leituras aleatórias de 4K.

Ambos com o fio e meu próprio programa hackeado, estou vendo em torno de 6K IOPS. É quase como se o tamanho da profundidade do IO não importasse, e o kernel está tentando buscar um bloco de cada vez.

Exemplo:

$ cat job
[randread]
filename=/dev/sdb2
rw=randread
size=128m
blocksize=4k
ioengine=libaio
iodepth=64
direct=1

$ sudo fio job
randread: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [25423K/0K /s] [6207/0 iops] [eta 00m:00s]
randread: (groupid=0, jobs=1): err= 0: pid=4678
  read : io=131072KB, bw=24852KB/s, iops=6213, runt=  5274msec
    slat (usec): min=1, max=94, avg= 5.00, stdev= 2.88
    clat (usec): min=312, max=13070, avg=10290.25, stdev=1399.78
    bw (KB/s) : min=23192, max=24464, per=97.08%, avg=24125.60, stdev=383.70
  cpu          : usr=15.74%, sys=22.57%, ctx=31642, majf=0, minf=88
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.8%
     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.1%, >=64=0.0%
     issued r/w: total=32768/0, short=0/0
     lat (usec): 500=0.01%, 750=0.01%, 1000=0.03%
     lat (msec): 2=0.05%, 4=0.10%, 10=20.10%, 20=79.70%

Run status group 0 (all jobs):
   READ: io=131072KB, aggrb=24852KB/s, minb=25448KB/s, maxb=25448KB/s, mint=5274msec, maxt=5274msec

Disk stats (read/write):
  sdb: ios=30453/0, merge=850/0, ticks=319060/0, in_queue=319060, util=98.09%

O sistema é Linux 2.6.35-31-generic #63-Ubuntu SMP Mon Nov 28 19:29:10 UTC 2011 x86_64 GNU/Linux . /dev/sdb2 acima é uma partição ~ 10GB em um SSD de 80GB. fio é a versão 1.38.

Eu realmente aprecio pensamentos sobre o que pode estar errado.

PS: A partição no teste acima (/ dev / sdb2) está alinhada em um limite de 4K. Ler de uma extensão maior (tamanho = 10g) não ajuda.

    

Answer 1

Suas partições estão alinhadas corretamente ? Se você não está iniciando sua partição em um limite de 4k, nenhuma de suas 4k leituras se alinhará, gerando cruzamentos de limite e, na pior das hipóteses, duplicando sua E / S.

    

Answer 2

Veja a discussão em Posso configurar meu sistema Linux para um armazenamento em cache mais agressivo do sistema de arquivos?

Em resumo, você provavelmente precisará ajustar algumas configurações de fila de dispositivos. Eu acho que o agendamento ou configuração de fila é incorretamente adivinhada pelo kernel ou manualmente definido.

Tente

grep . /sys/block/sd*/{queue/{nr_requests,nomerges,rotational,scheduler},device/queue_depth}

e

lsblk

para depurar o problema. Você deve ter queue_depth e nr_requests configurado para pelo menos 31 se puder tolerar a latência de uma única leitura causada pelo NCQ, nomerges deve ser zero e rotational deve ser zero para SSD. Selecionar o scheduler correto será mais difícil, mas para IOPS brutos, noop deve ser bom o suficiente. Eu encontrei corretamente ajustado cfq para lidar com os requisitos do mundo real um pouco melhor.

E certifique-se de que o disco esteja conectado com SATA + AHCI e você tenha o NCQ ativado. Caso contrário, há pouca esperança de obter tudo do seu disco.