Программный RAID10 на Linux (SSD) стал ужасно медленным

Вопрос или проблема

Я управляю сервером Supermicro (2x AMD EPYC 7282, 128 ГБ) с 8 дисками более 5 лет. Сервер работает под управлением Debian Linux и обслуживает множество виртуальных машин с различной нагрузкой (почта, Nextcloud, веб-сайты). 8 дисков разделены на три программных устройства RAID. Три диска формируют RAID1 (со spare-диском), используя SSD, в то время как остальные 5 дисков задействованы в двух RAID10. В прошлом году в июне я заменил HDD на SSD для RAID10, меняя каждый диск по очереди. Всё прошло без проблем. 2 января температура и задержка чтения/записи одного из дисков RAID10 увеличились. Температура поднялась примерно на 5°C, а задержка выросла с 2,5 мс до 100 мс. Сначала я подумал, что это аппаратная проблема, но ни SMART, ни ядро не сообщали о чём-то. Поэтому я удалил диск из RAID-массива и использовал запасной диск. Через несколько дней следующий диск проявил точно такое поведение. Когда я перезагружаю сервер, ещё один диск показывает ту же проблему, и так далее. В данный момент один или два диска затрагиваются одновременно. Для меня остаётся загадкой, почему это произошло.

Нагрузка:

  • Виртуальные машины с использованием libvirt
  • Диски подключены с помощью <driver name="qemu" type="raw" cache="none" io="native" discard="unmap" iothread="1" queues="8"/>
  • В виртуальных машинах активирован fstrim

Аппаратное обеспечение:

  • 1x Supermicro Mainboard H11DSi-NT
  • 2x AMD EPYC 7351 (2,40 ГГц, 16 ядер, 64 МБ)
  • 1x SAS III/SATA Backplane SC825TQ
  • 5x Samsung SSD 870 QVO 8 ТБ
  • 3x INTEL SSDSC2KB019T8

Возможности и состояние дисков выглядят хорошими (вот один пример)

$ sudo hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   12642 MB in  2.00 seconds = 6333.85 MB/sec
 Timing buffered disk reads: 1424 MB in  3.00 seconds = 474.45 MB/sec
$ sudo smartctl -a /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-29-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 870 QVO 8TB
Serial Number:    S5SSNF0W909845V
LU WWN Device Id: 5 002538 f439126a0
Firmware Version: SVQ02B6Q
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Thu Jan 30 10:04:20 2025 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
# fio --rw=readwrite --name=test --size=20M --direct=1 --bs=1024k
test: (g=0): rw=rw, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
fio-3.33
Starting 1 process
test: Laying out IO file (1 file / 20MiB)
Jobs: 1 (f=1): [M(1)][83.3%][r=3072KiB/s,w=2048KiB/s][r=3,w=2 IOPS][eta 00m:01s]
test: (groupid=0, jobs=1): err= 0: pid=270155: Thu Jan 30 10:28:50 2025
  read: IOPS=2, BW=2835KiB/s (2903kB/s)(12.0MiB/4334msec)
    clat (msec): min=6, max=332, avg=107.76, stdev=97.13
     lat (msec): min=6, max=332, avg=107.76, stdev=97.14
    clat percentiles (msec):
     |  1.00th=[    7],  5.00th=[    7], 10.00th=[    7], 20.00th=[   15],
     | 30.00th=[   34], 40.00th=[   83], 50.00th=[   94], 60.00th=[  104],
     | 70.00th=[  120], 80.00th=[  186], 90.00th=[  215], 95.00th=[  334],
     | 99.00th=[  334], 99.50th=[  334], 99.90th=[  334], 99.95th=[  334],
     | 99.99th=[  334]
   bw (  KiB/s): min= 2043, max= 8192, per=100.00%, avg=4095.00, stdev=2897.19, samples=5
   iops        : min=    1, max=    8, avg= 3.80, stdev= 3.03, samples=5
  write: IOPS=1, BW=1890KiB/s (1936kB/s)(8192KiB/4334msec); 0 zone resets
    clat (msec): min=5, max=967, avg=379.96, stdev=315.73
     lat (msec): min=5, max=967, avg=379.99, stdev=315.73
    clat percentiles (msec):
     |  1.00th=[    6],  5.00th=[    6], 10.00th=[    6], 20.00th=[  192],
     | 30.00th=[  203], 40.00th=[  209], 50.00th=[  209], 60.00th=[  279],
     | 70.00th=[  498], 80.00th=[  684], 90.00th=[  969], 95.00th=[  969],
     | 99.00th=[  969], 99.50th=[  969], 99.90th=[  969], 99.95th=[  969],
     | 99.99th=[  969]
   bw (  KiB/s): min= 2043, max= 2048, per=100.00%, avg=2047.17, stdev= 2.04, samples=6
   iops        : min=    1, max=    2, avg= 1.83, stdev= 0.41, samples=6
  lat (msec)   : 10=15.00%, 20=5.00%, 50=5.00%, 100=10.00%, 250=40.00%
  lat (msec)   : 500=15.00%, 750=5.00%, 1000=5.00%
  cpu          : usr=0.00%, sys=0.14%, ctx=46, majf=0, minf=14
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.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.0%, >=64=0.0%
     issued rwts: total=12,8,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=2835KiB/s (2903kB/s), 2835KiB/s-2835KiB/s (2903kB/s-2903kB/s), io=12.0MiB (12.6MB), run=4334-4334msec
  WRITE: bw=1890KiB/s (1936kB/s), 1890KiB/s-1890KiB/s (1936kB/s-1936kB/s), io=8192KiB (8389kB), run=4334-4334msec

