ZFS Appliance. zpool на zpool... А хочется как RAW по скорости!

Что есть - ZFS Appliance 7420 :
DATA: 50.1 ТБ
Parity: 52.9 TB
Reserved: 814 GB
Spare: 5.46 TB

Data+Parity: 38 HDD SATA
Spare: 2 SATA HDD
Log: 8 SSD SLC
Cache: 4 SSD eMLC

Сервер Т4-1, Solaris 11.1 SRU 19.6. Подключен к одному контроллеру Appliance (далее ZFSA) оптикой 4 Гб - один конец - ну нету больше ни SFP ни кабелей. ZFSA только одну голову включили.
На ZFSA делаем два LUN. Первый пусть 20ТБ - это будет файловая система ZFS. Второй том 10ТБ - будет типа RAW. По крайней мере не буду делать из него zpool/zfs.

Ставим Vdbench 5.2.
Делаем такой профиль нагрузки:

sd=sd1,lun=/dev/dsk/c0t600144F0D38CB9FD0000539856550004d0s0,threads=500
wd=wd1,sd=sd1,xfersize=8k,rdpct=70
rd=rd1,wd=wd1,iorate=max,elapsed=3000,interval=1

То есть наш LUN 10TB будем нагружать 500-ми потоками на чтение блоками 8К - 70% и остальные 30% - запись теми же блоками 8К.

Что получаем (в среднем вот такая картинка на всём протяжении трех тысяч тестовых попыток)
Jun 11, 2014  interval        i/o   MB/sec   bytes   read     resp     resp     resp    cpu%  cpu%
                             rate  1024**2     i/o    pct     time      max   stddev sys+usr   sys
21:59:20.014        31   12118.00    94.67    8192  69.54   41.088  117.648   29.401     2.2   1.8
21:59:21.027        32    9844.00    76.91    8192  69.98   49.287  189.694   39.058     1.6   1.4
21:59:22.014        33    8846.00    69.11    8192  70.42   58.373  278.969   47.641     1.6   1.3
21:59:23.015        34   11991.00    93.68    8192  70.09   41.427  114.597   29.526     1.9   1.6
21:59:24.014        35   11972.00    93.53    8192  69.29   41.832  116.797   30.124     2.0   1.7
21:59:25.014        36   11843.00    92.52    8192  69.64   42.325  117.584   30.306     2.5   1.9

#iostat -zxne 5
  r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b s/w h/w trn tot device
7903.9 3364.8 63231.4 26918.3 254.9 256.1   22.6   22.7 100 100   0   0   0   0 c0t600144F0D38CB9FD0000539856550004d0

Обращаю внимание на actv=256
Похожие результаты имеем от 250 до 500 потоков. При 600-х вся картина становится грустной - перегрузка массива запросами, резкое увеличение response time, на порядки снижается IOPS.

Что мне хотелось бы - сделать теперь zpool/zfs со вторым томом и получить похожую картинку на той же нагрузке. Я понимаю, что ZFSA это уже ZPOOL/ZFS со всем что нужно настроить в этой связке и мне бы использовать ASM для работы с СУБД, но мой ДБА не умеет и не знает что такое ASM.

Создаем zpool db1 с одним томом 20ТБ с ZFSA.
Делаем профиль нагрузки :
fsd=fsd1,anchor=/db1/fs0,depth=1,width=1,files=1000,size=1g
fwd=fwd1,fsd=fsd1,xfersize=8k,fileio=random,fileselect=random,rdpct=70,threads=500
rd=rd1,fwd=fwd1,fwdrate=max,format=yes,elapsed=3000,interval=1

Тут моя файловая система /db1. В ней будет создана структура файлов - 1000 файлов по 1ГБ каждый. 

Но прежде чем запустить работу vdbench, я настрою zfs как в мануале по Performance tuning а именно:

zfs set atime=off db1

zfs set logbias=throughput db1

zfs set recordsize=8k db1

в параметрах /etc/system у меня классическое:

set zfs:zfs_arc_max = 0x180000000

set zfs:zfs_vdev_max_pending=32

Запускаемся. Сначала vdbench будет очень долго трудиться над созданием структуры файлов. Он это делает по 8 потоков блоками 64К. Долго. Сделал.

Теперь начинаем работу - читаем 70% блоками 8К, файлы выбираем случайно.

Смотрим на статистику iostat/vdbench. Больше 2000 IOPS не получается.

ДАЛЕЕ - что я делаю то НЕ РЕКОМЕНДУЮ ДЕЛАТЬ БЕЗ ПОНИМАНИЯ ЗАЧЕМ Я ЭТО ДЕЛАЮ! НЕ ДЕЛАЙТЕ ЭТОГО У СЕБЯ БЕЗДУМНО!

