LINUX.ORG.RU
Форум — General  

Слишком маленькая скорость записи на raid-z

 


3

3

Привет.
С неприятным удивлением для себя обнаружил такую картину на своем сервере: 

smd@jupiter:/tank/work/smd/riscv/images$ sudo dd if=new_fedora_image.img of=/dev/zvol/tank/vm/riscv_vm_3
15622144+0 records in
15622144+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 693.554 s, 11.5 MB/s
Поясню, что тут происходит: у меня собран raid-z массив и на базе того же zfs есть тома, которые будут отданы виртуалкам в качестве фс. И, пока ничего не запущено, я с этого рейд массива ддшу на него же 8гб имеджа диска.
Казалось бы, последовательный доступ, скорость должна быть +- нормальная, но нет. Увы, не имею представления, куда копать.
Во время копирования по iostat картинка какая-то такая: 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.18    0.00   21.70    2.39    0.00   67.73

Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
sda              0.00    1.00      0.00      9.00     0.00     1.80   0.00  64.29    0.00    6.60   0.00     0.00     9.00   0.00   0.00
sdb              0.00    1.00      0.00      9.00     0.00     1.80   0.00  64.29    0.00   16.40   0.00     0.00     9.00   0.00   0.00
md0              0.00    2.20      0.00      8.80     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     4.00   0.00   0.00
md1              0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
md2              0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
sdc            437.00   83.60   2311.20    556.00     0.00     0.00   0.00   0.00    1.57    0.42   0.54     5.29     6.65   0.46  23.76
sdd            436.40   89.00   2374.40    573.60     0.00     0.00   0.00   0.00    1.65    0.33   0.52     5.44     6.44   0.45  23.44
sde            441.80   97.20   2306.40    577.60     0.20     0.00   0.05   0.00    1.31    0.24   0.50     5.22     5.94   0.40  21.76
zd0           1988.80 10326.60   7955.20  41306.40     0.00     0.00   0.00   0.00    0.04    0.71   7.39     4.00     4.00   0.03  31.44
zd16          2008.60    0.00   8034.40      0.00     0.00     0.00   0.00   0.00    0.04    0.00   0.08     4.00     0.00   0.04   8.08
zd32             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
zd48             0.00  705.40      0.00   2821.60     0.00     0.00   0.00   0.00    0.00    0.23   0.16     0.00     4.00   0.01   0.80
zd64             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
zd80             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.64    0.00   14.46    0.89    0.00   72.02

Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
sda              0.00    4.80      0.00     17.20     0.00     0.40   0.00   7.69    0.00    2.71   0.00     0.00     3.58   0.17   0.08
sdb              0.00    4.80      0.00     17.20     0.00     0.40   0.00   7.69    0.00    4.92   0.00     0.00     3.58   0.17   0.08
md0              0.00    4.20      0.00     16.80     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     4.00   0.00   0.00
md1              0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
md2              0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
sdc            664.60   28.40   3924.00   1828.00     0.00     0.00   0.00   0.00    0.91    1.22   0.51     5.90    64.37   0.34  23.76
sdd            680.20   33.40   3883.20   1836.80     0.00     0.20   0.00   0.60    0.99    1.05   0.52     5.71    54.99   0.35  25.04
sde            708.60   52.60   3795.20   1818.40     0.00     0.00   0.00   0.00    0.67    0.42   0.38     5.36    34.57   0.24  18.48
zd0           2514.20    0.00  10056.80      0.00     0.00     0.00   0.00   0.00    0.04    0.00   0.11     4.00     0.00   0.04  10.72
zd16          2581.60    0.00  10326.40      0.00     0.00     0.00   0.00   0.00    0.04    0.00   0.09     4.00     0.00   0.04   9.44
zd32             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
zd48            28.40    0.00    113.60      0.00     0.00     0.00   0.00   0.00    2.03    0.00   0.06     4.00     0.00   2.03   5.76
zd64             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00
zd80             0.00    0.00      0.00      0.00     0.00     0.00   0.00   0.00    0.00    0.00   0.00     0.00     0.00   0.00   0.00

smd@jupiter:/tank/work/dev/images/riscv$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 7h6m with 0 errors on Sun Mar 10 07:30:58 2019
config:

        NAME                                          STATE     READ WRITE CKSUM
        tank                                          ONLINE       0     0     0
          raidz1-0                                    ONLINE       0     0     0
            ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K0FU2HCS  ONLINE       0     0     0
            ata-ST2000NM0033-9ZM175_Z1X02J9D          ONLINE       0     0     0
            ata-ST2000NM0033-9ZM175_Z1Y01BZC          ONLINE       0     0     0

