MyCat性能优化

Stella981
• 阅读 542

    由于公司业务的快速发展导致数据库的数据量飞速增长,我们底层数据的存储,逐渐成为制约整个产品性能的核心部分。于是我们调研了各大数据库分库产品,如:hibernate5+对多租户的支持,当当ShardingJdbc,mysqlProxy,mycat等。最终考虑到国内目前各个产品的活跃度和成熟度,以及对现有业务的适配情况,最终选择了mycat作为分库分表的中间件产品。经过了几轮性能测试,发现mycat表现基本良好,性能损失率约为30%,在可接受的范围内。于是考虑在不分库分表的情况下,将mycat作为数据库代理,先在线上做个简单测试,没想到简单业务的服务没问题,但是核心服务在连接mycat时会出现请求响应缓慢的问题,一个通过主键查对象的SQL响应时间居然超过1秒钟。于是,赶紧下线mycat,重新连接mysql后,性能稳定下来。这没分库就表现这么差,分库了还了得。。。心有不甘,于是笔者踏上了mycat性能调优的汤坑之路。。

 一、日志对mycat性能的影响

1.log4j.xml配置成debug级别,mycat jvm参数:Xmx4G Xms4G XX:MaxDirectMemorySize=4G

a.GC情况:

S0      S1     E        O      P  YGC  YGCT FGC FGCT GCT 
88.69 0.00 77.57 5.05 � 2216 8.390 1      0.067 8.457
77.93 0.00 11.34 5.06 � 2218 8.399 1      0.067 8.466
0.00 76.96 46.41 5.06 � 2219 8.403 1      0.067 8.470
74.38 0.00 83.05 5.06 � 2220 8.408 1      0.067 8.475
60.70 0.00 18.26 5.07 � 2222 8.417 1      0.067 8.484
0.00 65.79 52.49 5.07 � 2223 8.421 1      0.067 8.488
73.44 0.00 87.12 5.07 � 2224 8.426 1      0.067 8.492
70.79 0.00 21.50 5.08 � 2226 8.435 1      0.067 8.501

每秒1~2次非常频繁

b.JVM CPU监控:

MyCat性能优化

log4j占用CPU时间最长。

c.JVM MEM监控:

MyCat性能优化

内存占用最多的是字符类型

d.2000个简单查询耗时统计

total costs(ms)

total costs(ms)

total costs(ms)

avg total costs(ms)

costs(ms)

costs(ms)

costs(ms)

avg costs(ms)

mysql

22935

24316

25853

24368

11

12

12

11.6

mycat

173680

171557

170718

171985

86

85

85

85.3

mysql耗时统计图:

MyCat性能优化

mycat耗时统计图:

MyCat性能优化

根据数据分析可得:mycat比mysql慢6.07倍

2.log4j.xml配置成error级别,mycat jvm参数:Xmx4G Xms4G XX:MaxDirectMemorySize=4G

a.GC情况:

S0      S1     E        O      P  YGC  YGCT FGC FGCT GCT 

84.81 0.00 70.54 1.24 � 94 2.451 1 0.064 2.515
84.81 0.00 80.04 1.24 � 94 2.451 1 0.064 2.515
84.81 0.00 85.36 1.24 � 94 2.451 1 0.064 2.515
84.81 0.00 87.42 1.24 � 94 2.451 1 0.064 2.515
84.81 0.00 89.46 1.24 � 94 2.451 1 0.064 2.515
84.81 0.00 91.69 1.24 � 94 2.451 1 0.064 2.515
84.81 0.00 93.53 1.24 � 94 2.451 1 0.064 2.515
84.81 0.00 96.10 1.24 � 94 2.451 1 0.064 2.515
84.81 0.00 97.97 1.24 � 94 2.451 1 0.064 2.515
84.81 0.00 98.69 1.24 � 94 2.451 1 0.064 2.515
0.00 92.86 13.14 1.25 � 95 2.472 1 0.064 2.536
0.00 92.86 49.48 1.25 � 95 2.472 1 0.064 2.536
0.00 92.86 68.61 1.25 � 95 2.472 1 0.064 2.536

每秒0.08次,看来日志输出是造成mycat GC频繁的元凶

b.JVM CPU监控:

MyCat性能优化

log4j占用CPU的时间已经找不到了,最长的是mycat处理查询结果的线程。

c.JVM MEM监控:

MyCat性能优化

调整日志级别后,int[] 对象占用的内存大大减少了

d.2000个简单查询耗时统计

total costs(ms)

total costs(ms)

total costs(ms)

