Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Некоторые данные о производительности EMC FASTcache и FAST VP | about NetApp

Некоторые данные о производительности EMC FASTcache и FAST VP

Несмотря на то, что EMC наотрез отказывается публиковать результаты производительности систем с FASTcache и FAST VP, храня по этому поводу многозначительное и загадочное молчание, невозможно запретить частным лицам анализировать и делиться своими результатами приобретенных ими систем.

Недавно в интернете удалось раскопать вот такие результаты.

image

Некто проследил и опубликовал результаты real world-работы системы NS480 (CX4-480), объемом 480 SAS, SATA и EFD дисков, на 28TB block и 100TB NAS data, оснащенной как FAST VP, так и FASTcache (4 диска EFD по 100GB, общей usable capacity в FASTcache – 183GB).

Пожалуйста, примите во внимание, что это Real World data, то есть реальная производительность системы, используемой под реальную пользовательскую работу (в рассмотренном случае – ERP, VMware, SQL server databases, CIFS shares), а не какие-то специальные тестовые условия. В этом и сила и слабость приведенных результатов. Сила в том, что это реальные, практические данные. Слабость – в том, что, вполне вероятно, мы не видим всех возможностей FAST/FASTcache.

image

Тем не менее “чем богаты – тем и рады”. Пока EMC хранит загадочное молчание, приходится перебиваться тем, что подарят сердобольные пользователи. Подробно о системе и полученных результатах – по ссылке выше.

Напомню, что, в отличие от EMC, NetApp результаты своих систем с Flash Cache не только не таит, а наоборот, активно пропагандирует и публикует, потому что, по справедливости, там есть чем гордиться.

UPD: В комментариях к посту также нашлось упоминание еще одних результатов.

http://sudrsn.wordpress.com/2011/03/19/storage-efficiency-with-awesome-fast-cache/
http://sudrsn.wordpress.com/2011/04/16/emc-fast-cache-increase-performance-while-reducing-disk-drive-count/

Правда там человек темнит о конфигурации.

7 комментариев

  1. Dmitriy:

    А можно ли как-то получить схожий разрез производительности в IOPS для NetApp? увидеть сколько идет с FlashCache, а сколько с SAS дисков? Operation Manager показывает только суммарный график по IOPS’ам.
    p.s. ? для 480 шпинделей (правда нету соотношения сколько из них SAS, сколько SATA) наверно это не самые большие попугаи :) зато реальные цифры.

  2. Алексей:

    Стоит отметить, что не просто кто-то, а работник EMC: http://storagesavvy.com/about/ :)

    Я думаю, что ценность графика, приведенного в статье, станет больше, если вписать комментарий из оригинала:
    I didn’t graph it here but the total array IO Response time through this window is averaging 2.5 m

  3. Dmitriy:

    Можно было бы попробовать сперва сделать замеры в варианте с кэшем, а потом отключить его (>options flexscale.enable off , если не ошибаюсь) и посмотреть разницу.

  4. firehunter:

    Dmitriy:

    Если у Вас в системе стоит FlashCache - то мой взгляд проще всего промониторить командой “stats show -p flexscale-access -i 1″ *) под реальной нагрузкой. Там есть статистика по “Hit Rate”, т.е. по эффективности кеша. Если грубо, то если система в среднем делает за период измерения 10,000 iops всего, при этом эффективность кеша 80% значит 8,000 iops до дисков не дошли, а обслужились из кеша.
    Наверное это не самый лучших способ и наверняка у производителя есть скрипты на эту тему :)

    *) цифру один в команде меняем на время, за которое хотим посмотреть агрегированную статистику.

  5. firehunter:

    Dmitriy:
    Можно еще вот так попробовать посмотреть статистику: “stats start ext_cache_obj:*:disk_reads_replaced ext_cache_obj:*:hit_percent system:*:read_ops”. Статистика начнет собираться. Посмотреть результаты - “stats stop”.
    Есть подозрение, что статистика не очень точная, возможно потому что значительная часть запросов обслуживается из первичного кеша, а может и по другой причине.
    Для более точной статистики наверное лучше собрать вместо system:*:read_ops счетчики disk:*:user_reads, но данные придется обрабатывать внешним скриптом, т.к. статистика будет по каждому диску отображаться отдельно и ее надо суммировать.

  6. nonkonf:

    На самом деле эти результаты очень показательны для тех, кто в данной сфере разбирается.
    Самое важное - это механизм работы FASTcache, его нельзя включать для всех возможных видов данных и операций, иначе результыты будут сильно отличаться от ожидаемых. Кроме того, размер кэша должен быть рассчитан исходя из размера горячих данных, и я никогда не поверю, что для 28Tb данных горячими являются 183Гб :) По своему опыту работы могу назвать число 10%, то есть 3Тб данных, которые постоянно читаются и обрабатываются. Теоретически это может означать, что шанс попадания в FASTCache в данном случае равен 6% (Hit Ratio). Поэтому неудивительно, что на картинке только 2500 операций вращаются в кэше (хотя на самом деле удивительно, потому что должно быть меньше!)

  7. firehunter:

    Спасибо за полный и подробный ответ, кстати (а то тут в основном все я, да я отвечаю;)

Оставить комментарий

20/0.084

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.