errors: No known data errors

smd@jupiter:/tank/work/dev/images/riscv$ sudo zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  5.44T  3.34T  2.10T         -    25%    61%  1.00x  ONLINE  -

smd@jupiter:/tank/work/dev/images/riscv$ sudo zfs get all tank | grep -v default
NAME  PROPERTY              VALUE                  SOURCE
tank  type                  filesystem             -
tank  creation              Wed Feb  5 21:06 2014  -
tank  used                  2.22T                  -
tank  available             1.28T                  -
tank  referenced            2.21T                  -
tank  compressratio         1.01x                  -
tank  mounted               yes                    -
tank  recordsize            16K                    local
tank  mountpoint            /tank                  local
tank  compression           lz4                    local
tank  atime                 off                    local
tank  createtxg             1                      -
tank  xattr                 sa                     local
tank  version               5                      -
tank  utf8only              off                    -
tank  normalization         none                   -
tank  casesensitivity       sensitive              -
tank  guid                  8135613722416036316    -
tank  usedbysnapshots       0B                     -
tank  usedbydataset         2.21T                  -
tank  usedbychildren        18.3G                  -
tank  usedbyrefreservation  0B                     -
tank  refcompressratio      1.01x                  -
tank  written               2.21T                  -
tank  logicalused           2.22T                  -
tank  logicalreferenced     2.20T                  -
tank  acltype               posixacl               local

md@jupiter:/tank/work/dev/images/riscv$ sudo zfs get all tank/vm/riscv_vm_3 | grep -v default
[sudo] password for smd: 
NAME                PROPERTY              VALUE                  SOURCE
tank/vm/riscv_vm_3  type                  volume                 -
tank/vm/riscv_vm_3  creation              Sat Mar 30 17:24 2019  -
tank/vm/riscv_vm_3  used                  2.48G                  -
tank/vm/riscv_vm_3  available             1.28T                  -
tank/vm/riscv_vm_3  referenced            2.48G                  -
tank/vm/riscv_vm_3  compressratio         1.36x                  -
tank/vm/riscv_vm_3  volsize               10G                    local
tank/vm/riscv_vm_3  compression           on                     inherited from tank/vm
tank/vm/riscv_vm_3  createtxg             29871336               -
tank/vm/riscv_vm_3  guid                  1236530763382609933    -
tank/vm/riscv_vm_3  usedbysnapshots       0B                     -
tank/vm/riscv_vm_3  usedbydataset         2.48G                  -
tank/vm/riscv_vm_3  usedbychildren        0B                     -
tank/vm/riscv_vm_3  usedbyrefreservation  0B                     -
tank/vm/riscv_vm_3  dedup                 off                    inherited from tank/vm
tank/vm/riscv_vm_3  refcompressratio      1.36x                  -
tank/vm/riscv_vm_3  written               2.48G                  -
tank/vm/riscv_vm_3  logicalused           2.53G                  -
tank/vm/riscv_vm_3  logicalreferenced     2.53G                  -
Железка, на которой все крутится: tyan S8226.
Прошу помощи у экспертного сообщества, тк не понимаю, во что оно упирается и куда/как копать: Dimez, King_Carlo, vxzvxz

Deleted

Последнее исправление: SMD (всего исправлений: 4)
← OneFileLinux - не получается собрать
Почему top, atop не показывают все процессы, сильно нагружающие CPU →

 ← 1 2 3
Ответ на: комментарий от anonymous

Так, действительно, стало существенно лучше: 

smd@jupiter:/tank/work/smd$ sudo zfs create -s -V 10g tank/vm/riscv_vm_5
smd@jupiter:/tank/work/smd$ sudo dd if=/tank/work/dev/images/riscv/fs/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=4096
1952768+0 records in
1952768+0 records out
# что-то закешировалось?
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 73.9615 s, 108 MB/s
smd@jupiter:/tank/work/smd$ sudo dd if=/tank/work/dev/images/riscv/fs/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=1M
7628+0 records in
7628+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 49.7763 s, 161 MB/s

tank recordsize 16K local

