☰

Низкая производительность записи программного массива RAID10 из 8 SSD-дисков

tag-icon • tag-icon linux raid storage software-raid ssd
Низкая производительность записи программного массива RAID10 из 8 SSD-дисков

У меня есть сервер с материнской платой Supermicro X10DRW-i и массивом RAID10 из 8 твердотельных накопителей KINGSTON SKC400S; ОС — CentOS 6.

  # cat /proc/mdstat 
Personalities : [raid10] [raid1] 

md2 : active raid10 sdj3[9](S) sde3[4] sdi3[8] sdd3[3] sdg3[6] sdf3[5] sdh3[7] sdb3[1] sda3[0]
      3978989568 blocks super 1.1 512K chunks 2 near-copies [8/8] [UUUUUUUU]
      bitmap: 9/30 pages [36KB], 65536KB chunk

—

  # mdadm --detail /dev/md2                
    /dev/md2:
            Version : 1.1
      Creation Time : Wed Feb  8 18:35:14 2017
         Raid Level : raid10
         Array Size : 3978989568 (3794.66 GiB 4074.49 GB)
      Used Dev Size : 994747392 (948.67 GiB 1018.62 GB)
       Raid Devices : 8
      Total Devices : 9
        Persistence : Superblock is persistent

      Intent Bitmap : Internal

        Update Time : Fri Sep 14 15:19:51 2018
              State : active 
     Active Devices : 8
    Working Devices : 9
     Failed Devices : 0
      Spare Devices : 1

             Layout : near=2
         Chunk Size : 512K

               Name : ---------:2  (local to host -------)
               UUID : 8a945a7a:1d43dfb2:cdcf8665:ff607a1b
             Events : 601432

        Number   Major   Minor   RaidDevice State
           0       8        3        0      active sync set-A   /dev/sda3
           1       8       19        1      active sync set-B   /dev/sdb3
           8       8      131        2      active sync set-A   /dev/sdi3
           3       8       51        3      active sync set-B   /dev/sdd3
           4       8       67        4      active sync set-A   /dev/sde3
           5       8       83        5      active sync set-B   /dev/sdf3
           6       8       99        6      active sync set-A   /dev/sdg3
           7       8      115        7      active sync set-B   /dev/sdh3

           9       8      147        -      spare   /dev/sdj3

Я заметил, что скорость записи просто ужасная, даже близко не сравнимая с производительностью SSD.

# dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=dsync      
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 16.511 s, 65.0 MB/s

Скорость чтения хорошая, но

# hdparm -tT /dev/md2

/dev/md2:
 Timing cached reads:   20240 MB in  1.99 seconds = 10154.24 MB/sec
 Timing buffered disk reads: 3478 MB in  3.00 seconds = 1158.61 MB/sec

После устранения неполадок я обнаружил, что, вероятно, изначально перепутал конфигурацию хранилища: X10DRW-i имеет Intel C610 с двумя отдельными контроллерами SATA, 6-портовым SATA и 4-портовым sSATA. Таким образом, диски в массиве подключены к разным контроллерам, и я считаю, что это основная причина низкой производительности. У меня есть только одна идея, как это исправить: установить контроллер PCIe SAS (вероятно, AOC-S3008L-L8E) и подключить к нему SSD-накопители.

Поэтому я хотел бы подтвердить следующее:

Прав ли я относительно первопричины или мне следует что-то перепроверить?

Будет ли работать мое решение?

Если я переподключу диски к новому контроллеру, сохранятся ли мой RAID и данные? Мои исследования показывают, что да, поскольку UUID разделов останутся прежними, но я просто хочу быть уверен.

Заранее всем спасибо.

UPD: iostat -x 1во время выполнения теста dd:https://pastebin.com/aTfRYriU

# hdparm /dev/sda                                    

/dev/sda:
 multcount     = 16 (on)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 124519/255/63, sectors = 2000409264, start = 0

—

# cat /sys/block/md2/queue/scheduler                 
none

Хотя, насколько мне известно, планировщик настроен на физические диски:

# cat /sys/block/sda/queue/scheduler 
noop anticipatory [deadline] cfq

—

smartctl -a(на устройствах, а не на разделах):https://pastebin.com/HcBp7gUH

ОБНОВЛЕНИЕ2:

# dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 14.389 s, 74.6 MB/s

ОБНОВЛЕНИЕ3:

Я только что запустил fstrimраздел / и получилнекоторыйэффект, скорость записи по-прежнему слишком низкая: 227 МБ/с, 162 МБ/с, 112 МБ/с, 341 МБ/с, 202 МБ/с в пяти последовательных тестах.

решение1

Измеренные низкие показатели являются результатом различных факторов:

  • после создания массив полностью синхронизируется, что приводит к размещению большинства (если не всех) страниц флэш-данных на половине SSD. Это переведет SSD в состояние низкой производительности, пока безопасное стирание/обрезка не «освободит» все/большинство/некоторые страницы. Это объясняет возросшую производительность после fstrim;
  • размер фрагмента (по умолчанию) 512 КБ слишком велик для максимальной последовательной/потоковой производительности (согласно результатам тестирования dd). С массивом из одних SSD я бы выбрал размер фрагмента 64 КБ и, вероятно (но это должно быть подтверждено реальным тестом), с "дальней" компоновкой. Обратите внимание, что уменьшение размера фрагмента, хотя и полезно для потокового доступа, может наказать за случайное чтение/запись. Это в основном касается HDD, но даже SSD могут быть в некоторой степени затронуты;
  • по умолчанию ядро ​​linux выдает максимум 512 КБ ввода-вывода. Это означает, что даже при запросе ddиспользования блоков размером 1 ГБ (как в вашей первой команде) они будут разделены на множество запросов размером 512 КБ. В сочетании с вашим 512 КБ-куском это задействуетодин SSD на запрос записи, в основном ограничивая производительность потоковой записи на уровне одного SSD и отрицая любое потенциальное увеличение скорости из-за RAID. Хотя вы можете использовать max_sectors_kbнастраиваемый параметр (найденный в /sys/block/sdX/queue/max_sectors_kb), значения больше 512 КБ могут (в некоторых версиях конфигурации/ядра) игнорироваться;
  • наконец, хотя это и интересно и обязательно для первой остановки, ddсамо по себе является плохим бенчмарком: он тестирует только производительность потоковой передачи при низкой (1) глубине очереди. Даже с вашей текущей конфигурацией массива более полный тест, как fioпоказал бы значительное увеличение производительности по сравнению со сценарием с одним диском, по крайней мере при случайном вводе-выводе.

Что вы можете сделать, чтобы исправить текущую ситуацию? Прежде всего, выдолженсогласитесь стереть диски/массив; очевидно, вынуждатьсясделать резервные копии в качестве первого шага. Затем:

  • остановить и удалить массив ( mdadm -S /dev/md2)
  • подрезатьвсеблоки данных налюбойдиск ( blkdiscard /dev/sdX3)
  • воссоздать массив с кусками по 64 КБ и счистыйфлаг ( mdadm --create /dev/md2 --level=10 --raid-devices=8 --chunk=64 --assume-clean /dev/sdX3)
  • переснять с помощью ddи fio;
  • Если все в порядке, восстановите резервную копию.

Последнее замечание о вашей настройке SATA: явно следует избегать такого разделения диска, чтобы получить максимальную производительность. Тем не менее, ваша скорость записи настолько низкая, что я бы не стал винить ваш контроллер SATA. Я бы действительно пересоздал массив по инструкции выше, прежде чем покупать что-то новое.

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