понедельник, 10 января 2011 г.

Насколько необходим directio в ZFS?

Файловые системы, не являющиеся ZFS -
не такие превосходные, как ZFS.


(фраза участника одного из

зарубежных профессиональных форумов)

Мне не раз приходилось слышать о том, что-де архитектура ZFS плохо подходит для Oracle с его собственным кэшированием, что было бы совсем хорошо, если бы можно было отключить кэширование ZFS подобно тому, как это делается для UFS при монтировании с опцией directio.

Directio в ZFS нет и не будет, вопрос необходимости такой опции мне лично предоставляется спорным, однако это тема несколько иной статьи.

Что до архитектуры, то большинство ФС являются кэширующими, и если кэш ФС вам реально мешает - всегда есть два выхода. Использование raw devices (в новых версиях Оракла прямо не поддерживаемых) и ASM (сиречь OCFS). Это тоже тема другой статьи, как и необходимость использования именно некэширующих файловых систем и очень спорная тема.

Давайте проведем небольшой эксперимент и выясним, можно ли отключить кэширование ZFS и каким образом. А также - как это скажется на поведении БД.

Для начала небольшая вводная по архитектуре текущей версии ZFS.

ARC по своей природе устроен в виде двухуровневой структуры. Собственно ARC в памяти (L1), и кэш второго уровня (L2) на диске, управляемые, в свою очередь, параметрами primarycache и secondarycache.

Поскольку ZFS кэширующая по своей природе, отключить ARC в оперативной памяти полностью не удастся:

*Default arc min is 12% of memory (see CR 6855793)
*Set zfs_arc_min if applications have a chance to consume more than this.
*zfs_arc_min should be at least 64MB and not more than arc_c_max (zfs_arc_max).

что можно легко подтвердить попыткой зануления параметра zfs_arc_max в /etc/system (set zfs:zfs_arc_max=0). То есть, если установить этот параметр равным нулю, а потом посмотреть на значения величин кэша, можно легко убедиться (например, при помощи скрипта arc_summary.pl), что нулевое значение игнорируется полностью.

Однако, при желании, можно почти полностью отключить использование кэша ARC в памяти параметром primarycache=none. А также практически полностью исключить влияние кэша второго уровня на БД, установив параметр secondarycache=none. Что в принципе эквивалентно монтированию в режиме directio.

Резонный вопрос, даст ли это хороший выигрыш.

В действительности - совершенно не факт.

Апологеты использования raw devices почему-то наивно считают, что в СУБД-приложениях получат хороший выигрыш в производительности. Это не так. Максимальный выигрыш, который в принципе удается получить при размещении БД на сырых устройствах, составляет 7-10%. При этом на свою голову вы получаете неслабые проблемы с администрированием (например, выполнение холодных бэкапов совсем не тривиально для сырых устройств и уж точно не быстро). Более того, попытки таким образом решить проблемы с узкими местами систем хранения и, тем более, с кривизной запросов, обречены на неудачу. И, более того, практические опыты с directio на UFS показывают, как правило, падение скорости обменных операций БД.

Осталось посмотреть на кэш L1/L2 ZFS и его влияние на работу БД. Давайте проведем небольшой эксперимент.

Сначала посмотрим текущие значения параметров кэша L1/L2 по умолчанию для пула, на котором у нас установлена БД:

root @ pegasus / # zfs get all data
...
data primarycache all default
data secondarycache all default
...

Перезапустим базу для того, чтобы кэш БД был холодным и несколько раз выполним простенький запрос к маленькой табличке:

oracle @ pegasus ~ $ sqlplus scott/tiger

SQL*Plus: Release 10.2.0.5.0 - Production on Пн Янв 10 15:14:56 2011

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Oracle Label Security, Data Mining and Real Application Testing options

SQL> set timing on
SQL> select * from emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17.12.80 800
20

7499 ALLEN SALESMAN 7698 20.02.81 1600 300
30

7521 WARD SALESMAN 7698 22.02.81 1250 500
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02.04.81 2975
20

7654 MARTIN SALESMAN 7698 28.09.81 1250 1400
30

7698 BLAKE MANAGER 7839 01.05.81 2850
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09.06.81 2450
10

7788 SCOTT ANALYST 7566 09.12.82 3000
20