Я так понимаю, причина, скорее всего в этом?
Допустим, с этим разобрались.
В vm тоже жутко низкая скорость, сравнимая с тем, что было в оригинальном dd. Меня смущает размер сектора, который репортится на устройство: 

[root@riscv-vm-3 ~]# fdisk -l /dev/vda 
Disk /dev/vda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Deleted
()

с этого рейд массива ддшу на него же

Кмк, всё в порядке. Чтение c двух дисков, потом запись в zil, потом чтение из zil, и запись на тои диска. И каждый раз перевод головок.

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

Допустим, но как это коррелирует с тем, что при правильном bs ситуация улучшается на порядок?

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

что-то закешировалось?
причина, скорее всего в этом?

Причина, в наличии arc. При повторном обращении к секторам диска, они берутся из arc, который в ram.

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

Рамы 64гб и большая часть из них свободна. Т.е. все те 8гб имеджа смогли бы влезть в арк(он до 30+гб расти может) и тогда, насколько я понимаю, даже с дефолтным bs оно должно было работать не так уныло. Или я ошибаюсь?

Deleted
()

Zfs не знаю. Странные всплески чтения 10 мб/с и записи 40 мб/с для zd0. Невыровненые разделы? Пишет блоками неправильного размера? Излишние промежуточные буферы наложенные на нехватку памяти? Сжатие? Шифрование? Чексуммы?

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

даже с дефолтным bs оно должно было работать не так уныло

Да, при повторном обращении к тем-же секторам дисков.

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

Странные всплески чтения 10 мб/с и записи 40 мб/с для zd0

Меня это тоже смутило, но объяснить не могу.

Невыровненые разделы?

Допускаю, но zfs создавался с выравниванием 4096, что вроде правильно. Но стоит проверить, да.

Пишет блоками неправильного размера?

Я сам склоняюсь к какой-то такой причине.

Излишние промежуточные буферы наложенные на нехватку памяти?

Скорее всего нет, тк рама почти вся свободна

Сжатие?

Сжатие есть через lz4, интернеты пишут, что оно совсем не отжирает ресурсов

Шифрование?

Нету

Чексуммы?

Тут нужно глубже в зфс копать, как минимум atime я отключил. Может, кто-то из более шарящих подскажет.

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

Кмк, всё в порядке. Чтение c двух дисков, потом запись в zil, потом чтение из zil, и запись на тои диска. И каждый раз перевод головок.

smd@jupiter:/tank/work/smd$ sudo zfs create -s -V 10g tank/vm/riscv_vm_5                                                                                                                                                                                                         
smd@jupiter:/tank/work/smd$ sudo dd if=/tank/work/dev/images/riscv/fs/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=4M                                                                                                                                         
1907+0 records in
1907+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 61.9815 s, 129 MB/s
smd@jupiter:/tank/work/smd$ sudo dd if=/tank/work/dev/images/riscv/fs/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5
15622144+0 records in
15622144+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 512.435 s, 15.6 MB/s

Мне кажется, что предположение, все же, ошибочно. Исходя из того, что образ должен был закешироваться в арке, тем самым, убрав чтение и, возможно, перевод головок, тк вся запись идет из рамы, скорость записи с обычным бс должна быть больше.
Еще я заметил, что при обоих вариантах дд, LA в системе подпрыгивает иногда до 15-20 и, судя по htop(увы, я пока не умею смотреть такое нормальными средствами) время тратится где-то в ядре.
UPD: Да, стало чуть лучше из-за кеша, насколько я могу судить, но, согласись, 15мбс против 11 все равно не торт.

Deleted
()
Последнее исправление: SMD (всего исправлений: 2)

Что за ZFS? Zfsonlinux? Реализация в freebsd? Solaris? Если это ZOL, то какая версия?

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

Сжатие есть через lz4, интернеты пишут, что оно совсем не отжирает ресурсов

Сжатие почти не отжирает ресурсы процессора, но меняет размер блока (иначе зачем нужно сжатие?). Я без понятия как в zfs реализовано отображение реальных блоков на сжатые блоки, но это точно небесплатно и по времени и по памяти оперативной и дисковой, которую еще надо синхронизировать.

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

Это arch или manjaro? В убунте 18.04 сейчас 

ZFS: Loaded module v0.7.5-1ubuntu16.4, ZFS pool version 5000, ZFS filesystem version 5
работает очень шустро.

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

