Статьи

Работа с парой ошибок в MySQL 5.6.7-RC

Сентябрь 13, 2018

Следующая статья была первоначально написана в MySQL Performance Blog Вадимом Ткаченко

MySQL 5.6.7 RC есть, поэтому я решил проверить, как он работает в рабочей нагрузке tpcc-mysql с точки зрения производительности и стабильности.
Я не могу сказать, что мой опыт был абсолютно безупречен, я столкнулся с двумя ошибками:

Но, в конце концов, разве это не RC? И Oracle запросил отзыв , так что я делаю свое дело.

  • Контрольная дата: октябрь-2012
  • Цель теста: протестировать работу MySQL 5.6.7
  • Спецификация оборудования

    • Сервер: Dell PowerEdge R710
    • Процессор: 2x Intel (R) Xeon (R) CPU E5-2660 0 @ 2,20 ГГц
    • Память: 192 ГБ
    • Память: очень быстрая флешка PCIe
    • Файловая система: ext4
  • Программного обеспечения

    • ОС: CentOS 6.3
    • Версия MySQL: 5.6.7-RC
  • Спецификация эталона

    • Название теста: tpcc-mysql
    • Коэффициент масштабирования: 2500 Вт (~ 250 ГБ данных)
    • Длительность эталонного теста: 4000 с, но результат берется только за последние 2000 с для удаления фазы прогрева Измерения проводятся каждую секунду.
  • Изменяемые параметры: мы варьируем innodb_buffer_pool_size : 13, 25, 50, 75, 100, 125 ГБ, чтобы иметь различное соотношение памяти и данных. Мы различаем innodb_buffer_pool_instances : 1 и 8 и innodb_log_file_size : 2x4GB и 2x8GB .

    • Полученные результаты

    Первый результат — файлы журнала innodb 2×4 ГБ

    Мы можем видеть, что innodb_buffer_pool_instances = 8 имеет большое значение для небольших размеров buffer_pool, в то время как для больших buffer_pool более предпочтительным является innodb_buffer_pool_instances = 1 .

    Результаты с большим значением buffer_pool довольно нестабильны, и причина в том, что InnoDB переходит в режим асинхронной очистки, проблема, которая должна была быть исправлена ​​в новом механизме очистки InnoDB. Однако Димитрий сказал мне, что нам могут потребоваться большие файлы журнала innodb, чтобы получить более стабильные результаты.

    Так что это с 2x4GB против 2x8GB журналов innodb.

    Очевидно, что с большими бревнами результат намного лучше, поэтому размер имеет значение.

    Заключение Параметр
    innodb_buffer_pool_instances может значительно изменить результат, особенно в интенсивных рабочих нагрузках ввода-вывода.
    В MySQL 5.6 наконец возможно достичь стабильной пропускной способности без провалов, но адаптивная очистка все еще требует больших файлов журнала.

    Конфигурация MySQL:

     

[mysqld]
gdb

innodb_file_per_table = true
innodb_data_file_path = ibdata1:100M:autoextend
innodb_flush_method = O_DIRECT
innodb_log_buffer_size = 256M

innodb_flush_log_at_trx_commit = 1
innodb_buffer_pool_size = 125G
innodb_buffer_pool_instances=8

innodb_log_file_size = 4G
innodb_log_files_in_group = 2
#####plugin options
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_io_capacity = 20000
innodb_io_capacity_max = 40000


#not innodb options (fixed)
port = 3306
back_log = 50
max_connections = 2000
max_prepared_stmt_count=500000
max_connect_errors = 10
table_open_cache = 2048
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

server-id = 10
#*** MyISAM Specific options
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
user=root
skip-grant-tables

37
Share: