Назад | Перейти на главную страницу

ZFS с L2ARC (SSD) медленнее для случайных поисков, чем без L2ARC

В настоящее время я тестирую ZFS (Opensolaris 2009.06) на более старом файловом сервере, чтобы оценить его использование для наших нужд. Наша текущая настройка выглядит следующим образом:

Двухъядерный (2,4 ГГц) с 4 ГБ ОЗУ
3x SATA-контроллера с 11 жесткими дисками (250 ГБ) и одним SSD (OCZ Vertex 2100 ГБ)

Мы хотим оценить использование L2ARC, поэтому текущий ZPOOL:

$ zpool status
  pool: tank
 state: ONLINE
 scrub: none requested
config:

        NAME         STATE     READ WRITE CKSUM
        afstank      ONLINE       0     0     0
          raidz1     ONLINE       0     0     0
            c11t0d0  ONLINE       0     0     0
            c11t1d0  ONLINE       0     0     0
            c11t2d0  ONLINE       0     0     0
            c11t3d0  ONLINE       0     0     0
          raidz1     ONLINE       0     0     0
            c13t0d0  ONLINE       0     0     0
            c13t1d0  ONLINE       0     0     0
            c13t2d0  ONLINE       0     0     0
            c13t3d0  ONLINE       0     0     0
        cache
          c14t3d0    ONLINE       0     0     0

где c14t3d0 - это SSD (конечно). Мы запускаем тесты ввода-вывода с помощью bonnie ++ 1.03d, размер установлен на 200 ГБ (-s 200g), так что тестовый образец никогда не будет полностью в ARC / L2ARC. Результаты без SSD: (средние значения за несколько прогонов, которые не показывают различий)

write_chr       write_blk       rewrite         read_chr        read_blk        random seeks
101.998 kB/s    214.258 kB/s    96.673 kB/s     77.702 kB/s     254.695 kB/s    900 /s

С SSD становится интересно. Я предполагал, что в худшем случае результаты должны быть как минимум такими же. Хотя скорости записи / чтения / перезаписи не отличаются, скорость случайного поиска значительно различается между отдельными запусками bonnie ++ (пока что между 188 и 1333 / с), в среднем 548 + - 200 / с, поэтому ниже значения без SSD.

Итак, мои вопросы в основном следующие:

Почему частота случайного поиска так сильно различается? Если поиски действительно случайны, они не должны сильно отличаться (мое предположение). Таким образом, даже если SSD снижает производительность, он должен быть одинаковым при каждом запуске bonnie ++.
Почему производительность случайного поиска хуже в большинстве прогонов bonnie ++? Я бы предположил, что некоторая часть данных bonnie ++ находится в L2ARC, и случайный поиск по этим данным работает лучше, тогда как случайный поиск по другим данным работает так же, как и раньше.

Не уверен, почему вы наблюдаете такое поведение, но могу сказать, почему они не обязательно сигнализируют об ужасной реальной производительности ZFS. Bonnie предназначен для измерения производительности реальных дисков и намеренно пытается не использовать кеш диска / памяти. Вы пытаетесь использовать его для измерения дискового кеша.

Устройство L2ARC нагревается в течение нескольких часов. В зависимости от того, сколько у вас основной памяти для ARC и производительности диска с вашей рабочей нагрузкой, SSD на 100 ГБ для L2ARC нагреется за 1-2 часа, а возможно, даже дольше (Источник). Во-вторых, L2Arc предназначен для кэширования произвольных операций чтения, а не для потокового чтения. «Если вы используете L2ARC для потоковой или последовательной рабочей нагрузки, тогда L2ARC будет в основном игнорировать его и не кэшировать» (Источник). Я был бы действительно удивлен, если большая часть вашей работы Bonnie когда-либо попадет в L2ARC. Вместо того, чтобы использовать bonnie ++, попробуйте создать нагрузку, которая напоминает ваше реальное использование системы.

Хотя маловероятно, последние версии разработки Bonnie ++ (1,96 против 1,03d) может привести к результатам, близким к ожидаемым. Вы также можете прочитать этот пост в солнечных блогах о bonnie ++ с Sun 7000 Series, хотя они работают через NFS, а не локально.

Вы также можете включить кэш потоковых данных в L2ARC на вашем SSD.

Для этого пригодится параметр l2arc_noprefetch.

Этот параметр определяет, кэшируются ли потоковые данные. По умолчанию потоковые данные не кэшируются (значение по умолчанию - true). Если вы установите для него значение false, вы, вероятно, увидите, что коэффициент попадания в кеш L2ARC значительно увеличится.