Estoy experimentando lo que parece un rendimiento inusualmente bajo de una banda SSD NVMe en un servidor. El hardware es el siguiente:
- Placa base: X9DR3-F
- CPU: doble E5-2650v2
- RAM: 128 GB DDR3-1333 UDIMM (16 x 8 GB)
- Unidades NVMe: 4x MZVLB256HBHQ-000L7 mediante expansor PCIe con carriles bifurcados
lspci -nvvmuestra un enlace 8GT/s x4 para un dispositivo, mostrándolo funcionando en PCIe 3.0 como quiere la unidad: LnkSta: Speed 8GT/s, Width x4. Los puntos de referencia para esta unidad muestran que es capaz de operar con escrituras de alrededor de 1,4 GB/s.
Cuando intento escribir secuencialmente en la unidad, obtengo aproximadamente un tercio de ese rendimiento. Lo siguiente mostró los 619 MB/s durante las escrituras, luego se detuvo durante otros 50 segundos, presumiblemente mientras los datos se vaciaban por completo en el 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
Suponiendo que esto era solo una peculiaridad de mi punto de referencia sintético frente al punto de referencia sintético de otra persona, puse los 4 dispositivos en un MD RAID-0 y lo intenté nuevamente:
$ 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
Mejor, pero mucho que desear. Si hay que creer en las matemáticas de mi educación en escuelas públicas, estas unidades transfieren entre 430x10 y 600x10 megabits por segundo, por lo que el mejor de los casos es 6 gbit. En condiciones ideales, esperaría que las unidades 4x con escritura simple de 0 alcancen los 6 GB, según pruebas comparativas sintéticas de otros. Suponiendo que esto era solo una limitación del sistema, probé la tarjeta Ethernet de 40 gbps no relacionada con un 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
Si bien esta tarjeta de red no tiene nada que ver con el rendimiento de SSD, para mí sí muestra que el sistema es capaz de saturar al menos un enlace de 40 gbit a través de PCIe, especialmente porque esa tarjeta es solo un enlace x8 en lugar de 4x4. Una cosa que puede ser notable es que la tarjeta Ethernet está en CPU1_SLOT1 y los SSD están en CPU2_SLOT4. Sin embargo, no estoy seguro de si eso explicaría la enorme diferencia en el rendimiento, ya que SLOT4 cuelga directamente de la CPU2 y SLOT1 cuelga directamente de la CPU1. Hay un enlace QPI dual de 8GT/s entre las CPU y no hay conmutadores adicionales:
Para mí, vale la pena señalar que el rendimiento de lectura también es correspondientemente bajo. Aquí no hay sobrecarga del sistema de archivos, esto es solo rendimiento flash sin formato y PCIe en efecto. Se trata del rendimiento de lectura de 4x HDD SATA de consumo en RAID-5 en hardware menor, por lo que es absolutamente inaceptablemente 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
La verificación topdurante esta operación de lectura mostró ddun consumo del 100% de la CPU, el 97% en espera del sistema. Los otros 31 hilos estaban más o menos inactivos. ¿Dónde puedo empezar a diagnosticar los problemas de rendimiento experimentados aquí?
Suponiendo que esto era sólo un problema con DD, intenté nuevamente con fio. Conservé el dispositivo MD, lo formateé en XFS permitiéndole elegir la configuración predeterminada, lo monté y ejecuté las pruebas descritas enhttps://cloud.google.com/compute/docs/disks/benchmarking-pd-rendimiento:
escritura secuencial
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%
Escritura aleatoria
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%
Lectura secuencial
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%
Lectura aleatoria
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%
Estos son mucho más rápidos, lo que demuestra que hay una ventaja en que varios subprocesos funcionen en la matriz, pero nuevamente, otros puntos de referencia en línea mostraron que estas unidades realizan escrituras de 1 GB/s individualmente (mientras que estoy alcanzando un máximo de 1,4 GB/s para las 4 combinadas), y yo He visto resultados de UserBenchmark que sitúan las lecturas en 2,2 GB/s por unidad, por lo que las lecturas de 6 GB/s funcionan bastante bien en contexto.
Entonces, ¿hay algo que hacer para mejorar el rendimiento de un solo proceso?
Respuesta1
Samsung MZVLB256HBHQ-000L7 son SSD pequeños (256 GB), por lo que se encontrará con el cuello de botella del ancho de banda NAND interno para cualquier escritura que abarque varios GB. Puedes recortarlos (perder todos los datos almacenados actualmente en las unidades) para limpiar el caché interno de pSLC, alcanzando más ancho de banda para las primeras pruebas, pero rápidamente lo saturarás nuevamente.
Respuesta2
Mi experiencia con las unidades Samsung MZVL* es pésima. Verhttps://superuser.com/questions/1721288/ssd-performance-falls-off-a-cliff
Estoy tratando de encontrar especificaciones confiables en su disco, pero mi principal suposición es que a los discos les falta DRAM.
Respuesta3
Bueno, odio hacerlo, pero en última instancia debería responder y cerrar la pregunta. El PM981 conducehacertienen un caché DRAM de 512 MB y también ofrecen un caché SLC de 12 GB, por lo que deberían ser rápidos. Cuatro de ellos en un RAID-0 deberían gritar.
https://www.techpowerup.com/ssd-specs/samsung-pm981a-256-gb.d784
En su lugar, compré un NAS porque nunca resolví esto.