LINUX.ORG.RU
ФорумAdmin

Низкая производительность LinuxZFS

 , ,


0

6

Думаю кто-то уже сталкивался, по этому решил задать вопрос здесь, копаю уже давно но пока не могу понять что именно дает проблему. Есть 3 сервера: 1. Торент качался, около 0.7Тб в раздаче, ОС Proxmox4 zfs, 4диска, WD 500Enterprise. Intel(R) Xeon(R) CPU E31260L @ 2.40GHz/8GB SSD Crucial BX100 120GB 2.5" SATAIII MLC в качестве cache и logs

2. Proxmox4 zfs , 20 клинтских серверов с FreeBSD 8.4, система на SSD, zfs из 4х дисков 1ТБ WD Ent 64Mb в raid 10, в качестве cache для zfs Solid State Drive DC S3510 120GB Intel(R) Xeon(R) CPU E5620 @ 2.40GHz x2, итого 16 ядер. 48GB памяти.

3. Proxmox Zfs, система на SSD Intel 530, 4диска 1TB WD, zfs без кэша на ssd. 48GB памяти.

*******

Сервер 1, Torrent:

 
|---------------------------------------------------------------------------------------------------------------------|
|l1reads    l1miss     l1hits     l1hit%     size  |  l2reads    l2misses   l2hits     l2hit%     size   disk_access% |            
|---------------------------------------------------------------------------------------------------------------------|
|3975337678 124722716  3850614962 96.862%    0 GB  |  9310188    2009521    7300667    78.415%    97GB    2.354%     |         
|3975337691 124722716  3850614975 96.862%    0 GB  |  9310188    2009521    7300667    78.415%    97GB    2.354%     |         
|3975337691 124722716  3850614975 96.862%    0 GB  |  9310188    2009521    7300667    78.415%    97GB    2.354%     |         
|3975337697 124722716  3850614981 96.862%    0 GB  |  9310188    2009521    7300667    78.415%    97GB    2.354%     |         
|3975337697 124722716  3850614981 96.862%    0 GB  |  9310188    2009521    7300667    78.415%    97GB    2.354%     |         
|3975337697 124722716  3850614981 96.862%    0 GB  |  9310188    2009521    7300667    78.415%    97GB    2.354%     |         
|3975337714 124722716  3850614998 96.862%    0 GB  |  9310188    2009521    7300667    78.415%    97GB    2.354%     |         
|3975337714 124722716  3850614998 96.862%    0 GB  |  9310188    2009521    7300667    78.415%    97GB    2.354%     |         
|3975337717 124722716  3850615001 96.862%    0 GB  |  9310188    2009521    7300667    78.415%    97GB    2.354%     |         

options zfs zfs_arc_min=536870912
options zfs zfs_arc_max=2147483648
options zfs zfs_prefetch_disable=1
options zfs zfs_vdev_max_pending=1
Этот тазик работает как часы, раздает и принимает не убивая диски и не перегружая систему, все абсолютно ровно и гладко.

Проблемы начинаются с сервером где находятся клиентские виртуалки, дисковая подсистема значительно тормозит, периодами диски стоят в полке по загрузки и ничего не сделаешь, бэкапы идут очень медленно. Тут началось самое интересное, сначала создавал виртуалки на разделе который был прописан в интерфейсе как zfs, если правильно скажу, то создавал отдельный dataset под каждую виртуалку.

3й сервер, zfs настроенна также как и там где клиентские виртуалки, опытным путем сделано на нем несколько тестов и выявленны такие же проблемы с производительностью как и сервера с клиентскими виртуалками, усе тормозит. Убрал хранение виртуалок как отдельный zvol для каждой машины и сделал как обычная директория с raw файлами внутри, скорость внутри машин поднялась, но только на уровне кэшей системы, хотя прирост значительный.

Дальше начались эксперементы, сейчас вышел к такому:

