Baixo desempenho inesperado com unidades NVMe em um X9DR3-F

Baixo desempenho inesperado com unidades NVMe em um X9DR3-F

Estou experimentando o que parece ser um desempenho anormalmente baixo de uma faixa SSD NVMe em um servidor. O hardware é o seguinte:

  • Placa-mãe: X9DR3-F
  • CPU: Dual E5-2650v2
  • RAM: 128 GB DDR3-1333 UDIMM (16x8 GB)
  • Unidades NVMe: 4x MZVLB256HBHQ-000L7 via expansor PCIe com pistas bifurcadas

lspci -nvvmostra um link 8GT/s x4 para um dispositivo, mostrando-o operando em PCIe 3.0 como o drive deseja: LnkSta: Speed 8GT/s, Width x4. Os benchmarks para esta unidade mostram que ela é capaz de operar em torno de gravações de 1,4 GB/s.

Quando tento gravações sequenciais na unidade, obtenho cerca de um terço desse desempenho. O seguinte mostrou 619 MB/s durante as gravações e, em seguida, pausou por mais 50 segundos, provavelmente enquanto os dados eram totalmente descarregados no disco.

$ sudo dd if=/dev/zero of=/dev/nvme1n1 bs=16M count=1k status=progress
16726884352 bytes (17 GB, 16 GiB) copied, 27 s, 619 MB/s
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 71.8953 s, 239 MB/s

Supondo que isso fosse apenas uma peculiaridade do meu benchmark sintético versus o benchmark sintético de outra pessoa, coloquei todos os 4 dispositivos em um MD RAID-0 e tentei novamente:

$ sudo mdadm --create /dev/md0 --level=0 --raid-devices=4 --force --run /dev/nvme?n1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
$ sudo dd if=/dev/zero of=/dev/md0 bs=16M count=2k status=progress
34191966208 bytes (34 GB, 32 GiB) copied, 57 s, 600 MB/s
2048+0 records in
2048+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 79.7502 s, 431 MB/s

Melhor, mas muito a desejar. Se acreditarmos na minha matemática da educação escolar pública, essas unidades estão transferindo algo entre 430x10 e 600x10 megabits por segundo, portanto, o melhor cenário é 6gbit. Em condições ideais, eu esperaria que unidades 4x em gravações simples com todos os 0 atingissem 6 GByte, com base em benchmarks sintéticos de outros. Supondo que isso fosse apenas alguma limitação do sistema, testei a placa Ethernet de 40 Gbps não relacionada em um host diferente:

$ iperf -c 10.x.x.x -P 4
------------------------------------------------------------
Client connecting to 10.x.x.x, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  2] local 10.x.x.x port 53750 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/196)
[  1] local 10.x.x.x port 53754 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/132)
[  3] local 10.x.x.x port 53738 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/212)
[  4] local 10.x.x.x port 53756 connected with 10.x.x.x port 5001 (icwnd/mss/irtt=87/8948/107)
[ ID] Interval       Transfer     Bandwidth
[  2] 0.0000-10.0027 sec  12.4 GBytes  10.6 Gbits/sec
[  1] 0.0000-10.0180 sec  12.7 GBytes  10.9 Gbits/sec
[  3] 0.0000-10.0179 sec  10.6 GBytes  9.05 Gbits/sec
[  4] 0.0000-10.0180 sec  10.5 GBytes  8.97 Gbits/sec
[SUM] 0.0000-10.0011 sec  46.1 GBytes  39.6 Gbits/sec

Embora esta placa de rede não tenha nada a ver com o desempenho do SSD, para mim ela mostra que o sistema é capaz de saturar pelo menos um link de 40 Gbit via PCIe, especialmente porque essa placa é apenas um link x8 em vez de 4x4. Uma coisa que pode ser digna de nota é que a placa Ethernet está em CPU1_SLOT1 e os SSDs estão em CPU2_SLOT4. Não tenho certeza se isso explicaria a enorme diferença no desempenho, já que o SLOT4 está pendurado diretamente na CPU2 e o SLOT1 está pendurado diretamente na CPU1. Há um link QPI duplo de 8GT/s entre as CPUs e nenhum switch adicional: Diagrama de blocos X9DR3-F

Para mim, é importante notar que o desempenho de leitura também é correspondentemente baixo. Não há sobrecarga do sistema de arquivos aqui, isso é apenas flash bruto e desempenho PCIe em vigor. Trata-se do desempenho de leitura de 4x HDDs SATA de consumo em RAID-5 em hardware menor, portanto, absolutamente inaceitavelmente lento:

$ sudo dd if=/dev/md0 of=/dev/null bs=16M count=8k
8192+0 records in
8192+0 records out
137438953472 bytes (137 GB, 128 GiB) copied, 214.738 s, 640 MB/s

A verificação topdurante esta operação de leitura mostrou ddconsumo de 100% da CPU, 97% dela em espera do sistema. Os outros 31 threads estavam mais ou menos ociosos. Onde posso começar a diagnosticar os problemas de desempenho enfrentados aqui?


Supondo que isso fosse apenas um problema com o DD, tentei novamente com o fio. Eu mantive o dispositivo MD, formatei-o em XFS permitindo que ele escolhesse as configurações padrão, montei-o e executei os testes descritos emhttps://cloud.google.com/compute/docs/disks/benchmarking-pd-performance:

Gravação sequencial

Run status group 0 (all jobs):
  WRITE: bw=1348MiB/s (1414MB/s), 1348MiB/s-1348MiB/s (1414MB/s-1414MB/s), io=80.8GiB (86.7GB), run=61368-61368msec