Disk stats (read/write):
    dm-25: ios=10/27, merge=0/0, ticks=1176/22896, in_queue=24072, util=100.00%, aggrios=12/28, aggrmerge=0/0, aggrticks=1264/12096, aggrin_queue=13360, aggrutil=98.83%
    dm-7: ios=12/28, merge=0/0, ticks=1264/12096, in_queue=13360, util=98.83%, aggrios=113/197, aggrmerge=0/0, aggrticks=1196/49788, aggrin_queue=50984, aggrutil=99.19%
    md1: ios=113/197, merge=0/0, ticks=1196/49788, in_queue=50984, util=99.19%, aggrios=25/129, aggrmerge=0/1, aggrticks=234/2788, aggrin_queue=4087, aggrutil=94.72%
  sdg: ios=14/182, merge=0/3, ticks=797/11548, in_queue=16700, util=94.72%
  sdf: ios=17/183, merge=0/2, ticks=129/778, in_queue=1215, util=7.56%
  sde: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
  sdc: ios=7/148, merge=2/0, ticks=27/952, in_queue=1343, util=8.19%
  sdb: ios=89/132, merge=0/1, ticks=221/662, in_queue=1178, util=7.02%
$ sudo vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 9  1      0 35817988 239156 1015344    0    0    85   123  307  372  0  1 92  1  0
10  0      0 35817988 239156 1015344    0    0 34608  3553 34452 40000  0  2 87  0  0
 6  0      0 35817988 239156 1015344    0    0  7156  1317 24555 30160  0  2 90  0  0
 7  1      0 35817988 239156 1015344    0    0   472   898 19253 19636  0  1 90  1  0
 7  0      0 35817988 239156 1015344    0    0  1944  1083 17017 20618  0  1 91  1  0
$ sudo mdadm -D /dev/md1
/dev/md1:
           Version : 1.2
     Creation Time : Sat May 23 16:27:09 2020
        Raid Level : raid10
        Array Size : 15624783872 (14.55 TiB 16.00 TB)
     Used Dev Size : 7812391936 (7.28 TiB 8.00 TB)
      Raid Devices : 4
     Total Devices : 5
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Thu Jan 30 10:11:48 2025
             State : active, degraded, recovering
    Active Devices : 3
   Working Devices : 5
    Failed Devices : 0
     Spare Devices : 2

            Layout : near=2
        Chunk Size : 512K

Consistency Policy : bitmap

    Rebuild Status : 7% complete

              Name : neon:1  (local to host neon)
              UUID : 5734c432:58f3c7e2:2d688727:783bf367
            Events : 1465326

    Number   Major   Minor   RaidDevice State
       8       8       99        0      active sync set-A   /dev/sdg3
       4       8       83        1      active sync set-B   /dev/sdf3
       9       8       19        2      active sync set-A   /dev/sdb3
       6       8       35        3      spare rebuilding   /dev/sdc3

       5       8       67        -      spare   /dev/sde3