7839 KING PRESIDENT 17.11.81 5000
10


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08.09.81 1500 0
30

7876 ADAMS CLERK 7788 12.01.83 1100
20


11 rows selected.

Elapsed: 00:00:00.63

SQL> select * from emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17.12.80 800
20

7499 ALLEN SALESMAN 7698 20.02.81 1600 300
30

7521 WARD SALESMAN 7698 22.02.81 1250 500
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02.04.81 2975
20

7654 MARTIN SALESMAN 7698 28.09.81 1250 1400
30

7698 BLAKE MANAGER 7839 01.05.81 2850
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09.06.81 2450
10

7788 SCOTT ANALYST 7566 09.12.82 3000
20

7839 KING PRESIDENT 17.11.81 5000
10


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08.09.81 1500 0
30

7876 ADAMS CLERK 7788 12.01.83 1100
20


11 rows selected.

Elapsed: 00:00:00.02

SQL> set timing off

Запомним время выполнения первого запроса (до кэширования таблицы Ораклом).

Посмотрим на статистику ARC:

root @ pegasus / # arc_summary.pl
System Memory:
Physical RAM: 1759 MB
Free Memory : 551 MB
LotsFree: 27 MB

ZFS Tunables (/etc/system):

ARC Size:
Current Size: 462 MB (arcsize)
Target Size (Adaptive): 1319 MB (c)
Min Size (Hard Limit): 164 MB (zfs_arc_min)
Max Size (Hard Limit): 1319 MB (zfs_arc_max)

ARC Size Breakdown:
Most Recently Used Cache Size: 50% 659 MB (p)
Most Frequently Used Cache Size: 50% 659 MB (c-p)

ARC Efficency:
Cache Access Total: 140823
Cache Hit Ratio: 85% 119956 [Defined State for buffer]
Cache Miss Ratio: 14% 20867 [Undefined State for Buffer]
REAL Hit Ratio: 80% 112670 [MRU/MFU Hits Only]

Data Demand Efficiency: 91%
Data Prefetch Efficiency: 22%

CACHE HITS BY CACHE LIST:
Anon: 6% 7226 [ New Customer, First Cache Hit ]
Most Recently Used: 23% 28020 (mru) [ Return Customer ]
Most Frequently Used: 70% 84650 (mfu) [ Frequent Customer ]
Most Recently Used Ghost: 0% 19 (mru_ghost) [ Return Customer Evicted, Now Back ]
Most Frequently Used Ghost: 0% 41 (mfu_ghost) [ Frequent Customer Evicted, Now Back ]
CACHE HITS BY DATA TYPE:
Demand Data: 67% 81176
Prefetch Data: 2% 2641
Demand Metadata: 25% 30995
Prefetch Metadata: 4% 5144
CACHE MISSES BY DATA TYPE:
Demand Data: 38% 7959
Prefetch Data: 43% 9108
Demand Metadata: 10% 2149
Prefetch Metadata: 7% 1651
---------------------------------------------

Запретим кэшировать все на первом и втором уровне:

root @ pegasus / # zfs set primarycache=none data
root @ pegasus / # zfs set secondarycache=none data
root @ pegasus / # zfs get primarycache data
NAME PROPERTY VALUE SOURCE
data primarycache none local
root @ pegasus / # zfs get secondarycache data
NAME PROPERTY VALUE SOURCE
data secondarycache none local

Перезапустим систему для чистоты эксперимента и выполним несколько раз тот же самый запрос к той же самой таблице:

oracle @ pegasus ~ $ sqlplus scott/tiger

SQL*Plus: Release 10.2.0.5.0 - Production on Пн Янв 10 15:27:49 2011

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, Oracle Label Security, Data Mining and Real Application Testing options

SQL> set timing on
SQL> select * from emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17.12.80 800
20

7499 ALLEN SALESMAN 7698 20.02.81 1600 300
30

7521 WARD SALESMAN 7698 22.02.81 1250 500
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02.04.81 2975
20

7654 MARTIN SALESMAN 7698 28.09.81 1250 1400
30

7698 BLAKE MANAGER 7839 01.05.81 2850
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09.06.81 2450
10

7788 SCOTT ANALYST 7566 09.12.82 3000
20

7839 KING PRESIDENT 17.11.81 5000
10


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08.09.81 1500 0
30