fio --name fio_test_file --direct=0 --rw=randwrite --bs=32768 --size=10G --numjobs=16 --time_based --runtime=180 --group_reporting                                                             
fio_test_file: (g=0): rw=randwrite, bs=32K-32K/32K-32K/32K-32K, ioengine=sync, iodepth=1
...
fio-2.1.11
Starting 16 processes
Jobs: 16 (f=16): [w(16)] [100.0% done] [0KB/13216KB/0KB /s] [0/413/0 iops] [eta 00m:00s]
fio_test_file: (groupid=0, jobs=16): err= 0: pid=4930: Sun Apr 24 13:29:15 2016
  write: io=2514.8MB, bw=14299KB/s, iops=446, runt=180097msec
    clat (usec): min=19, max=752004, avg=35792.66, stdev=53199.98
     lat (usec): min=20, max=752005, avg=35793.85, stdev=53199.95
    clat percentiles (usec):
     |  1.00th=[   36],  5.00th=[  724], 10.00th=[ 1112], 20.00th=[ 8096],
     | 30.00th=[11328], 40.00th=[14272], 50.00th=[18048], 60.00th=[23168],
     | 70.00th=[31616], 80.00th=[47360], 90.00th=[86528], 95.00th=[132096],
     | 99.00th=[288768], 99.50th=[346112], 99.90th=[444416], 99.95th=[493568],
     | 99.99th=[569344]
    bw (KB  /s): min=   58, max= 2163, per=6.33%, avg=904.52, stdev=356.82
    lat (usec) : 20=0.01%, 50=2.44%, 100=0.17%, 250=0.01%, 750=3.20%
    lat (usec) : 1000=3.68%
    lat (msec) : 2=1.69%, 4=1.43%, 10=13.05%, 20=28.46%, 50=26.88%
    lat (msec) : 100=11.02%, 250=6.55%, 500=1.38%, 750=0.04%, 1000=0.01%
  cpu          : usr=0.03%, sys=0.31%, ctx=79487, majf=0, minf=106
  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    : total=r=0/w=80473/d=0, short=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: io=2514.8MB, aggrb=14298KB/s, minb=14298KB/s, maxb=14298KB/s, mint=180097msec, maxt=180097msec
Как видно 446iops на random write предел, в принципе результат идентичный как и у проблемного второго сервера, от куда взял цифру: 32768 согласно manual:
https://www.freebsd.org/cgi/man.cgi?newfs%288%29

     -b	block-size
	     The block size of the file	system,	in bytes.  It must be a	power
	     of	2.  The	default	size is	32768 bytes, and the smallest allow-
	     able size is 4096 bytes.  The optimal block:fragment ratio	is
	     8:1.  Other ratios	are possible, but are not recommended, and may
	     produce poor results.
Таким образом я подозреваю размер блока файловой системы внутри виртуалок что именно он виновен в падении производительности файловой системы виртуальных машин, во время теста скорость файловых операций на каждом диске не выходила за 40-50мегайт сумарно со всего массива.
                                                  capacity     operations    bandwidth
pool                                           alloc   free   read  write   read  write
---------------------------------------------  -----  -----  -----  -----  -----  -----
data0                                          63.8G  1.75T      0  1.67K      0  69.7M
  mirror                                       31.9G   896G      0  1.14K      0  49.2M
    ata-WDC_WD1002FAEX-00Z3A0_WD-WCATR9310670      -      -      0    464      0  20.1M
    sdd                                            -      -      0    564      0  49.2M
  mirror                                       31.9G   896G      0    546      0  20.5M
    ata-WDC_WD1002FAEX-00Z3A0_WD-WCATR9151303      -      -      0    454      0  20.5M
    sde                                            -      -      0    573      0  4.93M
---------------------------------------------  -----  -----  -----  -----  -----  -----

Может у кого-то будут мысли почему еще может обрущиться производительность файлвой системы?

3й сервер