avg total costs(ms)

costs(ms)

costs(ms)

costs(ms)

avg costs(ms)

mysql

37680

36239

36705

36874

18

18

18

18

mycat

40554

39345

40623

40174

20

19

20

19.6

mysql耗时统计图:

MyCat性能优化

mycat耗时统计图:

MyCat性能优化

根据数据分析可得:mycat比mysql慢0.08倍

MyCat性能优化

疑问:mycat在调整日志,重新启动后,第一次测试时发生了性能抖动,之后平缓

mycat性能抖动图:

结论:日志需要开启error级别,否则将会造成mycat GC频繁,从而影响 响应时间

 二、DirectMemory对mycat性能的影响

1.log4j.xml配置成error级别,mycat jvm参数:Xmx4G Xms4G

a.GC对比

XX:MaxDirectMemorySize=4G

XX:MaxDirectMemorySize=3G

XX:MaxDirectMemorySize=2G

XX:MaxDirectMemorySize=1G

 GC

S0 S1 E O P YGC YGCT FGC FGCT GCT 
0.00 89.70 67.74 1.52 � 89 2.286 1 0.061 2.348
89.41 0.00 28.13 1.54 � 90 2.313 1 0.061 2.374
89.41 0.00 85.84 1.54 � 90 2.313 1 0.061 2.374
0.00 87.12 41.31 1.56 � 91 2.343 1 0.061 2.404
0.00 87.12 98.46 1.56 � 92 2.343 1 0.061 2.404
88.52 0.00 53.41 1.57 � 92 2.373 1 0.061 2.434
0.00 89.73 9.57 1.59 � 93 2.403 1 0.061 2.465
0.00 89.73 66.74 1.59 � 93 2.403 1 0.061 2.465
90.80 0.00 23.15 1.61 � 94 2.432 1 0.061 2.494
90.80 0.00 81.01 1.61 � 94 2.432 1 0.061 2.494
0.00 90.47 37.72 1.62 � 95 2.462 1 0.061 2.523
0.00 90.47 95.76 1.62 � 95 2.462 1 0.061 2.523
93.21 0.00 53.53 1.64 � 96 2.492 1 0.061 2.553  

 S0 S1 E O P YGC YGCT FGC FGCT GCT

72.59 0.00 55.69 2.35 � 126 2.661 1 0.066 2.727
72.59 0.00 74.64 2.35 � 126 2.661 1 0.066 2.727
72.59 0.00 82.26 2.35 � 126 2.661 1 0.066 2.727
72.59 0.00 96.14 2.35 � 126 2.661 1 0.066 2.727
72.59 0.00 98.74 2.35 � 126 2.661 1 0.066 2.727
0.00 73.05 24.66 2.36 � 127 2.678 1 0.066 2.744
0.00 73.05 59.14 2.36 � 127 2.678 1 0.066 2.744
0.00 73.05 74.67 2.36 � 127 2.678 1 0.066 2.744
0.00 73.05 80.99 2.36 � 127 2.678 1 0.066 2.744
0.00 73.05 84.09 2.36 � 127 2.678 1 0.066 2.744
0.00 73.05 86.12 2.36 � 127 2.678 1 0.066 2.744
0.00 73.05 89.39 2.36 � 127 2.678 1 0.066 2.744
0.00 73.05 92.26 2.36 � 127 2.678 1 0.066 2.744  

S0 S1 E O P YGC YGCT FGC FGCT GCT 
0.00 53.88 58.44 0.53 � 17 0.181 1 0.065 0.246
61.07 0.00 22.08 0.53 � 18 0.196 1 0.065 0.261
61.07 0.00 82.07 0.53 � 18 0.196 1 0.065 0.261
0.00 64.27 40.67 0.53 � 19 0.214 1 0.065 0.279
40.18 64.27 100.00 0.53 � 20 0.214 1 0.065 0.279
68.31 0.00 58.15 0.53 � 20 0.234 1 0.065 0.299
0.00 69.75 15.67 0.53 � 21 0.255 1 0.065 0.320
0.00 69.75 73.38 0.53 � 21 0.255 1 0.065 0.320
66.83 0.00 30.14 0.53 � 22 0.277 1 0.065 0.342
66.83 0.00 88.50 0.53 � 22 0.277 1 0.065 0.342
0.00 73.20 44.27 0.53 � 23 0.301 1 0.065 0.366
80.58 0.00 1.24 0.53 � 24 0.324 1 0.065 0.389
80.58 0.00 60.64 0.53 � 24 0.324 1 0.065 0.389  

