Неожиданно низкая производительность с дисками NVMe на X9DR3-F

Неожиданно низкая производительность с дисками NVMe на X9DR3-F

Я испытываю то, что кажется нехарактерно низкой производительностью полосы NVMe SSD на сервере. Аппаратное обеспечение следующее:

  • Материнская плата: X9DR3-F
  • Процессор: Двойной E5-2650v2
  • ОЗУ: 128 ГБ DDR3-1333 UDIMM (16x8 ГБ)
  • Накопители NVMe: 4x MZVLB256HBHQ-000L7 через расширитель PCIe с раздвоенными полосами

lspci -nvvпоказывает соединение 8 ГТ/с x4 для устройства, показывая, что оно работает на PCIe 3.0, как и требуется диску: LnkSta: Speed 8GT/s, Width x4. Тесты для этого диска показывают, что он способен работать со скоростью записи около 1,4 ГБ/с.

Когда я пробую последовательную запись на диск, я получаю около трети этой производительности. Ниже показано 619 МБ/с во время записи, затем пауза еще на 50 секунд, предположительно, пока данные полностью сбрасывались на диск.

$ 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

Предположив, что это просто какая-то странность моего синтетического теста по сравнению с чьим-то другим синтетическим тестом, я поместил все 4 устройства в MD RAID-0 и попробовал еще раз:

$ 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

Лучше, но желать лучшего. Если верить моей математике из государственного школьного образования, эти диски передают данные со скоростью от 430x10 до 600x10 мегабит в секунду, то есть в лучшем случае 6 Гбит. В идеальных условиях я бы ожидал, что 4x диски в простых полосовых записях со всеми нулями будут достигать 6 Гбайт, основываясь на синтетических тестах других. Предположив, что это просто какое-то ограничение системы, я протестировал несвязанную 40-гигабитную сетевую карту с другим хостом:

$ 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

Хотя эта сетевая карта не имеет никакого отношения к производительности SSD, на мой взгляд, она показывает, что система способна загрузить как минимум 40-гигабитное соединение через PCIe, тем более что эта карта имеет только соединение x8, а не 4x4. Обратите внимание, что сетевая карта находится в слоте CPU1_SLOT1, а твердотельные накопители — в слоте CPU2_SLOT4. Я не уверен, что это объясняет огромную разницу в производительности, поскольку SLOT4 напрямую связан с CPU2, а SLOT1 напрямую связан с CPU1. Между CPU есть двойная связь QPI 8GT/s и никаких дополнительных коммутаторов: Блок-схема X9DR3-F

Для меня стоит отметить, что производительность чтения также соответственно низкая. Здесь нет накладных расходов файловой системы, это просто сырая производительность флэш-памяти и PCIe. Это примерно производительность чтения 4x потребительских SATA HDD в RAID-5 на менее мощном оборудовании, так что просто неприемлемо медленно:

$ 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

Проверка topво время этой операции чтения показала ddпотребление 100% CPU, 97% из которых в системном ожидании. Остальные 31 поток были более или менее бездействующими. Где я могу начать диагностику проблем производительности, которые здесь наблюдаются?


Предположив, что проблема только в DD, я попробовал снова с fio. Я сохранил устройство MD, отформатировал его в XFS, позволив ему выбрать настройки по умолчанию, смонтировал его и провел тесты, описанные вhttps://cloud.google.com/compute/docs/disks/benchmarking-pd-performance:

Последовательная запись

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%

Случайная запись

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%

Последовательное чтение

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%

Случайное чтение

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%

Они намного быстрее, что показывает, что есть преимущество в том, что несколько потоков обгоняют массив, но, опять же, другие онлайн-тесты показали, что эти диски выполняют запись со скоростью 1 ГБ/с по отдельности (тогда как у меня пиковая скорость составляет 1,4 ГБ/с для всех 4 дисков вместе), и я видел результаты UserBenchmark, показывающие скорость чтения 2,2 ГБ/с на диск, так что чтение 6 ГБ/с в этом контексте — это довольно неплохо.

Можно ли что-то сделать для улучшения производительности отдельного процесса?

решение1

Samsung MZVLB256HBHQ-000L7 — это небольшие SSD-накопители (256 ГБ), поэтому вы столкнетесь с внутренним узким местом пропускной способности NAND для любых записей, охватывающих несколько ГБ. Вы можете обрезать их (потеря всех данных, хранящихся на дисках) для очистки внутреннего кэша pSLC, что обеспечивает большую пропускную способность для первых тестов, но вы снова быстро его переполните.

решение2

Мой опыт работы с дисками Samsung MZVL* ужасен. Смотретьhttps://superuser.com/questions/1721288/ssd-performance-falls-off-a-cliff

Я пытаюсь найти достоверные характеристики вашего накопителя, но моя главная догадка заключается в том, что на нем отсутствует DRAM.

решение3

Ну, мне не хочется этого делать, но в конечном итоге я должен ответить и закрыть вопрос. PM981 управляетделатьимеют кэш DRAM 512 МБ, а также предлагают кэш SLC 12 ГБ, так что они должны быть быстрыми. Четыре из них в RAID-0 должны кричать.

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

Я просто купил NAS, так как так и не решил эту проблему.

Связанный контент