LINUX.ORG.RU
ФорумAdmin

производительность zfs на медленных hdd с cache=standard

 ,


1

4

Собрал zraid2 на proxmox из 6ти HDD на 2TB (ST2000LM015, планируются использоваться под репликации, бекапы и файлопомойку, основные данные на SSD).

Создал VM на этом zraid и хотел поставить туда debian. Но установка системы шла дико долго во время установки пакетов. Минут через 30 остановил.

Отключение синхронизации (zfs set sync=disabled raid) решила проблему производительности. Установилось быстро.

Почему так происходит? Для работы на медленных hdd требуется использовать l2arc из ssd?

Почитал ресурсы:

Параметры zpool:

  • ashift=12
  • compression: lz4
# zpool status raid
  pool: raid
 state: ONLINE
  scan: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	raid        ONLINE       0     0     0
	  raidz2-0  ONLINE       0     0     0
	    sda     ONLINE       0     0     0
	    sdb     ONLINE       0     0     0
	    sdc     ONLINE       0     0     0
	    sdd     ONLINE       0     0     0
	    sde     ONLINE       0     0     0
	    sdf     ONLINE       0     0     0

errors: No known data errors

Параметры запуска vm:

/usr/bin/kvm
  -id 401
  -name wg-sm
  -chardev socket,id=qmp,path=/var/run/qemu-server/401.qmp,server,nowait
  -mon chardev=qmp,mode=control
  -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5
  -mon chardev=qmp-event,mode=control
  -pidfile /var/run/qemu-server/401.pid
  -daemonize
  -smbios type=1,uuid=0ce21302-e7ed-4c6d-8a34-32969e605407
  -smp 2,sockets=1,cores=2,maxcpus=2
  -nodefaults
  -boot menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg
  -vnc unix:/var/run/qemu-server/401.vnc,password
  -cpu kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep
  -m 2048
  -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e
  -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f
  -device vmgenid,guid=71c2d10c-a1aa-4b57-ab00-1e2bf77de1b6
  -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2
  -device usb-tablet,id=tablet,bus=uhci.0,port=1
  -device VGA,id=vga,bus=pci.0,addr=0x2
  -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
  -iscsi initiator-name=iqn.1993-08.org.debian:01:7759181d764
  -drive file=/var/lib/vz/template/iso/debian-10.7.0-amd64-netinst.iso,if=none,id=drive-ide2,media=cdrom,aio=threads
  -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200
  -device virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5
  -drive file=/dev/zvol/raid/vm-401-disk-0,if=none,id=drive-scsi0,cache=writeback,discard=on,format=raw,aio=threads,detect-zeroes=unmap
  -device scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100
  -netdev type=tap,id=net0,ifname=tap401i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on
  -device virtio-net-pci,mac=B6:B4:5B:24:88:66,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300
  -machine type=pc+pve0

-drive file=/dev/zvol/raid/vm-401-disk-0,if=none,id=drive-scsi0,cache=writeback,discard=on,format=raw,aio=threads,detect-zeroes=unmap

# pveversion -v | grep zfs
zfsutils-linux: 0.8.3-pve1

cast @imul, @system-root, @Harliff, @King_Carlo

★★★★★

ST2000LM015

Это SMR, так что, аккуратнее: https://m.habr.com/ru/post/500214/

Почему так происходит?

Синхронная запись требует дисков с низкой задержкой. Сравните результаты dd с sync и без, например.

Для работы на медленных hdd требуется использовать l2arc из ssd?

Не l2arc, a zil. И от SSD многое зависит (см. например: https://m.habr.com/ru/company/selectel/blog/521168/)

По ZSF - вот это ещё гляньте: https://m.habr.com/ru/post/504692/

Если Вы для продакшена - то не надо raid6 под виртуалки, сделайте лучше raid10.

И не надо zfs пихать всюду - часто достаточно lvm использовать (особенно если приоритет - производительность, или имеются существенные ограничения по железу).

Harliff ★★★★★
()

В качестве мимопроходящего предположу, что установщик ставит софт в режиме sync, соот-но, zraid из hdd в 5400 оборотов сильно не успевает. Хотя, там кеша в 128 мегабайт, но тем не менее. Если отключение кеша помогло, то в таком случае, если я прав, то установка ssd в качестве кеша для записи в режиме sync поможет. На репликацию: ну тоже будет так или иначе влиять такие медленные диски. Даже если предположить что диски будут реплицироваться в режиме async (я думаю что это так, но опять-же надо проверить), то в случае синхронизации и работы VM на этом массиве уже могут быть тормоза, но просто в режиме репликации (если будет реплицироваться один хост прокса в одно время, несколько в параллель не получится засинкать в любом случае :)) то будет беда. Не рассматривали proxmox backup? Мне кажется для такого массива именно это больше всего подходит.

DALDON ★★★★★
()

Почему так происходит?

Какая-то сборная солянка. zfs set sync=disabled это про запись, а l2arc - про чтение.

Ответ в общем случае - не использовать raidz для гипервизора.

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

Это SMR, так что, аккуратнее: https://m.habr.com/ru/post/500214/