Debian GNU/Linux buster/sid
Пришлось на него вчера переехать, тк слишком уж протухшие пакеты в стабильном были.

Deleted
()

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

Всплески LA - нехороший и непонятный фактор. С дисками всё в порядке? Smart хороший?

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

Сжатие lz4 включено по дефолту. Включал/выключал - все равно.
Насчет всплесков LA, да, согласен.
Диски вроде в норме, пара из них, конечно, хоть и серверные, но довольно старые, а третий - синий вд на 4тб. 

smd@jupiter:/tank/work/smd$ sudo smartctl -a  /dev/sdc
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-4-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Constellation ES.3
Device Model:     ST2000NM0033-9ZM175
Serial Number:    Z1Y01BZC
LU WWN Device Id: 5 000c50 04fcd8d07
Firmware Version: 0001
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
...
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   083   063   044    Pre-fail  Always       -       206670912
  3 Spin_Up_Time            0x0003   095   093   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       87
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   087   060   030    Pre-fail  Always       -       538976467
  9 Power_On_Hours          0x0032   043   043   000    Old_age   Always       -       49959
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       93
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   062   056   045    Old_age   Always       -       38 (Min/Max 27/40)
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       -       57
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       93
194 Temperature_Celsius     0x0022   038   044   000    Old_age   Always       -       38 (0 24 0 0 0)
195 Hardware_ECC_Recovered  0x001a   054   012   000    Old_age   Always       -       206670912
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

smd@jupiter:/tank/work/smd$ sudo smartctl -a  /dev/sdd
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-4-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Constellation ES.3
Device Model:     ST2000NM0033-9ZM175
Serial Number:    Z1X02J9D
LU WWN Device Id: 5 000c50 04ff39fa2
Firmware Version: 0001
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
...
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   067   063   044    Pre-fail  Always       -       6032069
  3 Spin_Up_Time            0x0003   096   095   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       89
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   094   060   030    Pre-fail  Always       -       2956748755
  9 Power_On_Hours          0x0032   043   043   000    Old_age   Always       -       49956
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       93
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   097   097   000    Old_age   Always       -       3
190 Airflow_Temperature_Cel 0x0022   064   057   045    Old_age   Always       -       36 (Min/Max 27/38)
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       -       57
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       94
194 Temperature_Celsius     0x0022   036   043   000    Old_age   Always       -       36 (0 23 0 0 0)
195 Hardware_ECC_Recovered  0x001a   061   011   000    Old_age   Always       -       6032069
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

smd@jupiter:/tank/work/smd$ sudo smartctl -a  /dev/sde
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-4-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Blue
Device Model:     WDC WD40EZRZ-00GXCB0
Serial Number:    WD-WCC7K0FU2HCS
LU WWN Device Id: 5 0014ee 20f64aad9
Firmware Version: 80.00A80
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
...
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     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   200   159   021    Pre-fail  Always       -       4975
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       18
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   090   090   000    Old_age   Always       -       7742
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       18
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       14
193 Load_Cycle_Count        0x0032   179   179   000    Old_age   Always       -       63885
194 Temperature_Celsius     0x0022   118   112   000    Old_age   Always       -       32
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0
Смотреть на эти данные смысла большого нет, но совсем уж криминала я не вижу.

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

Вообще этот сервер и зфс на нем были настроены в далеком 2014, поэтому сейчас руки чешутся все снести и сделать заново. Но пока возможности нет.

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

Так я ж не скорость тестирую, а мне действительно надо было заддшить образ.
Ок, разобрались, что можно подать недефолтный bs(начиная от 4096, но и 1М и 4М тоже неплохо работают) и все будет +- нормально.
Но хочется докопаться до причины и исправить ее, тк перфоманс виртуалки на этом зфсном томе такой же низкий.

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

Для работы с образами попробуй 

qemu-img convert

Но хочется докопаться до причины и исправить ее, тк перфоманс виртуалки на этом зфсном томе такой же низкий.

не забудь потом поделиться результатом

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

Я бы, кстати, был признателен, если меня кто-то просветит насчет размеров блоков, тк я запутался:
1. У всех дисков логический размер сектора 512 из-за легаси, но реально почти везде 4096
2. Я создаю зфсный пул, у которого ashift=12, т.е. предполагается выравнивание операций(?) по 4096
3. У пула я ставлю recordsize в 16К, тк предполагается работать с относительно мелкими файлами
4. У тома виртуалки я ставлю volblocksize в 4К, тк вм крутится на ехт4, у которой по дефолту блок 4к
5. Смущает выхлоп fdisk -l внутри виртуалки, тк там размер сектора указан 512(сам имедж делал не я), но тк он раскатывается на зфсный том, то, если он выровнен на 4к(см п.4), то должно быть все равно: 

