MySQL性能測試--jemalloc內存管理

1.目的
測試在jemalloc內存管理方式與glibc庫的malloc內存管理方式兩種情況下，MySQL的性能情況。通過測試，希望能夠從內存管理方式的優化上，提高MySQL的性能。

2.測試環境
2.1 測試服務器硬件環境

Summary:        Dell R720xd, 2 x Xeon E5-2630 0 2.30GHz, 189GB / 192GB 1333MHz DDR3
System:         Dell PowerEdge R720xd (Dell 0X6FFV)
Processors:     2 x Xeon E5-2630 0 2.30GHz 7200MHz FSB (HT enabled, 12 cores, 24 threads)
Memory:         189GB / 192GB 1333MHz DDR3 == 12 x 16GB - 16GB PC3-10600 Hynix DDR3-1333 ECC Registered CL9 2Rx4 

2.2測試服務器軟件環境

Linux 2.6.32-220.23.2.ali878.el6.x86_64
mysql-5.5.18

2.3 MySQL配置

binlog_format[ROW]
max_binlog_cache_size[2G]
max_binlog_size[500M]
sync_binlog[1]
thread_cache_size[256]
innodb_buffer_pool_instances[8]
innodb_buffer_pool_size[74G]
innodb_flush_log_at_trx_commit[1]
innodb_flush_method[O_DIRECT]
innodb_io_capacity[1000]
innodb_log_buffer_size[64M]
innodb_log_file_size[1G]
innodb_log_files_in_group[4]
innodb_max_dirty_pages_pct[60]
innodb_thread_concurrency[16]

3.測試方案
3.1測試內容
測試glibc庫的malloc與jemalloc的內存管理方式，分別在只讀模式和讀寫混合模式下，隨著測試連接線程數的增多，MySQL性能的影響，以及內存的使用情況。

3.2測試連接線程數
Connect thread 32 64 128 256 512
3.3測試內存管理版本
Version glibc-2.12 jemalloc-3.4.0
3.4測試指令
測試通過sysbench壓測工具進行壓力測試，數據量（約為23G）小於innodb_buffer_pool_size的大小，使得IO不成為瓶頸。通過只讀和讀寫混合測試，測試MySQL的性能。

# 初始化數據
./sysbench --test=tests/db/parallel_prepare.lua --max-time=1000 --oltp-dist-type=uniform --max-requests=0 --mysql-user=test --mysql-password=test --mysql-table-engine=innodb --oltp-table-size=3000000 --oltp-tables-count=32 --oltp-range-size=90 --oltp-point-selects=1 --oltp-simple-ranges=1 --oltp-sum-ranHges=1 --oltp-order-ranges=1 --oltp-distinct-ranges=1 --oltp-non-index-updates=10 --num-threads=32  --mysql-host=10.207.105.1 --mysql-port=3306 run

# 只讀壓力測試
./sysbench --test=tests/db/oltp.lua --max-time=3600 --oltp-dist-type=uniform --max-requests=0 --mysql-user=test --mysql-password=test --mysql-table-engi ne=innodb --oltp-table-size=3000000 --oltp-tables-count=32 --oltp-range-size=90 --oltp-point-selects=12 --num-threads=64 --mysql-host=10.207.105.1 --my sql-port=3306  --oltp-read-only=on run

# 讀寫混合壓力測試
./sysbench --test=tests/db/oltp.lua --max-time=3600 --oltp-dist-type=uniform --max-requests=0 --mysql-user=test --mysql-password=test --mysql-table-engine=innodb --oltp-table-size=3000000 --oltp-tables-count=32 --oltp-range-size=90 --oltp-point-selects=12 --oltp-index-updates=1 --oltp-non-index-updates=1 --num-threads=32 --mysql-host=10.207.105.1 --mysql-port=3306 run 

4.性能指標
性能指標主要包括：
cpu： %user
memory：vsize，rss
mysql：QPS，TPS
其中，vsize表示mysqld進程的虛擬地址空間大小；rss表示駐留物理地址空間的大小。查看原因見參考文檔。

5.測試結果
5.1只讀測試
1、CPU利用率
MySQL在只讀測試下，隨著線程數的增加，CPU的%usr的變化。從測試結果來看，jemalloc內存分配方式與glibc的malloc相比，CPU的利用率降低，並且利用率隨線程數的增加而差距增大。但是當線程數到達512時，CPU利用率基本一致，分析原因是由於達到CPU的處理上線導致。
2、QPS
MySQL只讀測試下，jemalloc內存分配方式比glic的malloc方式，QPS有較大的提高，並且提高程度隨線程數增加而幅度加大。具體如下所示：
3、MySQL的RSS
MySQL只讀測試下，隨著線程數的增加，MySQL的RSS在jemalloc內存方式下比glic的malloc方式下，占用物理內存的大小差距越來越大。具體如下圖所示：
4、MySQL的VSIZE
MySQL只讀測試下，jemalloc內存方式與glic的malloc方式相比，MySQL的VSIZE的大小減小了較多，並且隨著線程數的增大，差距越來越大。具體如下圖所示：
5.2讀寫測試
1、CPU利用率
MySQL在讀寫混合模式下（讀寫比6:1），隨著線程數的增加，jemalloc內存分配方式與glic的malloc分配方式相比，CPU的%user利用率無明顯變化。從以下結果中可知，在讀寫混合模式下，MySQL對CPU的利用很快達到瓶頸，線程數的增加沒有明顯效果。
2、QPS
在讀寫混合模式下，MySQL的QPS隨著線程數的增加，有一些提高，但與只讀模式測試相比，提高幅度較小。
3、TPS
在讀寫混合模式下，MySQL的TPS隨著線程數的增加，jemalloc內存分配方式與glic的malloc相比，提高程度不斷增大。
4、RSS
在讀寫混合模式下，隨著線程數的增加，jemalloc內存分配方式與glic的malloc相比，MySQL的RSS不斷減小。
5、VSIZE
在讀寫混合模式下，隨著線程數的增加，jemalloc內存分配方式與glic的malloc相比，MySQL的VSIZE大小差距不斷增加。
6.結論
通過測試，發現jemalloc內存分配方式與glic的malloc內存分配方式相比，在只讀模式下，CPU利用率最大降低了10%左右；MySQL的RSS最大降低了12%左右；MySQL的VSIZE最大降低了1%左右；MySQL的QPS最大提高了25%左右。

在讀寫混合模式下，CPU利用率基本無變化，是由於MySQL的CPU利用很快達到瓶頸的原因；MySQL的RSS最大降低了11%左右；MySQL的VSIZE最大降低了28%；MySQL的QPS最大提高了15%；MySQL的TPS最大提高了15%左右。

整體來看，jemalloc內存分配方式與glic的malloc內存分配方式相比，提高了MySQL的性能，降低了系統CPU和內存資源的利用。從壓測情況來看，基本達到測試的期望。
原文：http://blog.chinaunix.net/uid-26896862-id-3865087.html