7876 ADAMS CLERK 7788 12.01.83 1100
20


11 rows selected.

Elapsed: 00:00:00.27

SQL> /

EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17.12.80 800
20

7499 ALLEN SALESMAN 7698 20.02.81 1600 300
30

7521 WARD SALESMAN 7698 22.02.81 1250 500
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02.04.81 2975
20

7654 MARTIN SALESMAN 7698 28.09.81 1250 1400
30

7698 BLAKE MANAGER 7839 01.05.81 2850
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09.06.81 2450
10

7788 SCOTT ANALYST 7566 09.12.82 3000
20

7839 KING PRESIDENT 17.11.81 5000
10


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08.09.81 1500 0
30

7876 ADAMS CLERK 7788 12.01.83 1100
20


11 rows selected.

Elapsed: 00:00:00.12

SQL> set timing off

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

Проверим статистику ARC:

root @ pegasus / # arc_summary.pl
System Memory:
Physical RAM: 1759 MB
Free Memory : 787 MB
LotsFree: 27 MB

ZFS Tunables (/etc/system):

ARC Size:
Current Size: 210 MB (arcsize)
Target Size (Adaptive): 1319 MB (c)
Min Size (Hard Limit): 164 MB (zfs_arc_min)
Max Size (Hard Limit): 1319 MB (zfs_arc_max)

ARC Size Breakdown:
Most Recently Used Cache Size: 50% 659 MB (p)
Most Frequently Used Cache Size: 50% 659 MB (c-p)

ARC Efficency:
Cache Access Total: 180400
Cache Hit Ratio: 44% 80577 [Defined State for buffer]
Cache Miss Ratio: 55% 99823 [Undefined State for Buffer]
REAL Hit Ratio: 42% 76312 [MRU/MFU Hits Only]

Data Demand Efficiency: 57%
Data Prefetch Efficiency: 19%

CACHE HITS BY CACHE LIST:
Anon: --% Counter Rolled.
Most Recently Used: 13% 11140 (mru) [ Return Customer ]
Most Frequently Used: 80% 65172 (mfu) [ Frequent Customer ]
Most Recently Used Ghost: 11% 9001 (mru_ghost) [ Return Customer Evicted, Now Back ]
Most Frequently Used Ghost: 94% 75979 (mfu_ghost) [ Frequent Customer Evicted, Now Back ]
CACHE HITS BY DATA TYPE:
Demand Data: 62% 50721
Prefetch Data: 0% 107
Demand Metadata: 31% 25556
Prefetch Metadata: 5% 4193
CACHE MISSES BY DATA TYPE:
Demand Data: 38% 38254
Prefetch Data: 0% 433
Demand Metadata: 59% 59630
Prefetch Metadata: 1% 1506
---------------------------------------------

Обратите внимание, что, хотя коэффициент кэш-попаданий и уменьшился почти вдвое(REAL Hit Ratio), время выполнения первого запроса при холодном кэше базы все же стало вдвое лучше, чем при включенном кэшировании L1/L2 ZFS.

С чем связано такое ухудшение скорости при повторном выполнении запросов к уже кэшированной таблице? Навскидку объяснения у меня нет, есть предположение, связанное с тем, что мы отключили кэширование на всем пуле, где находится и БД и софт Oracle.

Замечание. Ухудшение кэш-попаданий файловой системы имеет очевидную причину - мы запретили кэширование данных и получаем их в кэш БД практически непосредственно, при этом мы не кэшируем также другие части БД и собственно установленное ПО, что при повторных обращениях ухудшает статистику кэша ФС.

Так как пул разбит на датасеты, установим атрибуты отключения кэша L1/L2 только на тех датасетах, на которых находится БД и повторим эксперимент (глобально на всем сторидж-пуле включим кэширование L1/L2 обратно):

root @ pegasus / # zfs list
NAME USED AVAIL REFER MOUNTPOINT
data 11.0G 8.54G 36K /data
data/OraHome1 3.37G 8.54G 3.37G /data/OraHome1
data/OraHome2 716M 8.54G 716M /data/OraHome2
data/apex 785M 8.54G 785M /data/apex
data/oradata 2.50G 8.54G 1.98G /data/oradata
data/oradata/flash 21K 8.54G 21K /data/oradata/flash
data/oradata/plsql_libs 219M 8.54G 219M /data/oradata/plsql_libs
data/oradata/redo1 157M 8.54G 157M /data/oradata/redo1
data/oradata/redo2 157M 8.54G 157M /data/oradata/redo2

