ZFS Blocksize (размер записи) и проблема с основным кешем

На этом веб-сайте: http://www.patpro.net/blog/index.php/2014/03/19/2628-zfs-primarycache-all-versus-metadata/

Этот человек показывает, что, переключая primarycache на все или метаданные, он получает совершенно другую скорость чтения при использовании антивируса.

Однако он также показывает, что пропускная способность чтения тоже очень сильно отличается.

Я создаю 2 новых набора данных, оба с primarycache = none и compress = lz4, и копирую в каждый файл размером 4,8 ГБ (коэффициент сжатия 2,05x). Затем я устанавливаю primarycache = all для первого и primarycache = metadata для второго. Я помещаю первый файл в / dev / null с помощью zpool iostat, запущенного в другом терминале. И, наконец, таким же образом я пропускаю второй файл.

Столбец «Сумма пропускной способности чтения» (почти) в точности равен физическому размеру файла на диске (вывод du) для набора данных с primarycache = all: 2,44 ГБ. Для другого набора данных с primarycache = metadata сумма столбца пропускной способности чтения составляет ... подождите ... 77,95 ГБ.

Затем он говорит, что анонимный пользователь объяснил это так:

clamscan читает файл, получает 4 КБ (размер страницы?) данных и обрабатывает их, затем считывает следующие 4 КБ и т. д.

Однако ZFS не может читать только 4 КБ. По умолчанию он читает 128 КБ (размер записи). Поскольку кеша нет (вы его отключили), остальные данные выбрасываются.

128k / 4k = 32

32 x 2.44GB = 78.08GB

Я не совсем понимаю объяснение анонимного пользователя. Я все еще не понимаю, почему такая большая разница в пропускной способности чтения.

Так почему же этот эксперимент ZFS показывает, что когда primarycache - это все, пропускная способность чтения составляет 2,44 ГБ, а когда это просто метаданные, это 77,95 ГБ? И каковы последствия настройки ZFS? Если бы человек, возможно, уменьшил размер своей записи, получился бы другой результат?

Как насчет утверждения, что размер записи ZFS переменный?


person CMCDragonkai    schedule 27.06.2014    source источник


Ответы (1)


Тест, который провел блоггер, Патрик, заключался в том, чтобы «переместить» файл размером 4,8 ГБ (сжатый до 2,44 ГБ) в / dev / null и посмотреть, сколько времени требуется для чтения файла.

Ключ в том, что «primarycache = metadata» может означать «cache = off», потому что ни один из фактических файлов не будет храниться в кеше. Когда «primarycache = all», система считывает весь файл один раз и сохраняет его в кэше (обычно в ОЗУ, а затем в кеш-памяти SSD второго уровня, когда он заполняется). Когда «cat» или «clamscan» ищут файл, они могут найти его там, и его не нужно повторно читать с диска.

Поскольку cat записывает файл в / dev / null, он не просто записывает его в одном блоке размером 2,44 ГБ, он записывает его понемногу, затем проверяет кеш на предмет следующего бита, а затем записывает немного больше и т. д.

С отключенным кешем этот файл нужно будет перечитывать с диска невероятное количество раз, поскольку он записывается в / dev / null (или stdout, где угодно) - это логика «128k / 4k = 32».

ZFS записывает файлы на диск блоками по 128 КБ, но участники форума обнаружили, что clamscan (и «cat», по крайней мере, на FreeBSD этого пользователя) обрабатывает данные блоками по 4 КБ. Таким образом, без кеша каждый блок размером 128 КБ придется обслуживать 32 раза, а не один раз. (clamscan извлекает блок № 1, размером 128 КБ, использует первые 4 КБ; снова нужен блок № 1, так как нет кеша, он снова считывает блок с диска; берет вторые 4 КБ, выбрасывает остальные и т. д.)

Результат:

[1] Может быть, никогда не делать "primarycache = metadata" ни по какой причине.

[2] Несоответствие размера блока может привести к проблемам с производительностью. Если clamscan читает блоки размером 128k, не будет (значительной?) Разницы при чтении одного файла. OTOH, если вам снова понадобится файл вскоре после этого, в кеше все еще будут свои блоки данных, и его не нужно будет снова извлекать с диска.

...

Вот несколько тестов, вдохновленных сообщением на форуме, для иллюстрации. Примеры относятся к набору данных zfs, размер записи установлен на 128 КБ (по умолчанию), для первичного кэша заданы метаданные, а фиктивный файл размером 1 ГБ копируется с разными размерами блоков, сначала 128 КБ, затем 4, затем 8. (Прокрутите вправо, Я выстроил свои команды копирования с показаниями iostat).