:(

Спасибо. Статью читал, но перед заказом дисков не проверил. Правильно ли я понимаю, что в принципе RAID на SMR использовать возможно, если ограничить скорость синхронизации?

Если Вы для продакшена - то не надо raid6 под виртуалки, сделайте лучше raid10.
И не надо zfs пихать всюду - часто достаточно lvm использовать (особенно если приоритет - производительность, или имеются существенные ограничения по железу).

Планировал использовать так:

основные виртуалки на ssd, с них на hdd часто идет репликация данных.
так же на hdd nextcloud (неинтенсивно используемый).

Сейчас ещё подумаю что теперь с дисками делать…

Tanger ★★★★★
() автор топика
pveversion -v | grep zfs
zfsutils-linux: 0.8.3-pve1
zpool status
  pool: data
 state: ONLINE
  scan: scrub repaired 0B in 0 days 00:29:23 with 0 errors on Sun Dec 13 00:53:25 2020
config:

        NAME                                STATE     READ WRITE CKSUM
        data                                ONLINE       0     0     0
          mirror-0                          ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:0:0   ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:1:0   ONLINE       0     0     0
          mirror-1                          ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:2:0   ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:3:0   ONLINE       0     0     0
          mirror-2                          ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:4:0   ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:5:0   ONLINE       0     0     0
          mirror-3                          ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:6:0   ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:7:0   ONLINE       0     0     0
          mirror-4                          ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:8:0   ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:9:0   ONLINE       0     0     0
          mirror-5                          ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:10:0  ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:11:0  ONLINE       0     0     0
          mirror-6                          ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:12:0  ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:13:0  ONLINE       0     0     0
          mirror-7                          ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:14:0  ONLINE       0     0     0
            pci-0000:03:00.0-scsi-0:2:15:0  ONLINE       0     0     0
        cache
          ata-SSD_240GB_1907S0620A000250    ONLINE       0     0     0

errors: No known data errors
zfs get sync
NAME                      PROPERTY  VALUE     SOURCE
data                      sync      standard  default
data/vm-100-disk-0        sync      standard  default
data/vm-200-disk-0        sync      standard  default
data/vm-201-disk-0        sync      standard  default
data/vm-301-disk-0        sync      standard  default
data/vm-302-disk-0        sync      standard  default
data/vm-303-disk-0        sync      standard  default
data/vm-401-disk-0        sync      standard  default
data/vm-402-disk-0        sync      standard  default
data/vm-403-disk-0        sync      standard  default
data/vm-501-disk-0        sync      standard  default
data/vm-502-disk-0        sync      standard  default
data/vm-503-disk-0        sync      standard  default
data/vm-601-disk-0        sync      standard  default
data/vm-602-disk-0        sync      standard  default
data/vm-603-disk-0        sync      standard  default

около 60-80к ips выдаёт виртуалка с ubuntu 18.04 на сколько помню.

не использую ничего кроме raid10 в том числе на ZFS уже много лет и не могу собрать подобный как у тебя стенд чтобы подтвердить проблему, но в первую очередь предлагаю грешить на pve, как на самых кривых сборщиков ядра/драйверов/чего угодно.

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

Да у тебя тоже жеж pve и ты не грешишь :) Там у парня диски 5400, raidz2

Ну и в твоём сетапе, то кстати: откуда 60k в режиме sync? Весь raid10 у тебя на ssd? Тогда у тебя cache девайс является узким местом, и от него нужно избавляться же.

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

Да какая разница какая модель? У меня дохнет всё. Hitachi (ещё до WD которые) - две штуки умерло одновременно в массиве давича. Не пожалел я что держу тройное зеркало. WD - уже со счету сбился сколько у меня вылетает. Что там остаётся? Toshiba? Samsung?

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

Жизнь — боль, да.

Но конкретно Seagate Barracuda — это стабильная смертность, причём на ровном месте. Не зависит от модели/партии, просто Seagate скатились.

Hitachi (ещё до WD которые) - две штуки умерло одновременно в массиве давича.

У меня та же история с Seagate. Заменил их на другие Seagate и они через три-пять месяцев тоже сдохли.

Зато Hitachi (до WD), ему уже лет десять, шуршит, немного просела скорость, но работает. Ещё были, но все раздал, потому что 500G — это нынче очень мало. ☺

К WD у меня была нелюбовь, но с покупкой Hitachi они таки подняли планку качества. А вот Hitachi, говорят, скатились.

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

Это SMR, так что, аккуратнее: https://m.habr.com/ru/post/500214/

Хм. А что у нас сейчас вообще остается из бюджетного сегмента 2.5"? Даже на 1TB не особо видно.

Что из этого брать можно?

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

Так и чего сейчас остаётся покупать? :)

Откапывать старые диски со свалок остаётся. (%

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

Вы хотите в 2021 году вкладывать деньги в HDD 2,5?

У меня есть 8 слотов 2.5".

В 2х из них сидят 2TB SSD: Intel SSDSC2KG019T801.

4Tb SSD мне достаточно. Объединять их в зеркало несколько жалко. (Кроме того не знаю насколько осмысленно. Раньше считал что у SSD небольшой ресурс и если одновременно поставить два диска в зеркало - они и умрут примерно в один день. Но, учитывая высокий DWPD у современных SSD, вероятно это не так.)

Для сохранности данных хочу регулярно бекапиться/реплицироваться на HDD RAID из 6ти дисков.

Плохая идея?

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

Если бэкапиться - то ок. Но вот для запуска виртуалок это будет плохо подходить.

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

Это SMR, так что, аккуратнее: https://m.habr.com/ru/post/500214/

Вообще вроде производительность последовательной записи на mdraid более-менее приемлема:

# dd if=/dev/urandom of=/dev/md0 bs=10M status=progress conv=sync
8000991395840 bytes (8.0 TB, 7.3 TiB) copied, 57455 s, 139 MB/s
dd: error writing '/dev/md0': No space left on device
763041+0 records in
763040+0 records out
8001054310400 bytes (8.0 TB, 7.3 TiB) copied, 57622.7 s, 139 MB/s

За 16 часов весь массив записался.

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