bitsCN.com

MySQL 5.6.7 RC 前些天發(fā)布了，因此我決定使用 tpcc-mysql 對其表現(xiàn)進行測試，包括性能和穩(wěn)定性方面。

我不能說我的測試過程是完美無瑕的，因為發(fā)現(xiàn)了兩個 bug ：

MySQL 5.6.7 在 CREATE INDEX 時鎖住了

MySQL 5.6.7-rc 在使用 tpcc-mysql 工作負載測試時崩潰

不曉得是不是因為是 RC 版本的原因，后來向 Oracle 提交一些反饋，下面是詳細的測試環(huán)境：

測試日期: Oct-2012

測試目的: 測試 MySQL 5.6.7 的表現(xiàn)

硬件換

服務(wù)器: Dell PowerEdge R710

CPU: 2x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz

內(nèi)存: 192GB（這個內(nèi)存太猛了）

存儲: Very Fast PCIe Flash Card

文件系統(tǒng): ext4

軟件

操作系統(tǒng): CentOS 6.3

MySQL 版本: 5.6.7-RC

測試規(guī)范

測試工具: tpcc-mysql

測試數(shù)據(jù): 2500W (~250GB of data)

測試時間: 總共測試 4000 秒，但只取最后的 2000 秒，避免因為冷啟動的問題導致測試結(jié)果不準確

不同的測試參數(shù): 使用幾組不同的 innodb_buffer_pool_size:13, 25, 50, 75, 100, 125GB ，innodb_buffer_pool_instances: 1 and 8, and innodb_log_file_size: 2x4GB and 2x8GB.

測試結(jié)果：

第一個結(jié)果使用的事 2x4GB 的 InnoDB 日志文件：

我們可看出當 innodb_buffer_pool_instances=8 在很小的 buffer_pool 大小時有很大的不同，而使用大的 buffer_pool 時，innodb_buffer_pool_instances=1 的表現(xiàn)最棒。

測試結(jié)果在大的 buffer_pool 時是很穩(wěn)定的，原因是 InnoDB 使用異步 flush 模式，在新的 InnoDB flush 機制下以前的問題已經(jīng)修復。不過 Dimitry 告訴我需要一個更大的 InnoDB 日志文件來獲得更穩(wěn)定的結(jié)果。

下面是 2x4GB vs 2x8GB innodb 日志文件大小的比較：

很顯然，使用更大的日志文件，測試結(jié)果更穩(wěn)定！

結(jié)論：

innodb_buffer_pool_instances 參數(shù)顯著的影響測試結(jié)果，特別是非常高的 I/O 負載時。

在 MySQL 5.6 ，最終是可以獲得非常穩(wěn)定的吞吐，但自適應(yīng)的 flush 機制仍需較大的日志文件。

MySQL 配置如下：
01 [mysqld] 02 gdb 03 04 innodb_file_per_table = true 05 innodb_data_file_path = ibdata1:100M:autoextend 06 innodb_flush_method = O_DIRECT 07 innodb_log_buffer_size = 256M 08 09 innodb_flush_log_at_trx_commit = 1 10 innodb_buffer_pool_size = 125G 11 innodb_buffer_pool_instances=8 12 13 innodb_log_file_size = 4G 14 innodb_log_files_in_group = 2 15 #####plugin options 16 innodb_read_io_threads = 16 17 innodb_write_io_threads = 16 18 innodb_io_capacity = 20000 19 innodb_io_capacity_max = 40000 20 21 22 #not innodb options (fixed) 23 port = 3306 24 back_log = 50 25 max_connections = 2000 26 max_prepared_stmt_count=500000 27 max_connect_errors = 10 28 table_open_cache = 2048 29 max_allowed_packet = 16M 30 binlog_cache_size = 16M 31 max_heap_table_size = 64M 32 sort_buffer_size = 4M 33 join_buffer_size = 4M 34 thread_cache_size = 1000 35 query_cache_size = 0 36 query_cache_type = 0 37 ft_min_word_len = 4 38 thread_stack = 192K 39 tmp_table_size = 64M 40 41 server-id = 10 42 #*** MyISAM Specific options 43 key_buffer_size = 8M 44 read_buffer_size = 1M 45 read_rnd_buffer_size = 4M 46 bulk_insert_buffer_size = 8M 47 myisam_sort_buffer_size = 8M 48 myisam_max_sort_file_size = 10G 49 myisam_repair_threads = 1 50 myisam_recover 51 user=root 52 skip-grant-tables

英文原文，OSCHINA原創(chuàng)翻譯

bitsCN.com

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com