fdisk -l /dev/vda
Disk /dev/vda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
6. Было бы хорошо удостовериться, что все разделы в хосте и тома виртуалок выровнены по 4к.

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

1 . У всех дисков логический размер сектора 512 из-за легаси, но реально почти везде 4096.

У старых сигейтов 512, у одного нового 4к физический, 512 логический.

Может быть, проблемы в этом. Я ни разу не миксовал диски нигде.

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

Как бы мне заставить обращаться всех по 4к, а не по 512?

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

Провел небольшой эксперимент: 

smd@jupiter:/tank/work/smd$ sudo dd if=/tank/work/dev/images/riscv/fs/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=2048
[sudo] password for smd: 
3905536+0 records in
3905536+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 262.221 s, 30.5 MB/s
smd@jupiter:/tank/work/smd$ sudo dd if=/tank/work/dev/images/riscv/fs/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=1024
7811072+0 records in
7811072+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 347.558 s, 23.0 MB/s
smd@jupiter:/tank/work/smd$ sudo dd if=/tank/work/dev/images/riscv/fs/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=512
15622144+0 records in
15622144+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 535.635 s, 14.9 MB/s
smd@jupiter:/tank/work/smd$ sudo dd if=/tank/work/dev/images/riscv/fs/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=4096
1952768+0 records in
1952768+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 69.485 s, 115 MB/s
smd@jupiter:/tank/work/smd$ sudo dd if=/tank/work/dev/images/riscv/fs/fedora32_image_jdk_ready.img of=/dev/zvol/tank/vm/riscv_vm_5 bs=8192
976384+0 records in
976384+0 records out
7998537728 bytes (8.0 GB, 7.4 GiB) copied, 69.4865 s, 115 MB/
Видно, что по дефолту обращение идет по 512 байт, а начиная от блока в 4096 все становится ок.

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

ИМХО, тут проблема комплексная: ashift + несовпадение размера физ. блока + разные винты. Скорость рейда ограничивается скоростью самого тормозного винта в нем. А если этому тормозу еще и приходится маслать в два раза больше остальных - отсюда падение скорости и рост I/O при записи мелких блоков.

Как такое чинить - хз. Всегда в рейдах использовал винты одной модели, объема и даже износа.

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

Но если непосредственно ддшить с самих дисков, скорость выходит не такая уж и плохая: 

smd@jupiter:/tank/work/smd$ sudo dd if=/dev/sdc of=/dev/shm/sdc_1g bs=1M count=1024
[sudo] password for smd: 
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.49222 s, 143 MB/s
smd@jupiter:/tank/work/smd$ sudo dd if=/dev/sdd of=/dev/shm/sdd_1g bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.0279 s, 153 MB/s
smd@jupiter:/tank/work/smd$ sudo dd if=/dev/sde of=/dev/shm/sde_1g bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.44829 s, 167 MB/s

проблема комплексная: ashift + несовпадение размера физ. блока + разные винты

Интересует момент про несовпадение блока, что имеется ввиду? Несовпадение размера блоков у дисков в рейде или в виртуалке?

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

Было бы хорошо удостовериться, что все разделы в хосте и тома виртуалок выровнены по 4к.

zdb poolname | grep ashift

iZEN ★★★★★
()
Ответ на: комментарий от iZEN 
smd@jupiter:/tank/work/dev/images/riscv$ sudo zdb -e tank | grep ashift
                ashift: 12
                ashift: 12

Конца грепа не дождался, но думаю, этого хватит?

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

Но если непосредственно ддшить

Так dd-шить нет смысла, так как при линейном чтении размер блока заведомо будет кратным bs=1M и падения скорости не будет. Попробуй dd-шить каждый диск с bs: 513, 1025, 2049, 4097.

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

Несовпадение размера блоков у дисков в рейде или в виртуалке?

И то, и другое. Одно будет усугублять второе.

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

Сейчас попробую, но как насчет вот этих результатов: Слишком маленькая скорость записи на raid-z (комментарий)
Насколкьо я могу судить, тут тоже должно быть линейное чтение и линейная запись.

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

