tps-ds测试mysql_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的处理上线导致。

0ed38a8a5a153d0127c1688f0b0321e3.png

b9b117879a715138b0041209853cdfde.png

1.1线程数32只读模式的%user利用率

1.2线程数64只读模式的%user利用率

1be2d6e9d3bed82333e0c5482a65f5f8.png

d91867b73f3607570eae3d5c32e1d36c.png

1.3线程数128只读模式的%user利用率

1.4线程数256只读模式的%user利用率

848ff424afe703d5ad66426761efeb74.png

1aa16c6d7100c59dcbcf88b0c6af2633.png

1.5线程数512只读模式的%user利用率

1.6 CPU %user利用率随线程数的变化

2、QPS

MySQL只读测试下,jemalloc内存分配方式比glic的malloc方式,QPS有较大的提高,并且提高程度随线程数增加而幅度加大。具体如下所示:

a47925120f8ecc03485cf90261e26d4e.png

8d611345a1fc9e4327cc7d60f8fb3b2b.png

2.1线程数32只读模式的QPS

2.2线程数64只读模式的QPS

0b6d7f1047cb675880d867305c96e09a.png

95d0a9d14f1587af47642b0541e5784f.png

2.3线程数128只读模式的QPS

2.4线程数256只读模式的QPS

95ad830a65a6a6f19d07a7ddb9f54f22.png

a5f81e3a4830224ac9740be99c404dfb.png

2.5线程数512只读模式的QPS

2.6 QPS随线程数的变化

3、MySQL的RSS

MySQL只读测试下,随着线程数的增加,MySQL的RSS在jemalloc内存方式下比glic的malloc方式下,占用物理内存的大小差距越来越大。具体如下图所示:

157b2134a4eaf5fee62a1fe1e8b5e99b.png

c8135f590b68da316da9198f2207d89a.png

3.1线程数32只读模式的RSS

3.2线程数64只读模式的RSS

31f62844952f264644d3243ad2b21b07.png

bf8b3eb378216433540f8629d347f8e0.png

3.3线程数128只读模式的RSS

3.4线程数256只读模式的RSS

8c28ea1953973045d873345b2cdd2101.png

6aede8753f140443addb43b9138e959f.png

3.5线程数256只读模式的RSS

3.6 RSS随线程数的变化

4、MySQL的VSIZE

MySQL只读测试下,jemalloc内存方式与glic的malloc方式相比,MySQL的VSIZE的大小减小了较多,并且随着线程数的增大,差距越来越大。具体如下图所示:

349bf3980d016ef509e340e9ee6e652d.png

5b597ccae6c20bcc044e5a38fd4705d9.png

4.1线程数32只读模式的VSIZE

4.2线程数64只读模式的VSIZE

60da91be6bc6ec8b08fb72745e820c16.png

e484248d4c4d45dc9a88a9883540d294.png

4.3线程数128只读模式的VSIZE

4.4线程数256只读模式的VSIZE

05a755190a4bdce76bd2205c37d26853.png

0695edfad73efb3a976baa15b5d1e655.png

4.5线程数512只读模式的VSIZE

4.6 VSIZE随线程数的变化

5.2读写测试

1、CPU利用率

MySQL在读写混合模式下(读写比6:1),随着线程数的增加,jemalloc内存分配方式与glic的malloc分配方式相比,CPU的%user利用率无明显变化。从以下结果中可知,在读写混合模式下,MySQL对CPU的利用很快达到瓶颈,线程数的增加没有明显效果。

0e4c11d5804805a1efea0b22939df18f.png

7a5a7d850ed90594138ce71cbdec5dc9.png

5.1线程数32读写模式的%user利用率

5.2线程数64读写模式的%user利用率

fcc81749829d04bac3d00c02e4c38482.png

6b0b1815a85b79f1d6e2873e5aa8e586.png

5.3线程数128读写模式的%user利用率

5.4线程数256读写模式的%user利用率

d292e346bd9af2d147a40abf95bdacaf.png

ba6e4a2d3a0347e979247f2d907289d0.png

5.5线程数512读写模式的%user利用率

5.6 CPU %user利用率随线程数的变化

2、QPS

在读写混合模式下,MySQL的QPS随着线程数的增加,有一些提高,但与只读模式测试相比,提高幅度较小。

a3978e0ff12004c43e8a7886a26a1abe.png

2dbd64a45cd7b6e44afa7010939c63aa.png

6.1线程数32读写模式的QPS

6.2线程数64读写模式的QPS

