LINUX.ORG.RU
ФорумAdmin

Linux raid level 6 скорость записи около 30 Мб/с

 , ,


1

2

Массив

root@host103:~# mdadm --detail /dev/md127 
/dev/md127:
           Version : 1.2
     Creation Time : Fri Nov  6 20:36:47 2020
        Raid Level : raid6
        Array Size : 92273631232 (87998.99 GiB 94488.20 GB)
     Used Dev Size : 11534203904 (10999.87 GiB 11811.02 GB)
      Raid Devices : 10
     Total Devices : 10
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon Nov  9 04:17:49 2020
             State : active, checking 
    Active Devices : 10
   Working Devices : 10
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : bitmap

      Check Status : 0% complete

              Name : host103:2  (local to host host103)
              UUID : 4e5483ae:2e82d657:2ec42c81:1593e833
            Events : 13709

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1
       2       8       65        2      active sync   /dev/sde1
       3       8       81        3      active sync   /dev/sdf1
       4       8       97        4      active sync   /dev/sdg1
       5       8      113        5      active sync   /dev/sdh1
       6       8      129        6      active sync   /dev/sdi1
       7       8      145        7      active sync   /dev/sdj1
       8       8      161        8      active sync   /dev/sdk1
       9       8      177        9      active sync   /dev/sdl1
root@host103:~# 

из дисков

root@host103:~# fdisk -l /dev/sdc
Disk /dev/sdc: 10.94 TiB, 12000138625024 bytes, 23437770752 sectors
Disk model: TOSHIBA MG07ACA1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: CC7399F1-714A-4ECF-B7A8-79BB1767F1B7

