Тома Solaris ZFS: рабочая нагрузка не превышает L2ARC
Я установил компьютер 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
и сценарий arcstat.pl с поддержкой L2ARC показывает 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.
1 ответ
Вы должны иметь больше оперативной памяти в системе. Указатели на 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).