644ca25d304848525228b1bcfa9436d3.png

1b6f7fdafefcb22ae4f5df1eb0828209.png

6.3线程数128读写模式的QPS

6.4线程数256读写模式的QPS

245983a8be3e3d35a2e1d49bcce667a5.png

d86af6e1b711f72508bc1d0f8aa2d8e3.png

6.5线程数256读写模式的QPS

6.6 QPS随线程数的变化

3、TPS

在读写混合模式下,MySQL的TPS随着线程数的增加,jemalloc内存分配方式与glic的malloc相比,提高程度不断增大。

a70133376a8e300eab2af3a9145a4cb4.png

91f224d123374e3158577669362b8fed.png

7.1线程数32读写模式的TPS

7.2线程数64读写模式的TPS

c13e9e8937e45bea4a96356e0cffe22e.png

85608cdaaa4990a5ffe83102ff429ae5.png

7.3线程数128读写模式的TPS

7.4线程数256读写模式的TPS

35cc240a872d8fd1ba0621d30b815b2e.png

a1e22c78c1ad8c3cf4fe9d175debc4bd.png

7.5线程数512读写模式的TPS

7.6 TPS随线程数的变化

4、RSS

在读写混合模式下,随着线程数的增加,jemalloc内存分配方式与glic的malloc相比,MySQL的RSS不断减小。

780b7fd79375453b3d0774819fb8ee11.png

4f4a80db114674a77f8bcf16c3070104.png

8.1线程数32读写模式的RSS

8.2线程数64读写模式的RSS

92bdb227f1246ed1af1fcfb4e3964364.png

beb66881098883c0f6ced9500649b43d.png

8.3线程数128读写模式的RSS

8.4线程数256读写模式的RSS

bd514c0b49915cf0540465e141589636.png

2175e64482ed7ce5bf48cf694a52d27a.png

8.5线程数512读写模式的RSS

8.6 RSS随线程数的变化

5、VSIZE

在读写混合模式下,随着线程数的增加,jemalloc内存分配方式与glic的malloc相比,MySQL的VSIZE大小差距不断增加。

962f6e2147817f38ffbf6b387e92ee80.png

f8ba3f8a1d8c7e1dd51242006fc11e96.png

9.1线程数32读写模式的VSIZE

9.2线程数64读写模式的VSIZE

0a1295193b2a3a117521b004db47862e.png

699d795af1ad1ac2fae0f0aad5eeb18c.png

9.3线程数128读写模式的VSIZE

9.4线程数256读写模式的VSIZE

be5cd893732b8a25c96091aab365eb9e.png

1cf168ad2232231638727fbdc157ccde.png

9.5线程数512读写模式的VSIZE

9.6 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和内存资源的利用。从压测情况来看,基本达到测试的期望。

参考

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
TPS-1是一个Profinet(工业以太网)网络的硬件设计流程指南。在开始设计TPS-1硬件之前,我们需要明确一些关键的设计要求和指导原则。 首先,为了确保TPS-1的性能和稳定性,我们需要根据Profinet网络的要求选择合适的硬件组件。这包括网络交换机、以太网接口芯片和控制器等。在选择这些硬件组件时,我们需要考虑其兼容性、可扩展性和可靠性。这些组件需要支持Profinet的通信协议和速率,并且应具备接口标准和保障数据传输的高效性。 其次,我们需要根据设计要求来选择合适的硬件架构和电路设计。我们需要设计一个适用于Profinet网络的主板,其中包括处理器、内存、接口和电源等关键组件。在电路设计方面,我们需要确保信号的强度和稳定性,减少噪音干扰,提高数据传输的可靠性和速率。 此外,为了提供灵活性和便利性,我们还需要考虑TPS-1的物理尺寸和外部接口。这些外部接口可能包括以太网接口、USB接口和扩展接口等。在设计这些接口时,我们需要根据实际应用需求来确定并确保其稳定性和可靠性。 最后,在TPS-1的硬件设计完成后,我们需要进行测试和验证。这包括硬件功能和性能测试,以及与其他Profinet设备之间的兼容性测试。通过这些测试和验证,我们可以确保TPS-1的硬件设计达到预期的要求,并且可以正常运行和与其他设备进行通信。 综上所述,TPS-1的硬件设计流程包括选择合适的硬件组件、设计适用于Profinet网络的主板和电路、考虑外部接口的物理尺寸和稳定性,以及进行测试和验证。通过严格遵循这些指南,我们可以设计出满足Profinet网络要求的高性能和稳定性的硬件。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值