Подготовка кэша ZFS L2ARC в Solaris 11.3

Немного поэкспериментировав, я нашел четыре возможных решения.

При каждом подходе вам нужно выполнить шаги, а затем продолжить чтение дополнительных данных для заполнения кеша ZFS ARC и для запуска подачи от ARC к L2ARC. Обратите внимание: если данные уже кэшированы в памяти, или если сжатый размер на диске каждого блока превышает 32 КБ, эти методы обычно ничего не делают.

1. Установите задокументированный флаг ядра zfs_prefetch_disable

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

echo "zfs_prefetch_disable/W0t1" | mdb -kw

.. или чтобы установить его постоянно, добавьте следующее в / etc / system :

set zfs:zfs_prefetch_disable = 1

Теперь, когда файлы читаются с использованием dd , они по-прежнему будут иметь право на L2ARC.

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

2. Перезапись данных

По мере того, как данные записываются в файловую систему ZFS, они кэшируются в ARC и (если они соответствуют критериям размера блока) могут быть отправлены в L2ARC. Не всегда легко перезаписать данные, но некоторые приложения и базы данных могут делать это вживую, например путем зеркалирования файлов на уровне приложения или перемещения файлов данных.

Проблемы:

• Не всегда возможно в зависимости от приложения.
• Занимает дополнительное место, если используются снимки.
• (Но на ярком стороны, полученные файлы дефрагментируются.)

3. Отключите недокументированный флаг ядра l2arc_noprefetch

Это основано на чтении исходного кода OpenSolaris и, без сомнения, полностью не поддерживается. Используйте на свой страх и риск.

1. Отключите флаг l2arc_noprefetch :

    echo "l2arc_noprefetch / W0" |  mdb -kw
    

   Данные, считываемые в ARC, пока этот флаг отключен, будут иметь право на L2ARC, даже если это последовательное чтение (пока блоки на диске не превышают 32 КБ).

2. Прочитать файл с диска:

     dd if = filename.bin of = / dev / null bs = 1024k
    

3. Повторно включить флаг l2arc_noprefetch :

    echo "l2arc_noprefetch / W1" |  mdb -kw
    

4. Чтение данных в случайном порядке

Я написал сценарий Perl для псевдослучайного чтения файлов кусками по 8 КБ (на основе порядка хэша Perl). Он также может работать с большими фрагментами, но я это еще не тестировал.

#!/usr/bin/perl -W

my $BLOCK_SIZE = 8*2**10;
my $MAX_ERRS = 5;

foreach my $file (@ARGV) {
        print "Reading $file...\n";
        my $size;
        unless($size = (stat($file))[7]) {print STDERR "Unable to stat file $file.\n"; next; }
        unless(open(FILE, "<$file")) {print STDERR "Unable to open file $file.\n"; next; }
        my $buf;
        my %blocks;
        for(my $i=0;$i<$size/$BLOCK_SIZE;$i++) { $blocks{"$i"} = 0; }
        my $errs = 0;
        foreach my $block (keys %blocks) {
                unless(sysseek(FILE, $block*$BLOCK_SIZE, 0) && sysread(FILE, $buf, $BLOCK_SIZE)) {
                        print STDERR "Error reading $BLOCK_SIZE bytes from offset " . $block * $BLOCK_SIZE . "\n";
                        if(++$errs == $MAX_ERRS) { print STDERR "Giving up on this file.\n"; last; }
                        next;
                }
        }
        close(FILE);
}

Проблемы:

• Это занимает много времени и создает большую нагрузку на диск.

Остающиеся проблемы

• Вышеупомянутые методы будут получить данные в основную память, подходящую для подачи в L2ARC, но они не запускают передачу. Единственный известный мне способ запустить запись в L2ARC - это продолжить чтение данных, чтобы оказать давление на ARC.
• В Solaris 11.3 с SRU 1.3.9.4.0 только в редких случаях L2ARC вырастает до ожидаемой полной величины. evict_l2_elhibited kstat увеличивается, даже когда устройства SSD не находятся под нагрузкой, указывая на то, что данные отбрасываются. Этот оставшийся кусок некэшированных данных оказывает непропорциональное влияние на производительность.

Я бы посоветовал использовать реальную рабочую нагрузку и отслеживать результат с помощью arcstat .

Что-то вроде:

arcstat.py -f "time,read,l2read,hit%,hits,miss%,miss,l2hit%,l2miss%,arcsz,c,l2size" 1

Я не думаю, что в этом есть необходимость " заполнить "кэш". Если имеющаяся у вас рабочая нагрузка не заполняет кеш естественным образом, то это не репрезентативная рабочая нагрузка для тестирования, верно?

Может быть, у вас есть исключительный вариант использования (какой у вас размер набора данных, размер ARC и размер рабочего набора?) , но в целом фокус на L2ARC переоценивается.