root@virt03:~# zfs get all data0                                                                                                                                                                              [7/7]
NAME   PROPERTY              VALUE                  SOURCE
data0  type                  filesystem             -
data0  creation              Fri Apr 22 15:21 2016  -
data0  used                  63.5G                  -
data0  available             1.69T                  -
data0  referenced            63.4G                  -
data0  compressratio         1.90x                  -
data0  mounted               yes                    -
data0  quota                 none                   default
data0  reservation           none                   default
data0  recordsize            128K                   default
data0  mountpoint            /data0                 default
data0  sharenfs              off                    default
data0  checksum              on                     default
data0  compression           lz4                    local
data0  atime                 off                    local
data0  devices               on                     default
data0  exec                  on                     default
data0  setuid                on                     default
data0  readonly              off                    default
data0  zoned                 off                    default
data0  snapdir               hidden                 default
data0  aclinherit            restricted             default
data0  canmount              on                     default
data0  xattr                 on                     default
data0  copies                1                      default
data0  version               5                      -
data0  utf8only              off                    -
data0  normalization         none                   -
data0  casesensitivity       sensitive              -
data0  vscan                 off                    default
data0  nbmand                off                    default
data0  sharesmb              off                    default
data0  refquota              none                   default
data0  refreservation        none                   default
data0  primarycache          all                    local
data0  secondarycache        all                    default
data0  usedbysnapshots       0                      -
data0  usedbydataset         63.4G                  -
data0  usedbychildren        38.1M                  -
data0  usedbyrefreservation  0                      -
data0  logbias               latency                default
data0  dedup                 off                    default
data0  mlslabel              none                   default
data0  sync                  standard               default
data0  refcompressratio      1.90x                  -
data0  written               63.4G                  -
data0  logicalused           121G                   -
data0  logicalreferenced     120G                   -
data0  filesystem_limit      none                   default
data0  snapshot_limit        none                   default
data0  filesystem_count      none                   default
data0  snapshot_count        none                   default
data0  snapdev               hidden                 default
data0  acltype               off                    default
data0  context               none                   default
data0  fscontext             none                   default
data0  defcontext            none                   default
data0  rootcontext           none                   default
data0  relatime              off                    default
data0  redundant_metadata    all                    default
data0  overlay               off                    default

data0 compression lz4

возможно из-за этого.

вообще ZFS on Linux возможно и работает но https://smartos.org/ - вот это лучше и таки-да для образов дисков виртуалок там zvol как возможно наиболее удобный. Не знаю есть-ли к тому что я кинул в ссылке веб-харя но почему-то уверен что работать оно должно стабильнее в плане производительности/отказоустойчивости ФС

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

Кто-нибудь вообще это использует? Как оно в работе?

есть проект Illumos - общая кодовая база форка ОпенСоляриса. Конкретно этот дистр от кодовой базы ( которую можно забилдить и самому если есть БОЛЬШОЕ желание и время :) )пилит контора контора Joyent есть ещё OmniTI - OmniOS, Nexenta и т.д. и всё из Иллюмоса. Каждая контора пилит под свои решения и под кастомное железо т.к. там HCL не ахти какой широкий и железки в основном «от штата Калифорния» т.е. хорошие качественные и надёжные. Приглядываюсь к OmniOS т.к. нужна файлосторка для бекапов а сервак который под это пойдёт без аппаратного рейда и нужно чтоб без «сюрпризов». Насколько качественен KVM сказать не могу и как оно там эмулирует железо тоже т.к. не использовал. Сейчас спрыгнул с ESXi на Hyper-V Server Core(бесплатный) т.к. работает на любом CPU где есть VTx+SLAT и нашару лив-миграция и программные рейды + интеграция в домен и т.д. Если контейнерами машины на FreeBSD то рациональнее юзать Jails+zvol т.к. издержки на виртуализацию минимальны. Ещё есть шаровый XEN-Server и немного жалею что не ушел на него, хотя саппорт от оффтопика долгий и гарантированный и как платформа для моего огорода достаточна а что будет с XEN завтра неясно. Не подумай что рекламирую оффтопик. Там хорошие технологии но по сравнению с VMWare это просто поделие для захвата рынка, может в ихних облаках (Azure) оно имеет другой функционал но то что нахаляву убого но зато работает везде.

VKraft ★★
()

Что-то местные zfs-проповедники в технических темах о zfs предпочитают не появляться.

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

да вы прикалываетесь, 956 открытых issuses, походу надо в топку отправлять этот zfs.

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

Насколько качественен KVM сказать не могу и как оно там эмулирует железо тоже т.к. не использовал.

Вот это и интересно. Я чет вообще даже не знал, что Illumos умеет kvm.

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

Насколько качественен KVM сказать не могу и как оно там эмулирует железо тоже т.к. не использовал.

Обычный kvm.

как оно там эмулирует железо