root @ pegasus / # zfs set primarycache=none data/oradata/redo1
root @ pegasus / # zfs set primarycache=none data/oradata/redo2
root @ pegasus / # zfs set primarycache=none data/oradata/flash
root @ pegasus / # zfs set primarycache=none data/oradata
root @ pegasus / # zfs set primarycache=all data/oradata/plsql_libs
root @ pegasus / # zfs set secondarycache=none data/oradata/redo1
root @ pegasus / # zfs set secondarycache=none data/oradata/redo2
root @ pegasus / # zfs set secondarycache=none data/oradata/flash
root @ pegasus / # zfs set secondarycache=none data/oradata
root @ pegasus / # zfs set secondarycache=all data/oradata/plsql_libs

SQL> select * from emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17.12.80 800
20

7499 ALLEN SALESMAN 7698 20.02.81 1600 300
30

7521 WARD SALESMAN 7698 22.02.81 1250 500
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02.04.81 2975
20

7654 MARTIN SALESMAN 7698 28.09.81 1250 1400
30

7698 BLAKE MANAGER 7839 01.05.81 2850
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09.06.81 2450
10

7788 SCOTT ANALYST 7566 09.12.82 3000
20

7839 KING PRESIDENT 17.11.81 5000
10


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08.09.81 1500 0
30

7876 ADAMS CLERK 7788 12.01.83 1100
20


11 rows selected.

Elapsed: 00:00:00.23
SQL> /

EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17.12.80 800
20

7499 ALLEN SALESMAN 7698 20.02.81 1600 300
30

7521 WARD SALESMAN 7698 22.02.81 1250 500
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02.04.81 2975
20

7654 MARTIN SALESMAN 7698 28.09.81 1250 1400
30

7698 BLAKE MANAGER 7839 01.05.81 2850
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09.06.81 2450
10

7788 SCOTT ANALYST 7566 09.12.82 3000
20

7839 KING PRESIDENT 17.11.81 5000
10


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08.09.81 1500 0
30

7876 ADAMS CLERK 7788 12.01.83 1100
20


11 rows selected.

Elapsed: 00:00:00.01
SQL> /

EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7369 SMITH CLERK 7902 17.12.80 800
20

7499 ALLEN SALESMAN 7698 20.02.81 1600 300
30

7521 WARD SALESMAN 7698 22.02.81 1250 500
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7566 JONES MANAGER 7839 02.04.81 2975
20

7654 MARTIN SALESMAN 7698 28.09.81 1250 1400
30

7698 BLAKE MANAGER 7839 01.05.81 2850
30


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7782 CLARK MANAGER 7839 09.06.81 2450
10

7788 SCOTT ANALYST 7566 09.12.82 3000
20

7839 KING PRESIDENT 17.11.81 5000
10


EMPNO ENAME JOB MGR HIREDATE SAL COMM
---------- ---------- --------- ---------- -------- ---------- ----------
DEPTNO
----------
7844 TURNER SALESMAN 7698 08.09.81 1500 0
30

7876 ADAMS CLERK 7788 12.01.83 1100
20


11 rows selected.

Elapsed: 00:00:00.02

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

Проверим статистику ARC:

root @ pegasus / # arc_summary.pl
System Memory:
Physical RAM: 1759 MB
Free Memory : 796 MB
LotsFree: 27 MB

ZFS Tunables (/etc/system):

ARC Size:
Current Size: 257 MB (arcsize)
Target Size (Adaptive): 1319 MB (c)
Min Size (Hard Limit): 164 MB (zfs_arc_min)
Max Size (Hard Limit): 1319 MB (zfs_arc_max)

ARC Size Breakdown:
Most Recently Used Cache Size: 50% 659 MB (p)
Most Frequently Used Cache Size: 50% 659 MB (c-p)

ARC Efficency:
Cache Access Total: 127803
Cache Hit Ratio: 83% 106971 [Defined State for buffer]
Cache Miss Ratio: 16% 20832 [Undefined State for Buffer]
REAL Hit Ratio: 80% 102670 [MRU/MFU Hits Only]

