ips realmente baixos no ataque ssd (menor que 1000)

2

Estou tendo sérios problemas de desempenho em um servidor, com iops muito baixos.

servidor:

  • ProLiant DL360p Gen8
  • com o controlador HP Smart Array P420i (firmware v6)
  • com 4x Samsung 840 - 512 GB no ataque 1 + 0

aqui está um samsung 840 detalhes:

hpacucli ctrl slot=0 pd 2I:1:6 show detail
physicaldrive 2I:1:6
Port: 2I
Box: 1
Bay: 6
Status: OK
Drive Type: Data Drive
Interface Type: Solid State SATA
Size: 512.1 GB
Firmware Revision: DXM04B0Q
Serial Number: S12SNEAD102607E
Model: ATA     Samsung SSD 840
SATA NCQ Capable: True
SATA NCQ Enabled: True
Current Temperature (C): 16
Maximum Temperature (C): 70
Usage remaining: 100.00%
Power On Hours: 0
SSD Smart Trip Wearout: False
PHY Count: 1
PHY Transfer Rate: 6.0Gbps
Drive Authentication Status: OK
Carrier Application Version: 11
Carrier Bootloader Version: 6

e aqui está o resultado de referência

sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
    test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
    fio-2.1.3
    Starting 1 process
    test: Laying out IO file(s) (1 file(s) / 4096MB)
    Jobs: 1 (f=1): [m] [99.8% done] [7152KB/2400KB/0KB /s] [1788/600/0 iops] [eta 00m:02s]
    test: (groupid=0, jobs=1): err= 0: pid=36718: Thu Mar  5 18:15:12 2015
    read : io=3071.7MB, bw=2536.5KB/s, iops=634, runt=1240097msec
    write: io=1024.4MB, bw=866133B/s, iops=211, runt=1240097msec
    cpu          : usr=0.28%, sys=1.18%, ctx=401767, majf=0, minf=2347
    IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
    issued    : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0
    Run status group 0 (all jobs):
    READ: io=3071.7MB, aggrb=2536KB/s, minb=2536KB/s, maxb=2536KB/s, mint=1240097msec, maxt=1240097msec
    WRITE: io=1024.4MB, aggrb=845KB/s, minb=845KB/s, maxb=845KB/s, mint=1240097msec, maxt=1240097msec
    Disk stats (read/write):
    dm-1: ios=785968/267543, merge=0/0, ticks=50476776/28341176, in_queue=79704028, util=100.00%, aggrios=788659/265218, aggrmerge=1953/2589, aggrticks=50709304/27483028, aggrin_queue=78191444, aggrutil=100.00%
    sda: ios=788659/265218, merge=1953/2589, ticks=50709304/27483028, in_queue=78191444, util=100.00%

executar o mesmo banco no hdd normal mostra mais yops do que no ssd

Alguma ideia?

    
por Charly Koza 05.03.2015 / 19:07

1 resposta

2

Devido à forma como os SSDs do MLC funcionam, eles precisam de um cache DRAM local de tamanho decente para absorver as gravações recebidas e, ao mesmo tempo, gravar no NAND auxiliar.

No entanto, as placas RAID de hardware frequentemente desativam o cache do disco e contam exclusivamente com o próprio cache DRAM (no cartão). Embora isso não seja um problema com o HDD clássico, a natureza intrínseca de não-sobrescrita dos chips NAND (e os SSDs construídos sobre eles) causam uma perda massiva de desempenho se o cache DRAM interno não puder ser usado.

Para dar um exemplo: um Crucial M550 de 256 GB, com gravação sequencial de mais de 400 MB / s, cai para 5 MB / s com cache interno desativado. Com a gravação aleatória, a perda é igualmente severa. Esta é a razão exata pela qual o SSD corporativo usava (no passado) NANDs do SLC: o tempo de programação é bem menor comparado ao MLC ou mesmo ao eMLC.

Por esse motivo, estou sempre um pouco nervoso ao combinar SSDs de classe de consumidor com cartões RAID de hardware de marca. Por outro lado, o Linux mdraid funciona fantasticamente bem com SSDs de qualquer classe.

Para o caso específico, você pode fazer algum teste tentando reativar o cache de disco interno (o controlador DELL / LSI fornece essa possibilidade, eu não sei sobre o controlador HP). No entanto, lembre-se de que, com o cache de gravação do disco ativado, você fica exposto à perda de dados no caso de falta de energia (a menos que seus discos tenham proteção contra perda de energia, mas isso é muito raro no espaço do consumidor).

    
por 05.03.2015 / 22:26