Так же, как и везде - никак, ибо это не эмулятор.

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

Кто-нибудь вообще это использует? Как оно в работе?

Отличная платформа для виртуализации и облаков.

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

на лоре надо церкви зарегистрировать, церковь btrfs, церковь zfs, церковь lvm, церковь ext4. И рядом с ником писать в какой церкви человек относится и статус...

erzentn
()

Покаж 'zpool status data0', а то выхлоп iostat какой-то странный.
А так да, смотри что по размеру блока в гостях, сравнивай, проверь ashift.

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

Ну я к примеру прихожанин: lvm+ext4, zol, zfs on freebsd. :) Слишком толстое описание будет. Но насколько я понял, церковь btrfs, уже можно закрывать.

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

опции создания пула? блоксайз zvol? резирвирование у zvol, процент свободного места на пуле? На raw быстрее если промахнулся с блоксайз у zvol.

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

пул создавался как:

zpool create -f -o ashift=12 data0 /dev/sdb /dev/sdc

zfs get all data0
NAME   PROPERTY              VALUE                  SOURCE
data0  type                  filesystem             -
data0  creation              Fri Apr 22 15:21 2016  -
data0  used                  63.5G                  -
data0  available             1.69T                  -
data0  referenced            63.4G                  -
data0  compressratio         1.90x                  -
data0  mounted               yes                    -
data0  quota                 none                   default
data0  reservation           none                   default
data0  recordsize            128K                   default
data0  mountpoint            /data0                 default
data0  sharenfs              off                    default
data0  checksum              on                     default
data0  compression           lz4                    local
data0  atime                 off                    local
data0  devices               on                     default
data0  exec                  on                     default
data0  setuid                on                     default
data0  readonly              off                    default
data0  zoned                 off                    default
data0  snapdir               hidden                 default
data0  aclinherit            restricted             default
data0  canmount              on                     default
data0  xattr                 on                     default
data0  copies                1                      default
data0  version               5                      -
data0  utf8only              off                    -
data0  normalization         none                   -
data0  casesensitivity       sensitive              -
data0  vscan                 off                    default
data0  nbmand                off                    default
data0  sharesmb              off                    default
data0  refquota              none                   default
data0  refreservation        none                   default
data0  primarycache          all                    local
data0  secondarycache        all                    default
data0  usedbysnapshots       0                      -
data0  usedbydataset         63.4G                  -
data0  usedbychildren        45.3M                  -
data0  usedbyrefreservation  0                      -
data0  logbias               latency                default
data0  dedup                 off                    default
data0  mlslabel              none                   default
data0  sync                  standard               default
data0  refcompressratio      1.90x                  -
data0  written               63.4G                  -
data0  logicalused           121G                   -
data0  logicalreferenced     121G                   -
data0  filesystem_limit      none                   default
data0  snapshot_limit        none                   default
data0  filesystem_count      none                   default
data0  snapshot_count        none                   default
data0  snapdev               hidden                 default
data0  acltype               off                    default
data0  context               none                   default
data0  fscontext             none                   default
data0  defcontext            none                   default
data0  rootcontext           none                   default
data0  relatime              off                    default
data0  redundant_metadata    all                    default
data0  overlay               off                    default

Более не какой специфики, сейчас пул свободен на 90 процентов.

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

data0 checksum on default
data0 compression lz4 local

контрольные суммы ладно но зачем компрессия если данные - большие файлы/zvol под хранение образов дисков? + всё это ещё и на линуксе где zfs ещё во младенчестве.

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

спасибо, буду так делать, но пока дистрибутив сам если видит что буквы поплыли перестравает их на ata-ST1000DX001-1NS162_Z4YAV9Z0

data0 checksum on default
data0 compression lz4 local

выключил, скорость как была никакой, так и есть, тот жэ бэкап виртуалки еле ползет.

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

Местные проповедники zfs еще вещали что на хосте нужно много свободной оперативы для его нормальной работы

anonymous
()

options zfs zfs_vdev_max_pending=1

Интересно, с какого перепугу тебе понадобилось max pending в единицу устанавливать? Такие диски отстойные, что больше одной команды не переваривают?

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

