Думаю кто-то уже сталкивался, по этому решил задать вопрос здесь, копаю уже давно но пока не могу понять что именно дает проблему.
Есть 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
