Это вторая часть из двух частей, в которой сравнивается vCache Virident с FlashCache. Первая часть была сфокусирована на удобстве использования и сравнении функций; в этом посте мы рассмотрим некоторые результаты теста sysbench.
Раскрытие информации: исследования и тестирование, проведенные для этого поста, были спонсированы Virident.
Сначала немного справочной информации. Все тесты проводились на Cisco UCS C250 компании Percona.на тестовом компьютере, а также в тестах vCache и FlashCache использовалось то же устройство Virident FlashMAX II емкостью 2,2 ТБ, что и для устройства кэш-памяти. EXT4 — это файловая система, а CentOS 6.4 — операционная система, хотя модули предварительного выпуска, которые я получил от Virident, требовали использования ядра CentOS 6.2, 2.6.32-220, так что это ядро использовалось для всех тестов производительности. обе системы. Для тестирования использовался sysbench 0.5, а версия MySQL — Percona Server 5.5.30-rel30.1-465. Каждому тесту позволяли работать в течение 7200 секунд, а первые 3600 секунд отбрасывались как время прогрева; оставшиеся 3600 секунд были усреднены по 10-секундным интервалам. Все тесты были проведены приблизительно с 78 ГБ данных (32 таблицы по 10 М строк в каждой) и буферным пулом 4 ГБ.Кэш-устройства были сброшены на диск непосредственно перед каждым тестовым прогоном и сразу после него.
С этим из пути, давайте посмотрим на некоторые цифры.
vCache vCache — тестирование параметров MySQL
Первый тест был разработан, чтобы смотреть исключительно на производительность vCache при некоторых различных наборах параметров конфигурации MySQL. Например, учитывая, что интерфейсное устройство представляет собой очень быстрый PCIe SSD, имеет ли смысл настраивать MySQL так, как если бы оно использовало хранилище SSD, или просто использовать оптимизированную конфигурацию хранилища HDD? После создания устройства vCache с конфигурацией по умолчанию я начал с базовой конфигурации жесткого диска для MySQL (конфигурация A, приведенной в нижней части этого поста), а затем попытался провести три дополнительных эксперимента. Во-первых, базовая конфигурация плюс: мы называем эту конфигурацию B. Следующая содержала четыре специфичные для SSD оптимизации, основанные частично на некоторой предыдущей работе, которую я проделал с этой картой Virident (конфигурация C):
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_io_capacity = 30000
innodb_adaptive_flushing_method = keep_average
innodb_flush_neighbor_pages=none
innodb_max_dirty_pages_pct = 60
И, наконец, четвертый тест (конфигурация D), который объединил изменения параметров из тестов B и C. На приведенном ниже графике показана пропускная способность sysbench (tps) для этих четырех конфигураций: Как мы видим, все опции конфигурации выдают числа, которые в отсутствие выбросов примерно одинаковы, но это конфигурация C (показана на графике синей линией — конфигурация SSD), которая показывает наиболее стабильную производительность. Все остальные имеют различные падения производительности, разбросанные по всему графику. Мы видим точно такую же картину, глядя на задержку транзакции; базовые числа примерно одинаковы для всех четырех конфигураций, но конфигурация C позволяет избежать скачков и дает очень постоянный и предсказуемый результат.
vCache против FlashCache — основы
После того, как я определил, что конфигурация C, по-видимому, дает наиболее оптимальные результаты, я перешел к оценке производительности FlashCache по сравнению с vCache, и я также включил тестовый запуск без кэша, используя базовую конфигурацию жесткого диска MySQL для целей: сравнение. Учитывая очевидные различия в очистке по времени в vCache и FlashCache, оба устройства кэширования были настроены таким образом, чтобы очистка по времени была отключена. Кроме того, оба устройства были настроены таким образом, чтобы все операции ввода-вывода были кэшированы (т. Е. Без специальной обработки последовательных записей) и с 50% -ным пороговым значением «грязной» страницы. Опять же, для сравнения, я также включил числа из теста vCache, в котором включена временная очистка.
Как и следовало ожидать, решение только для жестких дисков практически не зарегистрировано на графике. С буферным пулом, который намного меньше, чем рабочий набор, подход без кэширования довольно ограничен и неэффективен. FlashCache работает значительно лучше, в среднем около 600 т / с, но vCache примерно в 3 раза лучше. Интересным моментом здесь является то, что vCache с включенной очисткой по времени на самом деле обеспечивает лучшую и более стабильную производительность, чем vCache без очистки по времени, но даже в худшем случае тест vCache без очистки по времени по-прежнему опережает FlashCache более чем в 2 раза. средний.
Если посмотреть только на чтение sysbench, то vCache с очисткой по времени постоянно достигает около 27000 в секунду, тогда как без очистки по времени он в среднем составляет около 12500. FlashCache пришел примерно на 7500 или около того. Записей Sysbench было чуть меньше 8000 для vCache + очистка на основе времени, около 6000 для vCache без очистки на основе времени и где-то около 2500 для FlashCache.
Мы можем взглянуть на некоторые данные vmstat, чтобы увидеть, что на самом деле происходит в системе во время всех этих различных тестов. По часовой стрелке слева вверху на следующем графике мы видим «без кеша», «FlashCache», «vCache без временной очистки» и «vCache с временной очисткой». Как показывают изображения, система без кэширования разрушается из-за ожидания ввода-вывода. И FlashCache, и vCache показывают улучшения, но пока мы не доберемся до vCache с очисткой по времени, мы увидим хорошую, предсказуемую, постоянную производительность.
Так почему же vCache с очисткой по времени превосходит все остальные? Моя гипотеза здесь заключается в том, что основанное на времени очищение позволяет записывать резервное хранилище с более постоянной и, возможно, субмаксимальной скоростью, по сравнению с очисткой пороговых значений для грязной страницы, которая срабатывает на заданном уровне, а затем пытается выполнить сброс как как можно быстрее вернуть грязные страницы в приемлемые рамки. Это, однако, только гипотеза.
vCache против FlashCache — порог грязной страницы
Наконец, мы исследуем влияние пары различных коэффициентов грязных страниц на производительность устройства, поскольку это единственный параметр, который можно надежно варьировать между ними одним и тем же способом. На следующем графике показана производительность sysbench OLTP для FlashCache по сравнению с vCache с пороговым значением 10% для грязной среды по сравнению с теми же показателями для пороговой величины 50% для грязной среды. Промывка по времени была отключена. В этом случае обе системы производят лучшую производительность, когда пороговое значение для грязной страницы установлено на 50%, но опять же, vCache на 10% превосходит FlashCache на 10%.
Один интересный момент здесь заключается в том, что vCache действительно со временем становится лучше; Я не совсем уверен, почему это так или в какой момент производительность будет снижаться, так как все эти тесты все равно выполнялись в течение 2 часов, но я думаю, что общие результаты все еще говорят сами за себя, и даже с объемом vCache, где коэффициент загрязнения составляет всего 10%, как это может быть в случае, когда развертывание имеет огромный размер набора данных по отношению как к рабочему набору, так и к размеру устройства кеша, цифры обнадеживают.
Вывод
В целом, я думаю, что графики говорят сами за себя. Когда рабочий набор превосходит доступную память пула буферов, но все еще умещается в устройстве кеша, vCache светит. По сравнению с развертыванием без SSD-кэша, FlashCache по-прежнему работает достаточно хорошо, значительно превосходя настройки только для HDD, но даже не приближается к цифрам, полученным с помощью vCache. Могут быть способы настройки конфигурации FlashCache для получения лучших или более согласованных результатов или результатов, которые в большей степени соответствуют цифрам, выставленным vCache, но когда мы считаем, что общее удобство использования было одной из точек оценки, и объединяем это с фактом что лучшие результаты производительности vCache были получены при конфигурации vCache по умолчанию, я думаю, что vCache можно объявить явным победителем.
Базовая конфигурация MySQL и Benchmark
Все тесты проводились со следующим:
sysbench --num-threads=32 --test=tests/db/oltp.lua --oltp_tables_count=32 \ --oltp-table-size=10000000 --rand-init=on --report-interval=1 --rand-type=pareto \ --forced-shutdown=1 --max-time=7200 --max-requests=0 --percentile=95 \ --mysql-user=root --mysql-socket=/tmp/mysql.sock --mysql-table-engine=innodb \ --oltp-read-only=off run
Базовая конфигурация MySQL (конфигурация A) представлена ниже:
#####fixed innodb options innodb_file_format = barracuda innodb_buffer_pool_size = 4G innodb_file_per_table = true innodb_data_file_path = ibdata1:100M innodb_flush_method = O_DIRECT innodb_log_buffer_size = 128M innodb_flush_log_at_trx_commit = 1 innodb_log_file_size = 1G innodb_log_files_in_group = 2 innodb_purge_threads = 1 innodb_fast_shutdown = 1 #not innodb options (fixed) back_log = 50 wait_timeout = 120 max_connections = 5000 max_prepared_stmt_count=500000 max_connect_errors = 10 table_open_cache = 10240 max_allowed_packet = 16M binlog_cache_size = 16M max_heap_table_size = 64M sort_buffer_size = 4M join_buffer_size = 4M thread_cache_size = 1000 query_cache_size = 0 query_cache_type = 0 ft_min_word_len = 4 thread_stack = 192K tmp_table_size = 64M serverid = 101 key_buffer_size = 8M read_buffer_size = 1M read_rnd_buffer_size = 4M bulk_insert_buffer_size = 8M myisam_sort_buffer_size = 8M myisam_max_sort_file_size = 10G myisam_repair_threads = 1 myisam_recover