Device     Start         End     Sectors  Size Type
/dev/sdc1   2048 23068674047 23068672000 10.8T Linux filesystem
root@host103:~# 
root@host103:~# smartctl -i -A /dev/sdc
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-52-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Toshiba MG07ACA... Enterprise Capacity HDD
Device Model:     TOSHIBA MG07ACA12TE
Serial Number:    20B0A2AQFDUG
LU WWN Device Id: 5 000039 9f8cb26c8
Firmware Version: 4003
User Capacity:    12,000,138,625,024 bytes [12.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Mon Nov  9 04:18:41 2020 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       7148
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       10
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   050    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       85
 10 Spin_Retry_Count        0x0033   100   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       10
 23 Helium_Condition_Lower  0x0023   100   100   075    Pre-fail  Always       -       0
 24 Helium_Condition_Upper  0x0023   100   100   075    Pre-fail  Always       -       0
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       9
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       15
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       27 (Min/Max 19/27)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       2228224
222 Loaded_Hours            0x0032   100   100   000    Old_age   Always       -       61
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
224 Load_Friction           0x0022   100   100   000    Old_age   Always       -       0
226 Load-in_Time            0x0026   100   100   000    Old_age   Always       -       594
240 Head_Flying_Hours       0x0001   100   100   001    Pre-fail  Offline      -       0

root@host103:~# 

Диски подключены к контроллеру PERC H730 Mini (Embedded) в режиме HBA (шасси PowerEdge R730xd)

Поверх лежит LVM.

root@host103:~# vgs
  VG   #PV #LV #SN Attr   VSize   VFree   
  vg01   1   4   0 wz--n- 439.87g  399.87g
  vg02   1   3   0 wz--n- <85.94t <158.99g
root@host103:~# 
root@host103:~# lvs | grep -e LV -e test
  LV              VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  test-begin      vg02 -wi-ao---- 400.00g                                                    
  test-end        vg02 -wi-a----- 400.00g                                                    
  test-middle     vg02 -wi-a-----  85.00t                                                    
root@host103:~# 

Показывает на операции

root@host103:~# shred -n0 -z -vv /dev/mapper/vg02-test--begin                                                                                                                                                      
shred: /dev/mapper/vg02-test--begin: pass 1/1 (000000)...                                                                                                                                                          
shred: /dev/mapper/vg02-test--begin: pass 1/1 (000000)...145MiB/400GiB 0%

скорость на запись около 30 мебибайт в секунду. Это нормально?

Прямо сейчас идёт ресинк, я руками запустил. На момент прогона shred ресинка не было.

★★★★★

Последнее исправление: targitaj (всего исправлений: 3)

echo 8192 > /sys/block/md127/md/stripe_cache_size

пробовал

30 метров в секунду на запись на raid6 на 10 шпинделях - это нормально?

targitaj ★★★★★
() автор топика
Последнее исправление: targitaj (всего исправлений: 1)

Вот это вообще как понимать?

root@host103:~# dmesg | grep raid6
[   17.296089] raid6: avx2x4   gen() 21336 MB/s
[   20.672087] raid6: avx2x4   xor() 13632 MB/s
[   20.720088] raid6: avx2x2   gen() 18245 MB/s
[   20.768085] raid6: avx2x2   xor() 11082 MB/s
[   20.816089] raid6: avx2x1   gen() 16036 MB/s
[   20.864083] raid6: avx2x1   xor() 10475 MB/s
[   20.912090] raid6: sse2x4   gen() 11746 MB/s
[   20.960090] raid6: sse2x4   xor()  7336 MB/s
[   21.008088] raid6: sse2x2   gen()  9771 MB/s
[   21.056089] raid6: sse2x2   xor()  6247 MB/s
[   21.104093] raid6: sse2x1   gen()  8367 MB/s
[   21.152088] raid6: sse2x1   xor()  5707 MB/s
[   21.152106] raid6: using algorithm avx2x4 gen() 21336 MB/s
[   21.152126] raid6: .... xor() 13632 MB/s, rmw enabled
[   21.152144] raid6: using avx2x2 recovery algorithm
root@host103:~# 

впрочем, тут числа других порядков, начинается от 5000 метров в сек.

targitaj ★★★★★
() автор топика
Последнее исправление: targitaj (всего исправлений: 1)

Ты используешь shred для тестирования, значит важных данных там нет. Если разобрать рейд и попробовать тоже самое поделать с каждым диском в отдельности - без аномалий, скорость записи единооразная на всех дисках? Олсо, shred перезаписывает каждый файл трижды при i=DEFAULT, не надо ли умножить выходное значение на три? Если попробовать с dd conv=fsync результаты будут такими же?

slowpony ★★★★★
()

Ставь raidz и перестань использовать молоток, чтобы вкручивать саморезы.

anonymous
()
Ответ на: комментарий от targitaj

Смотри iostat, что у тебя там пишется и какими блоками.

Я предполагаю, что shred должен писать последовательно большими блоками. Если это так, то 30 Mb/s - это очень медленно.

Скорость последовательной записи на RAID-6 должна быть такой же, как и у RAID-0 из такого же числа дисков.

Еще проверь, что там с кэшом дисков (не контроллера, а самих дисков), т.е. контроллер может его отключить. Включать или нет - решай сам.

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

Скорость последовательной записи на RAID-6 должна быть такой же, как и у RAID-0 из такого же числа дисков.

С чего вдруг, если 2 диска (2 объема, точнее) отводятся под контрольные суммы? Которые еще надо считать.

YAR ★★★★★
()
Ответ на: комментарий от bigbit

Четность размазана по всем дискам

Потому и уточнил - «2 объема», а не выделенных диска.

В любом случае, у тебя не будет скорости записи «как на RAID0 из того же числа дисков». В идеальном случае было бы на 2 диска меньше. А в реальной жизни приходится обычно вычитывать лежащие на диске блоки данных, чтобы построить для них блоки четности. В RAID0 всего этого нет.

YAR ★★★★★
()
Ответ на: комментарий от YAR

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

К примеру, есть RAID-6 6+2 и RAID-0 из 8 дисков. Пишем полными страйпами, размер сhunk'а 64Кб.

RAID-0: 64Кб запишутся на 8 дисков одновременно.
RAID-6: На 2 диска запишутся 128Кб, на остальные 6 дисков - 64Кб. Тоже одновременно.

Особой разницы нет. Как я уже говорил, Хитачи, когда делает сайзинг, ее не учитывает.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от bigbit

Скорость последовательной записи на RAID-6 должна быть такой же, как и у RAID-0 из такого же числа дисков.

Ты точно запись с чтение не путаешь?

ЕМНИП, write penalty для RAID6 очень большой, т.к. он считает четность два раза, и, соответственно, делает дополнительные операции записи.

CaveRat ★★
()

Так, ясно, а помогите понять про оптимальный размер chuck для моего случая. 10 шпинделей по 12Т, под хранилище, файлы от килобайт до гигабайт размером.

targitaj ★★★★★
() автор топика
Ответ на: комментарий от targitaj

Оптимальным решением как бы является отказ от классического размещения данных, то есть чтобы дедупликация, сжатие, избыточность обеспечивалась объектным хранилищем. Например гуглить приватную реализацию Amazon S3. Но это надо перекраивать всю сопутствующую инфраструктуру. Второй вариант, если вас не пугает пенальти по объему - RAID10. Третий вариант, на мой взгляд с гнильцой, использовать аппаратные контроллеры с жирным кешем на запись. Четвертый вариант, bcache в режиме writeback, но для ваших объемов придется прикупить что-нибудь типа Intel DC на 1Tb.

Bloody ★★
()
Ответ на: комментарий от CaveRat

Читай выше - если запись последовательная и набирается полный страйп, то пенальти на запись не будет.

bigbit ★★★★★
()

Откуда ты знаешь, блоками какого размера пишет shred. Если блоки не кратны размеру страйпа, будут тормоза. К тому же shred наверняка не параллелит операции записи. Хочешь бенчмаркать дисковую систему – используй fio.

8+2 это хороший конфиг, размер страйпа степень двойки. Попробуй разные размеры чанка 4k, 8k, 16k – дадут размеры страйпа 32k, 64k, 128k. Бенчи каждый конфиг fio с размером блока кратным страйпу с параллелизмом.

iliyap ★★★★★
()

Похоже на вибрацию дисков от них самих: «220 Disk_Shift» - головки уходят с дорожек.

anonymous
()
Ответ на: комментарий от targitaj

Я же предложил попробовать разные. Не хочешь пробовать – возьми наугад, например 8k.

Если тебя интересует только скорость последовательной однопоточной записи, можно побенчить её с помощью dd bs=1M count=10240 oflag=direct status=progress if=/dev/zero of=/dev/mapper/vg-lv. Параллельную нагрузку лучше бенчить с помощью fio. Вот такой джоб для fio симулирует параллельную нагрузку от 4 потоков пишуших мегабайтными блоками:

[randw1m]
filename=/dev/mapper/vg-lv
readwrite=randwrite
blocksize=1Mi
size=100%
io_size=10Gi
direct=1
ioengine=libaio
iodepth=4

При создании файловой системы надо указать параметры твоего рейд-массива, чтобы файловая система оптимально аллоцировала и выравнивала пространство (целыми страйпами). Например, для ext2/3/4 на страйпах 8x8k это mke2fs -b 4096 -E stride=2,stripe_width=8.

iliyap ★★★★★
()
Последнее исправление: iliyap (всего исправлений: 1)

ЛОР, а что скажете насчёт выноса bitmap на соседний raid1 на паре SSD? Там тоже LVM. Какого размер LV надо?

targitaj ★★★★★
() автор топика
Последнее исправление: targitaj (всего исправлений: 1)
Ответ на: комментарий от iliyap

херня какая. 10 потоков по 10 мб/сек=100мб/сек-бинго

только когда даже один юзер работает-нихрена не работает

10 мб/сек не сорость

anonymous
()
Ответ на: комментарий от anonymous

Добавлю. В таком решении низкая производительность это нормально. SATA диски 7200rpm имеют производительность порядка 60-70 IOPS, это следует прямо из механики диска (см. даташиты). Можно убедиться через: # ioping -R /dev/sdc . Соответственно RAID-6 8+2, даже если считать 10 дисков при страйпе 512KB ( = 64KB * 8 ), не сможет дать более ( 10шт. * 64KB * 70IOPS = 44800KB per sec., при условии использования файловой системой самого малого блока 512KB равного страйпу.

Чтобы увеличить производительность нужно писать/читать бОльшими блоками. Однако для приложений, которые работают с малыми блоками это приведёт к снижению производительности (считать -> изменить часть блока -> записать). А вот для ПО, типично работающего с большИми блоками это приведёт к росту производительности. Например, чанки по 128KB дадут страйп 1MB, такой же размер блока FS и производительность 89600KB per sec. Сейчас все OS поддерживают 1MB блоки для IO, а вот бОльшие зачастую разбивают до 1MB.

Также можно увеличить производительность, заменив диски 7200rpm на 15000rpm, они имеют производительность до 260 IOPS, т.е. примерно в 3 раза большую. Либо сделать достаточное по объёму кэширование средствами RAM или SSD.

anonymous
()
Ответ на: комментарий от anonymous

При последовательной записи I/O шедулер по-merge-ит реквесты. Так что размер блока там будет ого-го.
Можно запустить iostat и наблюдать за rqm/s (requests merged/s).

bigbit ★★★★★
()

raid5 и raid6 для босяков, которые не накопили на десятку. Независимо от реализации получаешь низкие иопсы, падение удоев и бесконечные ребилды.

melkor217 ★★★★★
()
Ответ на: комментарий от melkor217

raid5 и raid6 для босяков, которые не накопили на десятку.

raid5 и raid6 для бэкаперов, которые не накопили на специальный девайс.

Minona ★★☆
()
Ответ на: комментарий от melkor217

raid10 и raid6 как бы имеют разную отказоустойчивость. 2 диска в raid6 допустимо потерять. Я бы делал raid60 на этих 10 дисках (5+5 stripe). По крайней мере, проверил, протестил.

Еще я не уверен, что mdadm хорошо оптимизирован, на самом деле. Из реальных пременений это всегда наколенные сборки из того что есть под рукой. Пусть скажут те, кто видел\делал продакшн на сложных и больших mdadm конфигурациях.

zendrz ★★
()
Последнее исправление: zendrz (всего исправлений: 1)
Ответ на: комментарий от Minona

Raid0 из двух raid6 по 5 дисков (в вики по рейдам есть иллюстрации и схемы про райд60)

zendrz ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.