S0 S1 E O P YGC YGCT FGC FGCT GCT 
0.00 58.25 50.25 0.52 � 17 0.192 1 0.064 0.256
64.19 0.00 15.57 0.52 � 18 0.207 1 0.064 0.271
64.19 0.00 75.00 0.52 � 18 0.207 1 0.064 0.271
0.00 67.74 33.33 0.53 � 19 0.226 1 0.064 0.290
0.00 67.74 91.26 0.53 � 19 0.226 1 0.064 0.290
67.43 0.00 48.33 0.53 � 20 0.247 1 0.064 0.311
0.00 76.06 6.20 0.53 � 21 0.267 1 0.064 0.331
0.00 76.06 66.35 0.53 � 21 0.267 1 0.064 0.331
78.43 0.00 24.29 0.53 � 22 0.290 1 0.064 0.354
78.43 0.00 86.86 0.53 � 22 0.290 1 0.064 0.354
0.00 79.12 46.02 0.53 � 23 0.314 1 0.064 0.378
79.61 0.00 0.00 0.53 � 24 0.336 1 0.064 0.400
79.61 0.00 62.98 0.53 � 24 0.336 1 0.064 0.400

 gc有波动,稳定后差不多是0.33次/秒

b.DirectMemory对比

XX:MaxDirectMemorySize=4G

XX:MaxDirectMemorySize=3G

XX:MaxDirectMemorySize=2G

XX:MaxDirectMemorySize=1G

DirectMemory

MyCat性能优化

MyCat性能优化

MyCat性能优化

MyCat性能优化

c.2000个简单查询对比

XX:MaxDirectMemorySize=4G

costs(ms)

XX:MaxDirectMemorySize=3G

costs(ms)

XX:MaxDirectMemorySize=2G

costs(ms)

XX:MaxDirectMemorySize=1G

costs(ms)

mysql

18

18

17

15

mycat

19.6

22

22

21

结论:XX:MaxDirectMemorySize的调整对性能影响不大

 三、Xmx对mycat性能的影响

a.GC对比

Xmx4G

Xmx3G

Xmx2G

Xmx1G

 GC

S0 S1 E O P YGC YGCT FGC FGCT GCT 
0.00 82.58 39.14 0.99 � 55 1.395 1 0.066 1.460
33.46 82.58 100.00 1.01 � 56 1.395 1 0.066 1.460
82.04 0.00 59.80 1.01 � 56 1.425 1 0.066 1.491
0.00 86.30 14.58 1.02 � 57 1.459 1 0.066 1.524
0.00 86.30 71.13 1.02 � 57 1.459 1 0.066 1.524
86.53 0.00 23.09 1.04 � 58 1.493 1 0.066 1.558
86.53 0.00 76.25 1.04 � 58 1.493 1 0.066 1.558
0.00 86.30 39.70 1.06 � 59 1.520 1 0.066 1.585
0.00 86.30 96.79 1.06 � 59 1.520 1 0.066 1.585
79.55 0.00 53.02 1.08 � 60 1.561 1 0.066 1.626
0.00 83.33 8.07 1.10 � 61 1.594 1 0.066 1.660
0.00 83.33 61.35 1.10 � 61 1.594 1 0.066 1.660
80.26 0.00 17.64 1.12 � 62 1.627 1 0.066 1.693  

S0 S1 E O P YGC YGCT FGC FGCT GCT 
0.00 84.61 4.00 2.44 � 127 2.706 1 0.062 2.768
0.00 84.61 97.48 2.44 � 127 2.706 1 0.062 2.768
84.78 0.00 11.81 2.46 � 128 2.723 1 0.062 2.785
84.78 0.00 90.06 2.46 � 128 2.723 1 0.062 2.785
84.78 0.00 98.42 2.46 � 128 2.723 1 0.062 2.785
0.00 76.83 22.84 2.48 � 129 2.739 1 0.062 2.802
0.00 76.83 76.87 2.48 � 129 2.739 1 0.062 2.802
0.00 76.83 98.82 2.48 � 129 2.739 1 0.062 2.802
84.51 0.00 3.76 2.50 � 130 2.757 1 0.062 2.819
84.51 0.00 86.22 2.50 � 130 2.757 1 0.062 2.819
84.51 0.00 98.31 2.50 � 130 2.757 1 0.062 2.819
0.00 76.49 20.33 2.52 � 131 2.773 1 0.062 2.835
0.00 76.49 75.03 2.52 � 131 2.773 1 0.062 2.835

