Вопрос или проблема
Я управляю сервером 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
Я в растерянности и у меня заканчиваются идеи, что могло внезапно измениться, так как всё шло хорошо полгода
Ответ или решение
Причины резкого снижения производительности RAID10 на SSD могут вызывать серьезные затруднения, особенно если система ранее работала стабильно. Давайте рассмотрим возможные причины проблемы и пути ее решения.
Теория:
Прежде всего, важно понимать, что переход с HDD на SSD в составе RAID10-массива приносит множество преимуществ, включая повышенную скорость чтения и записи данных. Однако SSD имеют свои особенности и ограничения, которые могут влиять на производительность системы, особенно при высоких нагрузках, как в вашем случае. Наибольшую обеспокоенность должны вызывать увеличенные латентности и температуры дисков, которые могут быть следствием перегрузки контроллеров SSD, проблем с кэшем или фрагментацией.
Пример:
У вас в сервере присутствуют 5 SSD Samsung 870 QVO по 8TB каждый. Данные модели известны как хорошие решения для хранения больших объемов данных, однако они имеют свои ограничения со стороны производительности при больших объемах записи из-за использования QLC NAND памяти. В спецификациях данных SSD, великая вероятнось, есть ограничения на количество одновременных операций ввода-вывода и емкость кэширования. В нагрузке, когда несколько виртуальных машин совершают интенсивные операции ввода/вывода, могут возникнуть ситуации, когда SSD не успевают обрабатывать все запросы, что ведет к очередям и увеличению времени ответа.
Применение:
Теперь перейдем к применению теоретических данных для решения вашей проблемы:
-
Настройка TRIM: Вы используете параметр
discard="unmap"
в настройках ваших виртуальных машин, что позволяет использовать TRIM. Однако некорректная работа TRIM в RAID может привести к деградации производительности. Рекомендуется периодически вручную выполнять командуfstrim
для всех файловых систем на SSD или отключить TRIM в реальном времени и ограничиться плановыми запусками. -
Проблемы с кэшем: Проверьте настройки кэша как на уровне контроллера, так и на уровне файловой системы. Возможно, стоит поэкспериментировать с различными режимами кэширования в конфигурации libvirt (например, writeback вместо none).
-
Фрагментация RAID: Долгосрочное использование и потенциально большой объем изменения данных могут привести к фрагментации, повышая нагрузку на систему ввода-вывода. Регулярное выполнение репликации и средства оптимизации RAID могут уменьшить эту проблему.
-
Мониторинг и журналирование: Важно усилить мониторинг состояния SSD и RAID через smartctl, mdadm, и другие утилиты, чтобы наиболее быстро обнаруживать деградацию производительности и эскалацию температуры.
-
Администрирование IO Threads: Управление очередями ввода-вывода (IO) имеет критическое значение при работе с SSD. Неправильная конфигурация iothread может вызывать узкие места. Попробуйте увеличить количество потоков или перераспределить их между наиболее нагруженными процессами.
-
Анализ сети и системного окружения: Перегрузка сети или других подсистем также может откладываться на общей производительности RAID.
-
Рассмотрите замену SSD или увеличение их числа: Если техническая диагностика показывает постоянные проблемы с отдельными SSD, задумайтесь об их замене. Кроме того, увеличение количества дисков с последующей настройкой RAID10 может помочь разгрузить текущие.
Проблемы с производительностью в таком сложном серверном окружении как у вас требуют комплексного подхода и своевременного мониторинга всех аспектов работы системы. Надеюсь, данные рекомендации помогут вам модернизировать систему и устранить возникшие проблемы.