контрольные суммы ладно но зачем компрессия если данные - большие файлы/zvol под хранение образов дисков? + всё это ещё и на линуксе где zfs ещё во младенчестве.

сразу два ничем неподкреплённых заявления в одном параграфе.

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

контрольные суммы ладно но зачем компрессия если данные - большие файлы/zvol под хранение образов дисков? + всё это ещё и на линуксе где zfs ещё во младенчестве.

сразу два ничем неподкреплённых заявления в одном параграфе.

anonymous
()

ТС, тебе бы в школу за учебник русского языка, чтобы научиться грамотно писать и четко формулировать мысли - продираться через этот поток сознания то еще удовольствие.

Я не знаю, почему ты сравниваешь яблоки с апельсинами. У твоих пулов существенно разные конфигурации и разные нагрузки, поэтому ожидать одинаковых результатов - это все равно что сравнивать яблоки с апельсинами.

Я не знаю, зачем тебе на торрентокачалке отдельный диск для ZIL. Я еще могу понять диск для L2ARC, но отдельный диск для ZIL там точно ни к чему. От него было бы гораздо больше пользы в твоей второй конфигурации с виртуалками.

Как видно 446iops на random write предел, в принципе результат идентичный как и у проблемного второго сервера

Если этот fio делает синхронную запись - то это отличный результат для твоей конфигурации с двумя зеркалами из не самых быстрых дисков. Хочешь больше - забирай SSD для ZIL из твоей торрентокачалки и добавляй во вторую или третью конфигурацию. Случайных синхронных операций записи (до определенного размера) оно должно будет прожевывать гораздо больше в теории. На практике ограничение ARC сверху размером в 2GB влияет в числе прочего и на размер грязных данных, так что это тоже может оказаться ограничивающим фактором. Плюс смотри, чтобы размер ввода-вывода из твоей виртуалки не сильно отличался от размера recordsize (или volblocksize), иначе у тебя будет большая инфляция при чтении и очень много RMW.

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

data0 checksum on default
data0 compression lz4 local
выключил, скорость как была никакой, так и есть, тот жэ бэкап виртуалки еле ползет.

файлы УЖЕ созданные с данными параметрами нужно создавать заново - «особенность» ZFS )

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

в NTFS например для этого есть «магическая» галочка - «для этой папки, всех её подпапок и файлов» при изменении параметров/атрибутов, например сжимать или нет, смена АЦЛ. т.е. в твоём случае скорее всего файлы дисков вирт. машин так и остались сжатыми.

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

контрольные суммы ладно но зачем компрессия если данные - большие
файлы/zvol под хранение образов дисков? + всё это ещё и на линуксе
где zfs ещё во младенчестве.

сразу два ничем неподкреплённых заявления в одном параграфе.

Хочешь сказать что при компрессии/декомпреcсии образов дисков вирт.машин можно получить высокие показатели (особенно для той конфигурации которая предъявлена) по iops? Глянь багтрэкер ZOL.

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

создание пула под виртуалки - http://pve.proxmox.com/wiki/Storage:_ZFS

имею такой расклад под виртуалки на з-х машинках опции пула:

zfs set compression=on kvmpool
zfs set atime=off kvmpool
zfs set dedup=off kvmpool
zfs set compression=lz4 kvmpool
volblocksize=64k
массив raid_10 из 4-х SAS 15k(jbod), оперы 128Гб из 256(ECC) отдано zfs, виртуалки часть в raw, часть в zvol(без резирвирования)

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

массив raid_10 из 4-х SAS 15k(jbod), оперы 128Гб из 256(ECC) отдано zfs, виртуалки часть в raw, часть в zvol(без резирвирования)

и давно работает? сколько виртуалок? какая нагрузка? я серьёзно. ещё не праздный вопрос о лив-миграции, только то что написано в вики - с общим хранилищем и кластер?

VKraft ★★
()

Ты это серьезно? На одной машине торренты, которым иопсы пофигу, а на второй 20 виртуалок на 2-х дисках сатовых, и ты спрашиваешь почему тормозит?

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

Кстати ты прав, брат анонимус, вброс очень жидкий.

anonymous
()

крути размер блока zvol'ов чтобы совпадал с размером внутри виртуалки, иначе тебе не миновать read-update-write проблемы...

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