ИМХО, этот тест показывает, что один из винтов явно не умеет писать 4k блоки. Отсюда и тормоза при bs<4096.

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

ИМХО, этот тест показывает, что один из винтов явно не умеет писать 4k блоки. Отсюда и тормоза при bs<4096.

Звучит разумно 

smd@jupiter:/tank/work/dev/images/riscv$  for i in /dev/sd{c,d,e};do sudo smartctl -x $i | grep 'Sector Size';done
[sudo] password for smd: 
Sector Size:      512 bytes logical/physical
Sector Size:      512 bytes logical/physical
Sector Sizes:     512 bytes logical, 4096 bytes physical

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

Звучит разумно

Оказывается наоборот, только один может писать 4k.

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

Попробуй 4k диск перевести в оффлайн и проделать те же тесты.

iron ★★★★★
()
Ответ на: комментарий от Deleted
  1. Я создаю зфсный пул, у которого ashift=12, т.е. предполагается выравнивание операций(?) по 4096

А на диске-то ты выравниваешь? Как создавал раздел(ы)?

Создавай с ashift, равным большему значению среди имеющихся дисков (например, если у тебя большинство 512 и один 4096, делай 4096). В RAIDZ можешь ставить 8K (ashift=13).

  1. Было бы хорошо удостовериться, что все разделы в хосте и тома виртуалок выровнены по 4к.

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

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

Пул был создан еще в 2014 году с ashift 12, так что с этим все в порядке.
Однако по какой-то причине в зфс я отдал не полностью диски, а создал на них разделы и выглядит это как-то так: 

smd@jupiter:/tank/work/dev/images/riscv$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000NM0033-9ZM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6AAD4D9B-2C13-604F-B403-8A6D9CD2F4FA

Device     Start        End    Sectors  Size Type
/dev/sdc1   2048 3907012607 3907010560  1.8T Solaris /usr & Apple ZFS
smd@jupiter:/tank/work/dev/images/riscv$ sudo fdisk -l /dev/sdd
Disk /dev/sdd: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000NM0033-9ZM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 42060B14-513E-0D43-A8E3-3637E1CC6AAA

Device     Start        End    Sectors  Size Type
/dev/sdd1   2048 3907012607 3907010560  1.8T Solaris /usr & Apple ZFS
smd@jupiter:/tank/work/dev/images/riscv$ sudo fdisk -l /dev/sde
Disk /dev/sde: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EZRZ-00G
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: DE52369D-8F6E-7B47-B271-C9DBDFAA8CCB

Device          Start        End    Sectors  Size Type
/dev/sde1        2048 7814019071 7814017024  3.7T Solaris /usr & Apple ZFS
/dev/sde9  7814019072 7814035455      16384    8M Solaris reserved 1
Т.е. начала разделов выровнены на 2048 и i/o size различается.

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

Если том, где хранятся имейджи, выравнен и выставлен верный разаер блока

Как это можно обеспечить кроме как выставлением volblocksize?

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

Вот такой лайфхак случайно нашел. Разрешаешь монтировать пул по NFS:

 zfs set sharenfs="rw=@*,all_squash" tank/...


Монтируешь через loopback:

mount localhost:/<mountpoint zfs pool> /mnt -o rw,hard,rsize=131072,wsize=131072,nointr,nosharecache,timeo=600


переходишь в /mnt и проверяешь

 dd if=my_file.ext of=/dev/null

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

Попробовал повторить изначальный эксперимент, наблюдая в zpool iostat: складывается ощущение, что оно сначала медленно вычитывает, а потом довольно быстро пишет на диск.
Т.е. в начале скорость чтения с рейда около 10-30мб/с, запись на нуле, потом несколько секунд записи на 150+мб/с, а в какой-то момент скорость чтения падает до уровня ~1мб/с и ниже.

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

По логике, если разделы у тебя начинаются с 2048 а винт пишет блок 4096 (на одном из винтов) то как раз для записи каждого блока потребуется на одну операцию больше. Говорил же тебе, попробуй перевести 4к диск в оффлайн и протестировать. Тогда станет ясно в этом ли причина.

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

Скорее всего, один из дисков в массиве подыхает. Такие симптомы — показатель.

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3
← OneFileLinux - не получается собрать
General
Почему top, atop не показывают все процессы, сильно нагружающие CPU →