Disk stats (read/write):
    md0: ios=0/710145, merge=0/0, ticks=0/397607236, in_queue=397607236, util=99.82%, aggrios=0/177558, aggrmerge=0/2, aggrticks=0/99452549, aggrin_queue=99465067, aggrutil=99.62%
  nvme0n1: ios=0/177568, merge=0/5, ticks=0/56627328, in_queue=56635784, util=97.96%
  nvme3n1: ios=0/177536, merge=0/1, ticks=0/145315089, in_queue=145331709, util=99.62%
  nvme2n1: ios=0/177559, merge=0/3, ticks=0/151148103, in_queue=151165889, util=99.44%
  nvme1n1: ios=0/177569, merge=0/0, ticks=0/44719677, in_queue=44726889, util=97.87%

Escrita aleatória

Run status group 0 (all jobs):
  WRITE: bw=101MiB/s (106MB/s), 101MiB/s-101MiB/s (106MB/s-106MB/s), io=6074MiB (6370MB), run=60003-60003msec

Disk stats (read/write):
    md0: ios=0/1604751, merge=0/0, ticks=0/623304, in_queue=623304, util=100.00%, aggrios=0/401191, aggrmerge=0/2, aggrticks=0/153667, aggrin_queue=153687, aggrutil=99.99%
  nvme0n1: ios=0/402231, merge=0/3, ticks=0/156754, in_queue=156775, util=99.98%
  nvme3n1: ios=0/401144, merge=0/2, ticks=0/149648, in_queue=149667, util=99.98%
  nvme2n1: ios=0/400158, merge=0/0, ticks=0/150380, in_queue=150400, util=99.98%
  nvme1n1: ios=0/401233, merge=0/4, ticks=0/157887, in_queue=157908, util=99.99%

Leitura sequencial

Run status group 0 (all jobs):
   READ: bw=6244MiB/s (6547MB/s), 6244MiB/s-6244MiB/s (6547MB/s-6547MB/s), io=367GiB (394GB), run=60234-60234msec

Disk stats (read/write):
    md0: ios=3089473/14, merge=0/0, ticks=272954324/220, in_queue=272954544, util=99.98%, aggrios=779529/3, aggrmerge=6/1, aggrticks=68744470/104, aggrin_queue=68744621, aggrutil=99.60%
  nvme0n1: ios=779520/6, merge=12/2, ticks=24023533/1, in_queue=24023534, util=98.84%
  nvme3n1: ios=779519/2, merge=14/0, ticks=145571896/378, in_queue=145572449, util=99.60%
  nvme2n1: ios=779536/3, merge=0/1, ticks=77038488/3, in_queue=77038492, util=98.90%
  nvme1n1: ios=779544/3, merge=0/1, ticks=28343963/34, in_queue=28344012, util=98.81%

Leitura aleatória

Run status group 0 (all jobs):
   READ: bw=372MiB/s (390MB/s), 372MiB/s-372MiB/s (390MB/s-390MB/s), io=21.8GiB (23.4GB), run=60002-60002msec

Disk stats (read/write):
    md0: ios=5902401/10, merge=0/0, ticks=2684388/0, in_queue=2684388, util=100.00%, aggrios=1475009/3, aggrmerge=608/0, aggrticks=685706/0, aggrin_queue=685706, aggrutil=99.90%
  nvme0n1: ios=1475288/4, merge=632/1, ticks=697246/0, in_queue=697246, util=99.89%
  nvme3n1: ios=1475328/2, merge=611/0, ticks=678849/1, in_queue=678850, util=99.89%
  nvme2n1: ios=1474625/3, merge=588/1, ticks=673908/0, in_queue=673909, util=99.90%
  nvme1n1: ios=1474795/3, merge=602/0, ticks=692822/1, in_queue=692822, util=99.90%

Eles são muito mais rápidos, mostrando que há uma vantagem em vários threads batendo no array, mas novamente outros benchmarks on-line mostraram essas unidades fazendo gravações de 1 GB/s individualmente (enquanto estou atingindo um pico de 1,4 GB/s para todos os 4 combinados), e eu Vi resultados do UserBenchmark colocando leituras em 2,2 GB/s por unidade, portanto, leituras de 6 GB/s estão indo muito bem no contexto.

Há algo a ser feito para melhorar o desempenho de um único processo?

Responder1

Samsung MZVLB256HBHQ-000L7 são SSDs pequenos (256 GB), então você atingirá o gargalo de largura de banda NAND interno para qualquer gravação que abranja vários GB. Você pode apará-los (perder todos os dados atualmente armazenados nas unidades) para limpar o cache interno do pSLC, obtendo mais largura de banda para os primeiros benchmarks, mas você irá saturá-lo novamente rapidamente.

Responder2

Minha experiência com unidades Samsung MZVL* é péssima. Verhttps://superuser.com/questions/1721288/ssd-performance-falls-off-a-cliff

Estou tentando encontrar especificações confiáveis ​​em sua unidade, mas meu principal palpite é que falta DRAM nas unidades.

Responder3

Bem, odeio fazer isso, mas, em última análise, devo responder e encerrar a pergunta. As unidades PM981fazertêm um cache DRAM de 512 MB e também oferecem um cache SLC de 12 GB, portanto, devem ser rápidos. Quatro deles em um RAID-0 deveriam gritar.

https://www.techpowerup.com/ssd-specs/samsung-pm981a-256-gb.d784

Acabei de comprar um NAS, pois nunca resolvi isso.

informação relacionada