1. Снимаем ограничение на глубину очереди :

echo zfs_vdev_max_pending/W0t256 | mdb -kw

Результат конечно же будет сразу - мы видим 3-4 тысячи IOPS вместо 2-х тысяч.

2. Снимаем кэшировку в NVRAM:

echo zfs_nocacheflush/W0t1 |mdb -kw

Результат стал получше но мало изменилось, совсем мало + 500 IOPS.

3. Что может мешать работать zfs как RAW ? В моем понимании в этой ситуации - память ядра, которая работает как буферный кэш. Отвязываюсь от нее:

zfs set primarycache=none db1

zfs set secondarycache=none db1

Результаты видим сразу - до 6-7 тысяч подросли.

4. ОСТОРОЖНО! НЕ ПОВТОРЯТЬ без понимания!

ZFS имеет параметры и поведение, согласно которому вот что происходит:

Параметр zfs_txg_synctime_ms у меня был равен 5000 мс.

#echo zfs_txg_synctime_ms/D |mdb -k

zfs_txg_synctime_ms:

zfs_txg_synctime_ms:            5000

Что это значит - 5000 ms * dp_throughput (1000B/ms) = 5 000 000 B  - это лимит записи (write limit). И как он набирается, zfs блокирует операции записи, пока не сбросит его на диски. После сброса (sync) продолжаем работать. 

Снижаем до 1мс:

echo zfs_txg_synctime_ms/W0t1 | mdb -kw

zfs_txg_synctime_ms:            0x1388          =       0x1

Зачем? Моя задача сделать из zfs -> RAW , но как бы отвязаться от буферизации в памяти.

Может есть forcedirectio у ZFS ?? Я не нашел.

Зато vdbench работает и iostat показывает:

r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b s/w h/w trn tot device

9459.6 1863.7 33980.4 33757.8  1.1 25.2    0.1    2.2  11  97   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

9862.5 1877.2 39283.4 34031.1  1.3 26.7    0.1    2.3  11  98   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

9840.9 2011.3 39882.0 33009.7  1.3 30.2    0.1    2.6  11  95   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

Увеличу количество потоков до 1000:

 13428.7 1546.8 42924.2 27747.3 14.0 41.6    0.9    2.8  16  96   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

 12028.1 1415.2 40124.5 25257.1 15.0 41.5    1.1    3.1  16  93   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

12909.0 1325.1 44641.5 23010.3 16.0 45.1    1.1    3.2  17  97   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

13653.4 1399.0 48039.5 25726.9 15.0 44.0    1.0    2.9  17  97   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

14593.8 1719.1 51977.4 28239.7 17.2 49.4    1.1    3.0  20  94   0   6   0   6 c0t600144F0D38CB9FD00005396B9480003d0

Это выглядит даже лучше чем RAW :))))

Вопросов больше чем ответов пока. 

Немного по настройкам томов на ZFSA. Я выключил на вкладке Shares->LUNs->Protocol галку Write cache enabled. Ибо судя по блогу одного из ораклистов при включеной этой опции мы имеем синхронные записи во флеш (Writezilla) а потом в DRAM. Оно хорошо бы включить для скорости эту опцию (с потерей в надежности!!!!) когда ZFSA поставляется БЕЗ WriteZilla. Они кстати стоят на каждой полке с дисками а ReadZilla - на контроллерах.

Для LUN db1 были умолчания: write bias = latency, cache device = all, Single copy, Fletcher4, Compression=off. Thin provision =off.

PS: кстати... Вот что попробовал и получил в догонку.

Если в настройках тома установить write bias = throughput, IOPS падают в разы - оно и понятно, поведение при такой настройке говорит делать sync на диски чаще. Тут нам поможет как раз Write cache enabled на вкладке Protocol. 

Включив Write cache enabled получаем еще лучше вариант по IOPS:

#iostat -zxne 5

 r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b s/w h/w trn tot device

 17265.6 1898.4 85969.1 29162.4 25.7 75.8    1.3    4.0  26  93   0   8   0   8 c0t600144F0D38CB9FD00005396B9480003d0

15672.3 1554.0 76992.3 28906.9 24.3 60.5    1.4    3.5  24  98   0   8   0   8 c0t600144F0D38CB9FD00005396B9480003d0

 16188.2 1471.3 79249.6 26984.2 24.8 61.3    1.4    3.5  24  98   0   8   0   8 c0t600144F0D38CB9FD00005396B9480003d0

Коллеги, не надо критиковать - это чисто эксперимент и не более того:)