S0 S1 E O P YGC YGCT FGC FGCT GCT 
91.65 0.00 27.10 6.25 � 292 4.636 1 0.064 4.700
0.00 90.26 50.93 6.26 � 293 4.651 1 0.064 4.715
82.54 0.00 67.42 6.28 � 294 4.667 1 0.064 4.731
0.00 86.86 81.88 6.30 � 295 4.685 1 0.064 4.749
86.29 0.00 97.60 6.33 � 296 4.700 1 0.064 4.765
87.07 0.00 14.29 6.37 � 298 4.733 1 0.064 4.798
0.00 88.58 29.21 6.38 � 299 4.750 1 0.064 4.814
89.10 0.00 45.92 6.40 � 300 4.767 1 0.064 4.831
0.00 80.04 61.14 6.42 � 301 4.783 1 0.064 4.847
84.42 0.00 77.88 6.44 � 302 4.800 1 0.064 4.865
0.00 84.94 91.44 6.45 � 303 4.818 1 0.064 4.882
0.00 84.83 1.98 6.49 � 305 4.853 1 0.064 4.917
77.33 0.00 17.87 6.51 � 306 4.868 1 0.064 4.933  

S0 S1 E O P YGC YGCT FGC FGCT GCT 
81.73 0.00 49.91 11.93 � 200 0.706 1 0.059 0.764
66.63 0.00 70.87 11.99 � 202 0.712 1 0.059 0.770
81.48 0.00 75.88 12.05 � 204 0.719 1 0.059 0.778
82.85 0.00 81.89 12.11 � 206 0.726 1 0.059 0.785
99.97 0.00 95.65 12.17 � 209 0.733 1 0.059 0.795
0.00 55.60 8.26 12.28 � 211 0.743 1 0.059 0.801
0.00 81.97 18.77 12.37 � 213 0.750 1 0.059 0.808
0.00 80.48 18.83 12.46 � 215 0.757 1 0.059 0.816
0.00 79.10 19.45 12.51 � 217 0.764 1 0.059 0.822
0.00 88.47 25.51 12.59 � 219 0.771 1 0.059 0.829
0.00 73.85 32.49 12.68 � 221 0.778 1 0.059 0.837
0.00 71.48 42.69 12.76 � 223 0.785 1 0.059 0.844
0.00 72.61 53.90 12.83 � 225 0.793 1 0.059 0.852  

随着内存减少,GC越来越快

b.内存使用情况

Xmx4G

Xmx3G

Xmx2G

Xmx1G

堆内存

MyCat性能优化

MyCat性能优化

MyCat性能优化

MyCat性能优化

c.2000个简单查询对比

Xmx4G

costs(ms)

Xmx3G

costs(ms)

Xmx2G

costs(ms)

Xmx1G

costs(ms)

mysql

18

15

21

19

mycat

21

18

26

24

 四、数据库大表对mycat性能的影响

a.400多列a_account表

1并发(ms)

10并发(ms)

100并发(ms)

200并发(ms)

300并发(ms)

mysql

3.5

4.6

32

61

85

mycat

4.5

6.2

56

81

110

b.5列a_account表

1并发(ms)

10并发(ms)

100并发(ms)

200并发(ms)

300并发(ms)

mysql

1.2

 2.1

 23

 44

 70

mycat

1.9 

2.2 

 22

 45

 68

通过观察2组测试数据,可以发现:

1.400多列表的那组测试中,mycat各并发下,平均都比mysql慢30%左右,

2.5列表的那组测试中,mycat各并发下,与mysql持平

3.通过观察mycat的CPU、内存、线程发现,300列的大表,占用内存非常之高,光char[]类型就达到了700M,CPU保持在30%~40%,NIO读写线程占用CPU时间最长。

   而5列的小表,内存占用非常小,gc次数明显降低,CPU也稳定到了10%~20%的水平。

结论:

1.数据库表结构过大,会对mycat性能产生较大影响

2.由大表读写导致的网络流量对mycat性能影响很大,mycat宿主机需要多网卡支持

 五、大表的SELECT * 对mycat性能的影响

1.通过测试大表的SELECT 全字段,和SELECT * 对比发现,SELECT 全字段时,mycat大部分的CPU都被druid SQL解析占据,yong GC主要是由于mycat解析大SQL引起的,所以ORM框架的全字段改写SQL功能(包括读写)会降低mycat性能。

2.通过将程序的SELECT全字段改为SELECT * 后,mycat GC次数直线下降,CPU也减了下来,并且响应时间得到良好的改善,基本跟直连mysql持平。

