ZFS с L2ARC (SSD) медленнее для случайных поисков, чем без L2ARC
В настоящее время я тестирую ZFS (Opensolaris 2009.06) в старом файловом сервере, чтобы оценить его использование для наших нужд. Наша текущая настройка выглядит следующим образом:
- Двухъядерный (2,4 ГГц) с 4 ГБ оперативной памяти
- 3 контроллера SATA с 11 жесткими дисками (250 ГБ) и одним SSD (OCZ Vertex 2 100 ГБ)
Мы хотим оценить использование 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 (конечно). Мы запускаем IO-тесты с bonnie++ 1.03d, размер установлен на 200 ГБ (-s 200 г), чтобы тестовый образец никогда не был полностью в 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, и произвольный поиск по этим данным работает лучше, тогда как случайный поиск по другим данным работает точно так же, как и раньше.
2 ответа
Не уверен, почему вы видите поведение, которое вы видите, но я могу сказать вам, почему они не обязательно сигнализируют ужасную реальную производительность ZFS. Бонни предназначена для измерения производительности реальных дисков и намеренно пытается не использовать дисковый / кэш-память. Вы пытаетесь использовать его для измерения дискового кэша.
Устройство L2ARC может нагреться часами. В зависимости от того, сколько основной памяти у вас есть для ARC и производительности диска с вашей рабочей нагрузкой, накопителю на 100 ГБ для L2ARC потребуется 1-2 часа, чтобы нагреться и, возможно, даже дольше ( Source). Во-вторых, L2Arc предназначен для кэширования случайных операций чтения, а не потоковых операций чтения. "Если вы используете L2ARC для потоковой или последовательной рабочей нагрузки, то L2ARC будет в основном игнорировать его, а не кэшировать его" ( Источник). Я был бы очень удивлен, если бы большая часть вашей работы с Бонни когда-нибудь попала в L2ARC. Вместо того, чтобы использовать bonnie++, попробуйте генерировать нагрузку, которая напоминает ваше реальное использование системы.
Хотя маловероятно, что запуск последних версий Bonnie++ для разработчиков (1.96 против 1.03d) может привести к чему-то ближе к вашим ожидаемым результатам. Возможно, вы также захотите ознакомиться с этой публикацией в блогах Sun о Bonnie++ с Sun 7000 Series, хотя они работают через NFS, а не локально.
Вы также можете включить потоковый кеш данных в L2ARC на вашем SSD.
Для этого полезен параметр l2arc_noprefetch.
Этот параметр определяет, кэшируются ли потоковые данные или нет. По умолчанию кэширование потоковых данных не выполняется (по умолчанию установлено значение true). Если вы установите значение false, вы, вероятно, значительно увеличите коэффициент попадания в кэш L2ARC.