Data Demand Efficiency: 90%
Data Prefetch Efficiency: 37%

CACHE HITS BY CACHE LIST:
Anon: --% Counter Rolled.
Most Recently Used: 20% 22190 (mru) [ Return Customer ]
Most Frequently Used: 75% 80480 (mfu) [ Frequent Customer ]
Most Recently Used Ghost: 0% 731 (mru_ghost) [ Return Customer Evicted, Now Back ]
Most Frequently Used Ghost: 6% 6684 (mfu_ghost) [ Frequent Customer Evicted, Now Back ]
CACHE HITS BY DATA TYPE:
Demand Data: 72% 77064
Prefetch Data: 1% 1153
Demand Metadata: 23% 25247
Prefetch Metadata: 3% 3507
CACHE MISSES BY DATA TYPE:
Demand Data: 40% 8473
Prefetch Data: 9% 1926
Demand Metadata: 43% 9024
Prefetch Metadata: 6% 1409
---------------------------------------------

Как видите, статистика вернулась почти к своему первоначальному виду, при заметном сокращении времени чтения таблицы в холодный кэш базы данных.

Итак, что мы выяснили? Кэш L1/L2 в ZFS для баз данных Оракла в нашем случае действительно реально не требуется. И отключается кэширование без перестроения файловой системы парой команд. Если только - обратите внимание! - вам не нужно постоянно дергать статические файлы с диска - бинарники или библиотеки, файловые компоненты веб-фронта итп. Датасет с такими данными лучше оставить с параметрами кэша L1/L2 по умолчанию, что мы и сделали (нативно скомпилированные объектные библиотеки PL/SQL) выше.

Прошу заметить, что отключение кэша ARC L1, в отличие от кэширования L2, может оказаться вредным конкретно для вашей БД. Мы провели эксперимент с крошечной таблицей и запросом, выполняющим очевидный полный скан. В случае повторяющихся диапазонных сканов в запросах с соединением nested loops и при использовании индексов отключение кэша L1 может реально привести к снижению производительности.

Вывод следующий. Дисковый кэш L2 для базы достаточно часто может оказаться избыточным. Кэш L1 - зависит от характера базы. В более общем случае лично я бы не отключал кэширование первого уровня полностью, а кэшировал бы только метаданные (для сохранения скорости доступа к файлам) установкой параметра primarycache=metadata.

Остается один вопрос - с какой целью было сделано дисковое кэширование второго уровня?

Все очень просто. ZFS - файловая система общего назначения (совмещенная с volume manager, но это и так очевидно), в частности, предназначенная в числе прочего для создания файловых хранилищ. Кэш L2 может, конечно, располагаться на тех же устройствах, что и основной пул хранения, но в первую очередь это функциональность файловых хранилищ с гибридной структурой. Например, основной массив данных хранится на дешевых дисках JBOD с интерфейсами SATA, а кэш L2 и ZIL вынесены на отдельные быстродействующие устройства SSD либо SAS при создании пула хранения. Соответственно, в кэш L2 можно выдергивать либо метаданные, либо все, обеспечивая желаемое распределение операций ввода-вывода по устройствам.

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

Что вовсе не означает - заметьте! - что ZFS архитектурно не совместима с базами данных. А всего лишь говорит о том, что данная файловая система способна работать с почти любыми классами приложений, под которые ее всего лишь необходимо настроить.

Остается лишь заметить, что параметры ZFS "из коробки" являются усредненными, но отнюдь не идеальными для всех без исключения приложений. Что, в общем-то, самоочевидно всем, кроме дилетантов, желающих все и сразу и непременно "волшебную пулю".

К чести ZFS надо заметить, что она прекрасно настраивается, позволяя получить почти любой желаемый результат и единственный, на мой взгляд, недостаток ее реализации в Solaris - это невозможность (в текущей версии) выбрать размер recordsize для корневого пула при установке системы.

PS. Оставим пока за кадром, как умудряются некоторые рукосуидеятели испохабить ZFS до такой степени, чтобы потом склонять ее за плохую производительность под БД. И эта глупая байка так и гуляет по форумам и пустым головам анонимных "аналитиков". У меня всегда появляется в этом случае вопрос - что я делаю не так? Я постараюсь ответить на этот вопрос в следующих статьях.