Перестройка RAID идет ужасно медленно, а IO находится под высоким давлением

$ cat /proc/mdstat
Personalities : [raid1] [raid10] [linear] [multipath] [raid0] [raid6] [raid5] [raid4]
md1 : active raid10 sde3[5](S) sdb3[9] sdg3[8] sdc3[6] sdf3[4]
      15624783872 blocks super 1.2 512K chunks 2 near-copies [4/3] [UUU_]
      [=>...................]  recovery =  7.6% (599331904/7812391936) finish=135942.9min speed=883K/sec
      bitmap: 16/117 pages [64KB], 65536KB chunk

Grafana Storage IO Metrics

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

Ответ или решение

Причины резкого снижения производительности RAID10 на SSD могут вызывать серьезные затруднения, особенно если система ранее работала стабильно. Давайте рассмотрим возможные причины проблемы и пути ее решения.

Теория:

Прежде всего, важно понимать, что переход с HDD на SSD в составе RAID10-массива приносит множество преимуществ, включая повышенную скорость чтения и записи данных. Однако SSD имеют свои особенности и ограничения, которые могут влиять на производительность системы, особенно при высоких нагрузках, как в вашем случае. Наибольшую обеспокоенность должны вызывать увеличенные латентности и температуры дисков, которые могут быть следствием перегрузки контроллеров SSD, проблем с кэшем или фрагментацией.

Пример:

У вас в сервере присутствуют 5 SSD Samsung 870 QVO по 8TB каждый. Данные модели известны как хорошие решения для хранения больших объемов данных, однако они имеют свои ограничения со стороны производительности при больших объемах записи из-за использования QLC NAND памяти. В спецификациях данных SSD, великая вероятнось, есть ограничения на количество одновременных операций ввода-вывода и емкость кэширования. В нагрузке, когда несколько виртуальных машин совершают интенсивные операции ввода/вывода, могут возникнуть ситуации, когда SSD не успевают обрабатывать все запросы, что ведет к очередям и увеличению времени ответа.

Применение:

Теперь перейдем к применению теоретических данных для решения вашей проблемы:

  1. Настройка TRIM: Вы используете параметр discard="unmap" в настройках ваших виртуальных машин, что позволяет использовать TRIM. Однако некорректная работа TRIM в RAID может привести к деградации производительности. Рекомендуется периодически вручную выполнять команду fstrim для всех файловых систем на SSD или отключить TRIM в реальном времени и ограничиться плановыми запусками.

  2. Проблемы с кэшем: Проверьте настройки кэша как на уровне контроллера, так и на уровне файловой системы. Возможно, стоит поэкспериментировать с различными режимами кэширования в конфигурации libvirt (например, writeback вместо none).

  3. Фрагментация RAID: Долгосрочное использование и потенциально большой объем изменения данных могут привести к фрагментации, повышая нагрузку на систему ввода-вывода. Регулярное выполнение репликации и средства оптимизации RAID могут уменьшить эту проблему.

  4. Мониторинг и журналирование: Важно усилить мониторинг состояния SSD и RAID через smartctl, mdadm, и другие утилиты, чтобы наиболее быстро обнаруживать деградацию производительности и эскалацию температуры.

  5. Администрирование IO Threads: Управление очередями ввода-вывода (IO) имеет критическое значение при работе с SSD. Неправильная конфигурация iothread может вызывать узкие места. Попробуйте увеличить количество потоков или перераспределить их между наиболее нагруженными процессами.

  6. Анализ сети и системного окружения: Перегрузка сети или других подсистем также может откладываться на общей производительности RAID.

  7. Рассмотрите замену SSD или увеличение их числа: Если техническая диагностика показывает постоянные проблемы с отдельными SSD, задумайтесь об их замене. Кроме того, увеличение количества дисков с последующей настройкой RAID10 может помочь разгрузить текущие.

Проблемы с производительностью в таком сложном серверном окружении как у вас требуют комплексного подхода и своевременного мониторинга всех аспектов работы системы. Надеюсь, данные рекомендации помогут вам модернизировать систему и устранить возникшие проблемы.

Оцените материал
Добавить комментарий

Капча загружается...