Обратите внимание на то, насколько резко, когда размеры блоков не совпадают, увеличивается соотношение чтения и записи, а также пропускная способность чтения.

    root@zone1:~# zpool iostat 3
                   capacity     operations    bandwidth
    pool        alloc   free   read  write   read  write
    ----------  -----  -----  -----  -----  -----  -----
    rpool        291G   265G      0     21  20.4K   130K
    rpool        291G   265G      0      0      0      0
    rpool        291G   265G      0    515      0  38.9M            ajordan@zone1:~/mnt/test$ mkfile 1G test1.tst   
    rpool        291G   265G      0  1.05K      0   121M
    rpool        292G   264G      0    974      0   100M
    rpool        292G   264G      0    217      0  26.7M
    rpool        292G   264G      0    516      0  58.0M
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0     96      0   619K
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G    474      0  59.3M      0            ajordan@zone1:~/mnt/test$ dd if=test1.tst of=test1.2 bs=128k
    rpool        292G   264G    254    593  31.8M  67.8M                
    rpool        292G   264G    396    230  49.6M  27.9M                
    rpool        293G   263G    306    453  38.3M  45.2M                8192+0 records in
    rpool        293G   263G    214    546  26.9M  62.0M                8192+0 records out
    rpool        293G   263G    486      0  60.8M      0
    rpool        293G   263G    211    635  26.5M  72.9M
    rpool        293G   263G    384    235  48.1M  29.2M
    rpool        293G   263G      0    346      0  37.2M
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G  1.05K     70   134M  3.52M            ajordan@zone1:~/mnt/test$ dd if=test1.tst of=test1.3 bs=4k
    rpool        293G   263G  1.45K      0   185M      0                
    rpool        293G   263G  1.35K    160   173M  10.0M
    rpool        293G   263G  1.44K      0   185M      0
    rpool        293G   263G  1.31K    180   168M  9.83M
    rpool        293G   263G  1.36K    117   174M  9.20M
    rpool        293G   263G  1.42K      0   181M      0
    rpool        293G   263G  1.26K    120   161M  9.48M
    rpool        293G   263G  1.49K      0   191M      0
    rpool        293G   263G  1.40K    117   179M  9.23M
    rpool        293G   263G  1.36K    159   175M  9.98M
    rpool        293G   263G  1.41K     12   180M   158K
    rpool        293G   263G  1.23K    167   157M  9.63M
    rpool        293G   263G  1.54K      0   197M      0
    rpool        293G   263G  1.36K    158   175M  9.70M
    rpool        293G   263G  1.42K    151   181M  9.99M
    rpool        293G   263G  1.41K     21   180M   268K
    rpool        293G   263G  1.32K    132   169M  9.39M
    rpool        293G   263G  1.48K      0   189M      0
    rpool        294G   262G  1.42K    118   181M  9.32M
    rpool        294G   262G  1.34K    121   172M  9.73M
    rpool        294G   262G    859      2   107M  10.7K
    rpool        294G   262G  1.34K    135   171M  6.83M
    rpool        294G   262G  1.43K      0   183M      0
    rpool        294G   262G  1.31K    120   168M  9.44M
    rpool        294G   262G  1.26K    116   161M  9.11M
    rpool        294G   262G  1.52K      0   194M      0
    rpool        294G   262G  1.32K    118   170M  9.44M
    rpool        294G   262G  1.48K      0   189M      0
    rpool        294G   262G  1.23K    170   157M  9.97M
    rpool        294G   262G  1.41K    116   181M  9.07M
    rpool        294G   262G  1.49K      0   191M      0
    rpool        294G   262G  1.38K    123   176M  9.90M
    rpool        294G   262G  1.35K      0   173M      0
    rpool        294G   262G  1.41K    114   181M  8.86M
    rpool        294G   262G  1.29K    155   165M  10.3M
    rpool        294G   262G  1.50K      7   192M  89.3K
    rpool        294G   262G  1.43K    116   183M  9.03M
    rpool        294G   262G  1.52K      0   194M      0
    rpool        294G   262G  1.39K    125   178M  10.0M
    rpool        294G   262G  1.28K    119   164M  9.52M
    rpool        294G   262G  1.54K      0   197M      0
    rpool        294G   262G  1.39K    120   178M  9.57M
    rpool        294G   262G  1.45K      0   186M      0
    rpool        294G   262G  1.37K    133   175M  9.60M                
    rpool        294G   262G  1.38K    173   176M  10.1M                
    rpool        294G   262G  1.61K      0   207M      0
    rpool        294G   262G  1.47K    125   189M  10.2M
    rpool        294G   262G  1.56K      0   200M      0
    rpool        294G   262G  1.38K    124   177M  10.2M
    rpool        294G   262G  1.37K    145   175M  9.95M
    rpool        294G   262G  1.51K     28   193M   359K
    rpool        294G   262G  1.32K    171   169M  10.1M
    rpool        294G   262G  1.55K      0   199M      0
    rpool        294G   262G  1.29K    119   165M  9.48M
    rpool        294G   262G  1.11K    110   142M  8.36M
    rpool        294G   262G  1.43K      0   183M      0
    rpool        294G   262G  1.36K    118   174M  9.32M
    rpool        294G   262G  1.49K      0   190M      0
    rpool        294G   262G  1.35K    118   173M  9.32M
    rpool        294G   262G  1.32K    146   169M  10.1M
    rpool        294G   262G  1.07K     29   137M   363K                262144+0 records in
    rpool        294G   262G      0     79      0  4.65M                262144+0 records out
    rpool        294G   262G      0      0      0      0
    rpool        294G   262G      0      0      0      0
    rpool        294G   262G      0      0      0      0
    rpool        294G   262G      0      0      0      0
    rpool        294G   262G      0      0      0      0
    rpool        294G   262G      0      0      0      0



    root@zone1:~# zpool iostat 3
                   capacity     operations    bandwidth
    pool        alloc   free   read  write   read  write
    ----------  -----  -----  -----  -----  -----  -----
    rpool        292G   264G      0     21  22.6K   130K
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G      0      0      0      0
    rpool        292G   264G  1.03K      0   131M      0            ajordan@zone1:~/mnt/test$ dd if=test8k.tst of=test8k.2 bs=8k
    rpool        292G   264G  1.10K    202   141M  16.4M
    rpool        292G   264G  1.25K     25   161M   316K
    rpool        292G   264G    960    215   120M  15.5M
    rpool        292G   264G  1.25K      0   160M      0
    rpool        292G   264G     1K    210   128M  14.8M
    rpool        292G   264G   1010    159   126M  14.3M
    rpool        292G   264G  1.28K      0   164M      0
    rpool        292G   264G  1.08K    169   138M  15.6M
    rpool        292G   264G  1.25K      0   161M      0
    rpool        292G   264G  1.00K    166   128M  15.3M
    rpool        293G   263G    998    201   125M  15.1M
    rpool        293G   263G  1.19K      0   153M      0
    rpool        293G   263G    655    161  82.0M  14.2M
    rpool        293G   263G  1.27K      0   162M      0
    rpool        293G   263G  1.02K    230   130M  12.7M
    rpool        293G   263G  1.02K    204   130M  15.5M
    rpool        293G   263G  1.23K      0   157M      0
    rpool        293G   263G  1.11K    162   142M  14.8M
    rpool        293G   263G  1.26K      0   161M      0
    rpool        293G   263G  1.01K    168   130M  15.5M
    rpool        293G   263G  1.04K    215   133M  15.5M
    rpool        293G   263G  1.30K      0   167M      0
    rpool        293G   263G  1.01K    210   129M  16.1M
    rpool        293G   263G  1.24K      0   159M      0
    rpool        293G   263G  1.10K    214   141M  15.3M
    rpool        293G   263G  1.07K    169   137M  15.6M
    rpool        293G   263G  1.25K      0   160M      0
    rpool        293G   263G  1.01K    166   130M  15.0M
    rpool        293G   263G  1.25K      0   160M      0
    rpool        293G   263G    974    230   122M  15.8M
    rpool        293G   263G  1.11K    160   142M  14.4M
    rpool        293G   263G  1.26K      0   161M      0
    rpool        293G   263G  1.06K    172   136M  15.8M
    rpool        293G   263G  1.27K      0   162M      0
    rpool        293G   263G  1.07K    167   136M  15.4M
    rpool        293G   263G   1011    217   126M  15.8M
    rpool        293G   263G  1.22K      0   156M      0
    rpool        293G   263G    569    160  71.2M  14.6M                131072+0 records in
    rpool        293G   263G      0      0      0      0                131072+0 records out
    rpool        293G   263G      0     98      0  1.09M
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G      0      0      0      0
    rpool        293G   263G      0      0      0      0
person adamtamu    schedule 01.10.2014
comment
Отличный ответ, спасибо. Думаю, размеры блоков всегда должны совпадать. Но каков должен быть размер блока для переменных рабочих нагрузок? Что лучше: переоценить средний размер блока рабочей нагрузки или недооценить средний размер блока? - person CMCDragonkai; 02.10.2014
comment
Хм, я вижу, вы тоже об этом спрашивали выше - а как насчет утверждения, что размер записи ZFS является переменным? - размер записи - свойство переменной, в котором файловая система будет сохранять блоки с этим размером (скажем, по умолчанию, 128 КБ) ИЛИ МЕНЬШЕ. Если размер файла превышает 128 КБ, он будет разбит на блоки по 128 КБ. Попробуйте сопоставить размер записи с размером блока вашего хранилища или быть кратным ему (не меньше) - это большая тема, вот достойная ссылка: ссылка - person adamtamu; 02.10.2014