3.性能测试时,适当减小路由缓存的参数值,可以很好的减少full gc的次数。

 六、调优过程遇到的坑

1.在整个调优过程中,首先出发点有可能是错误的,我们因为mycat在生产环境发生故障,而将服务的数据源切回mysql后,系统稳定下来,以此为依据断定mycat有性能问题,导致整个调优过程都将思路局限在mycat上,而忽略了自己程序的问题。

2.测试环境中,不同JVM进程会相互抢占CPU,而影响测试结果的稳定性。

3.网络带宽的大小,一度成为我们怀疑的目标,通过各种工具监控后,发现带宽不是瓶颈。

4.AWS ELB的带宽弹性功能,也是我们怀疑过的目标之一,后来通过测试,排除掉该可能性。

5.集群中多个节点同时连接mycat,导致SQL响应缓慢,让我们怀疑到了mycat客户端数量可能是性能瓶颈点。通过测试,发现连接数不是瓶颈,客户端数排除。

6.mycat内存管理有可能成为mycat响应缓慢的元凶,通过监控GC,发现yong gc次数较多,每2秒一次,Eden区很快会被填满,这让我们怀疑到可能是响应数据太大导致,从而将目标定位到数据库表结构上。

7.通过对比大表和小表在相同环境下的响应时间,可以发现小表的表现非常好,和mysql基本持平,从而断定是数据库表结构的问题。

8.由于业务已上线很长时间,不能轻易改动表结构,所以只好继续找mycat大表表现差的原因。受大表致使mycat性能下降观念先入为主的影响,调优很长时间没有思路。

9.偶然机会,同事使用JMeter来测试mycat和mysql的表现,居然发现两者性能差别不大,于是事情有了新的突破,我们开始关注为什么使用测试工具测试没事,我们用自己的服务压测就总有问题,从而将矛头对准了我们自己的底层dal程序。

10.通过使用原生的JDBC压测发现性能很好,于是将问题定位到hibernate。发现hibernate表现非常差,从而将问题锁定为hibernate。

11.通过查看hibernate的日志,发现其和JDBC直连唯一的差别在sql上,hibernate进行了sql改写,通过id查对象时,拼接了400多全列名,并且做了重命名,导致一个SQL的大小约为17K。而将这个大SQL使用JDBC直连执行时,问题得到了重现,从而定位到了性能问题的最终元凶,“hibernate改写后的长SQL”。

12.通过将hibernate通过id获取对象的hql语句改写为SELECT * FROM object后,性能表现良好,与mysql持平,自此,问题得到了解决。。

 七、调优过程用到的工具

1.Linux网络带宽监控工具: nload

2.JVM内存监控工具:jstat、jvisualvm、jmap、jstack、tprofiler、jprofiler

3.mycat集群搭建工具:haproxy

4.Linux CPU监控工具:top

5.绘图工具:gnuplot

6.性能压测工具:JMeter

7.内存分析工具:EclipseMAT

点赞
收藏
评论区
推荐文章
blmius blmius
2年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
Jacquelyn38 Jacquelyn38
2年前
2020年前端实用代码段,为你的工作保驾护航
有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
Stella981 Stella981
2年前
KVM调整cpu和内存
一.修改kvm虚拟机的配置1、virsheditcentos7找到“memory”和“vcpu”标签,将<namecentos7</name<uuid2220a6d1a36a4fbb8523e078b3dfe795</uuid
Easter79 Easter79
2年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Wesley13 Wesley13
2年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Wesley13 Wesley13
2年前
00:Java简单了解
浅谈Java之概述Java是SUN(StanfordUniversityNetwork),斯坦福大学网络公司)1995年推出的一门高级编程语言。Java是一种面向Internet的编程语言。随着Java技术在web方面的不断成熟,已经成为Web应用程序的首选开发语言。Java是简单易学,完全面向对象,安全可靠,与平台无关的编程语言。
Stella981 Stella981
2年前
Django中Admin中的一些参数配置
设置在列表中显示的字段,id为django模型默认的主键list_display('id','name','sex','profession','email','qq','phone','status','create_time')设置在列表可编辑字段list_editable
Wesley13 Wesley13
2年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
Python进阶者 Python进阶者
3个月前
Excel中这日期老是出来00:00:00,怎么用Pandas把这个去除
大家好,我是皮皮。一、前言前几天在Python白银交流群【上海新年人】问了一个Pandas数据筛选的问题。问题如下:这日期老是出来00:00:00,怎么把这个去除。二、实现过程后来【论草莓如何成为冻干莓】给了一个思路和代码如下:pd.toexcel之前把这