Я установил машину Solaris Express 11 с некоторыми достаточно быстрыми жесткими дисками за RAID-контроллером, настроил устройство как zpool с включенным сжатием и добавил к нему зеркальный журнал и 2 кэширующих устройства. Наборы данных представлены как целевые объекты FC для использования с ESX, и я заполнил их некоторыми данными, с которыми можно поиграть. L2ARC частично заполнен (и почему-то больше не заполняется), но толку от него не вижу. zpool iostat -v показывает, что в прошлом из кеша читалось не так много:
tank 222G 1.96T 189 84 994K 1.95M
c7t0d0s0 222G 1.96T 189 82 994K 1.91M
mirror 49.5M 5.51G 0 2 0 33.2K
c8t2d0p1 - - 0 2 0 33.3K
c8t3d0p1 - - 0 2 0 33.3K
cache - - - - - -
c11d0p2 23.5G 60.4G 2 1 33.7K 113K
c10d0p2 23.4G 60.4G 2 1 34.2K 113K
и Поддержка L2ARC arcstat.pl скрипт показывает 100% пропусков L2ARC для текущей нагрузки:
./arcstat.pl -f read,hits,miss,hit%,l2read,l2hits,l2miss,l2hit%,arcsz,l2size 5
read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size
[...]
243 107 136 44 136 0 136 0 886M 39G
282 144 137 51 137 0 137 0 886M 39G
454 239 214 52 214 0 214 0 889M 39G
[...]
Сначала я подозревал, что это может быть влияние запись слишком велика так что L2ARC распознает все как потоковую нагрузку, но zpool не содержит ничего, кроме томов zfs (я создал их как "разреженные", используя zfs create -V 500G -s <datasetname>), у которых даже нет параметра набора записей, который нужно изменить.
Я также нашел много понятий о том, что L2ARC требует 200 байтов ОЗУ на запись для своих метаданных, но до сих пор не мог выяснить, что L2ARC будет рассматривать как «запись» с набором данных тома - один сектор размером 512 байтов? Может быть, он страдает от нехватки оперативной памяти для метаданных и до сих пор заполнен мусором, который больше никогда не читается?
Редактировать: Добавление 8 ГБ оперативной памяти к уже установленным 2 ГБ сработало отлично - дополнительная оперативная память успешно используется даже в 32-разрядной установке, а L2ARC теперь вырос и получает успех:
time read hit% l2hit% arcsz l2size
21:43:38 340 97 13 6.4G 95G
21:43:48 185 97 18 6.4G 95G
21:43:58 655 91 2 6.4G 95G
21:44:08 432 98 16 6.4G 95G
21:44:18 778 92 9 6.4G 95G
21:44:28 910 99 19 6.4G 95G
21:44:38 4.6K 99 18 6.4G 95G
Благодаря ewwhite.
У вас должно быть больше оперативной памяти в системе. Указатели на L2ARC необходимо хранить в ОЗУ (ARC), поэтому я думаю, вам понадобится около 4 или 6 ГБ ОЗУ, чтобы лучше использовать ~ 60 ГБ L2ARC, которые у вас есть.
Это из недавнего треда в списке ZFS:
http://opensolaris.org/jive/thread.jspa?threadID=131296
L2ARC is "secondary" ARC. ZFS attempts to cache all reads in the ARC
(Adaptive Read Cache) - should it find that it doesn't have enough space
in the ARC (which is RAM-resident), it will evict some data over to the
L2ARC (which in turn will simply dump the least-recently-used data when
it runs out of space). Remember, however, every time something gets
written to the L2ARC, a little bit of space is taken up in the ARC
itself (a pointer to the L2ARC entry needs to be kept in ARC). So, it's
not possible to have a giant L2ARC and tiny ARC. As a rule of thumb, I
try not to have my L2ARC exceed my main RAM by more than 10-15x (with
really bigMem machines, I'm a bit looser and allow 20-25x or so, but
still...). So, if you are thinking of getting a 160GB SSD, it would be
wise to go for at minimum 8GB of RAM. Once again, the amount of ARC
space reserved for a L2ARC entry is fixed, and independent of the actual
block size stored in L2ARC. The jist of this is that tiny files eat up
a disproportionate amount of systems resources for their size (smaller
size = larger % overhead vis-a-vis large files).