数据库中间件-性能调优实战

Posted 2021-04-30 微创智云

操作系统优化

打开最大文件句柄数

    设置为5000-1万，在ClusterDB Server和mysql数据库的机器上都设置。 

查看用户单一进程最大文件打开数

ulimit -n

ulimit

修改文件句柄数查看：

 添加下面两行

 

 vi/etc/security/limits.conf 

在# End of file 上一行加入

* softnofile 65535

* hardnofile 65535

* softnproc 65535

* hardnproc 65535

 

#datalength

ulimit -dunlimited

#max mem

ulimit -munlimited

#stacksize

ulimit -sunlimited

#CPU time

ulimit -tunlimited

#VM

ulimit -vunlimited

 

退出，重新进入命令行执行ulimit –a 查看是否生效

 

注释掉这一行：

 

20-nproc&90-nproc

vi/etc/security/limits.d/20-nproc.conf

vi/etc/security/limits.d/90-nproc.conf 中修改* soft nproc 1024  为

*          soft    nproc    16384

*          hard    nproc    32768

login

在etc/pam.d/login的最后加入

vi/etc/pam.d/login

sessionrequired /lib/security/pam_limits.so

sessionrequired pam_limits.so

TCP连接数

打开系统的TIMEWAIT重用和快速回收

编辑文件/etc/sysctl.conf，加入以下内容：

net.ipv4.tcp_syncookies= 1

net.ipv4.tcp_tw_reuse= 1

net.ipv4.tcp_tw_recycle= 1

net.ipv4.tcp_fin_timeout= 30

 

然后执行 /sbin/sysctl -p 让参数生效。

ClusterDB优化配置

ClusterDB中间件性能优化

 操作系统优化配置

1.文件句柄数修改

  ulimit -a 

2.TCP连接优化

ClusterDB优化配置

3.ClusterDB 启动内存配置优化 

conf/wrapper.conf

#物理内存3/4

wrapper.java.additional.5=-XX:MaxDirectMemorySize=20G

#物理内存2/3

wrapper.java.additional.10=-Xmx15G

#物理内存1/4

wrapper.java.additional.11=-Xms4G

  

4.service.xml配置优化

  

    <!--  256-1024   -->

    <propertyname="processors">1024</property>

    <!--  16-64 -->

 <propertyname="processorExecutor">64</property>

JVM调优

内存占用分两部分:Java堆内存+直接内存映射（DirectBuffer占用），建议堆内存

适度大小，直接映射内存尽可能大，两种一起占据操作系统的1/2-2/3的内存。

 

在conf\wrapper.conf文件中，下面是一段实例：

# JavaAdditional Parameters

wrapper.java.additional.5=-XX:MaxDirectMemorySize=2G

wrapper.java.additional.6=-Dcom.sun.management.jmxremote

# Initial JavaHeap Size (in MB)

wrapper.java.initmemory=2048

# Maximum JavaHeap Size (in MB)

wrapper.java.maxmemory=2048

 

修改wrapper.Java.command 为jdk的bin目录下的java

wrapper.java.command=/opt/jdk1.7.0_45/bin/java

配置 wrapper.conf

vi./conf/wrapper.conf

1984端口修改

 

wrapper.java.additional.5=-XX:MaxDirectMemorySize=2G

修改大一点如：wrapper.java.additional.5=-XX:MaxDirectMemorySize=10G

 

 

添加打印堆栈信息

wrapper.java.additional.12=-XX:+HeapDumpOnOutOfMemoryError

wrapper.java.additional.13=-XX:+HeapDumpOnOutOfMemoryError

 

startup_nowrap文件

在MyCat1.6.5版本bin/startup_nowrap.sh或 bin/startup_nowrap.bat

下面以服务器16G内存为例，Mycat堆内存4G，直接内存映射6G，JVM参数如

下：

-server -Xms4G–Xmx4G   XX:MaxPermSize=64M-XX:MaxDirectMemorySize=6G

 

配置schema.xml

  conf/schema.xml

1. 设置<schema name="TESTDB"checkSQLschema="true" sqlMaxLimit="100">

中的checkSQLschema为false ,要求在开发中，不能在sql中添加数据库的名称

如TESTDB.company,这样可以优化SQL解析。

2.<dataHostname="dap_host1" maxCon="100" minCon="1"balance="3" writeType="0"

dbType="mysql" dbDriver="native"switchType="-1" slaveThreshold="100">

最大连接池maxCon,可以修个为1000至2000 ，同一个MySQL实例上的所有

datanode节点共享本dataHost上的物理连接，性能测试的时候，建议

minCon=maxCon=mysqlmax_connections 设为2000左右。另外，读写分离

是否开启，根据环境的配置来决定。 

缓存优化调整 

Show @@cache命令展示了缓存的使用情况，经常观察其结果，需要时候进行调整： 

一般来说：若CUR接近MAX，而PUT大于MAX很多，则表明MAX需要增大， HIT/ACCESS为缓存命中率，这个值越高越好。重新调整缓存的最大值以后，观测指标都会跟随变化，调整是否有效，主要观察缓存命中率是否在提升，PUT则下降。

 

conf/cacheservice.properties：缓存区的配置

目前缓存服务的配置文件为：cacheservice.properties，主要使用的缓存为enhache，enhache.xml里面设定了enhance缓存的全局属性，下面定义了几个缓存：

#used formycat cache service conf  

factory.encache=org.opencloudb.cache.impl.EnchachePooFactory

#key ispool name ,value is type,max size, expire seconds

pool.SQLRouteCache=encache,10000,1800

pool.ER_SQL2PARENTID=encache,1000,1800 

layedpool.TableID2DataNodeCache=encache,10000,18000

layedpool.TableID2DataNodeCache.TESTDB_ORDERS=50000,18000 

l SQLRouteCache为SQL 解析和路由选择的缓存，这个大小基本相对固定，就是所有 SELECT语句的数量。  

l ER_SQL2PARENTID为ER分片时候，根据关联SQL查询父表的节点时候用到，没有用到ER分片的，这个缓存用不到  

l TableID2DataNodeCache，当某个表的分片字段不是主键时，缓存主键到分片ID的关系，这个是二层的缓存，每个表定义一个子缓存，如”TEST_ORDERS”，这里命名为 schema_tableName（tablename要大写），当有很多的根据主键查询SQL时，这个缓存往往需要设置比较大，才能更好的提升性能。     

Mycat大数据量查询调优：    

1.返回结果比较多

 

建议调整 frontWriteQueueSize 在系统许可的情况下加大，默认值*3

这个原因是因为返回数据太多  

这里做了一个改进，就是超过POOL以后，仍然创建临时的BUFFER供使用，但这些不回收。。   这样的情况下，需要增加BUFFER参数  

调整processorBufferPool = 默认值*2  

不够的情况下，继续加大。

 

 

cacheservice是SQL的缓存服务

SQLRouteCache：sql路由缓存，通过缓存SQL语句的路由信息，下次查询，不用再路由了，直接从缓存中获取路由信息，然后发到各个节点执行；

TableID2DataNodeCache：表主键ID的路由缓存，为每一个表建一个缓存池，命名为TableID2DataNodeCache.TESTDB_表名,缓存的key是id的值，value是节点名；

ER_SQL2PARENTID： ER关系的缓存目前只是在Insert语句中才会使用缓存，子表插入数据的时候，根据joinKey的值，判断父表所在分片，从而定位子表分片，分片信息put缓存，以便下次直接获取

由于在测试的时候并没有对测试表是简单的区域划分，所以在测试中对后两个缓存是没有利用到的，具体对缓存大小的调整可以参考SQLRouteCache；

首先贴出结论：SQLRouteCache的大小对具体的QPS有比较大的影响，在实际的测试过程中，保持线程并发不变的情况下，从100W-300W都有调整过，大概每增加50W，有约15%的增加，直观来看的话,从100W-300W的增加过程中，128线程，5张表x5000W行/表的情况下，QPS范围从1W5-2W5，然而有一个问题很重要，当这个值增加到比较高后，会频繁出现极高的sys占用率，同时vmstat命令下，proc列会有非常高的r和b，直接后果就是MyCAT server本身会出现剧烈的性能波动，在基准测试中，QPS的低谷会降到3000-4000；但是free查看内存使用的时候，并没有出现内存不足的情况，推断为MyCAT本身的缓存设计中存在不完善的地方；

具体的设置值，在不断的测试中，以之前的虚拟机的配置（4核，32G）为参考，当SQLRouteCache的值设置到180W以上的时候，就会不定时的出现性能波动，为了保证稳定运行，在基准测试时采用了较低的150W

 

PS：由于基准测试的时候，SQL语句模板里面的参数都是采用随机值，所以缓存的命中率是偏低的（150W的设置下，大约只有25%的命中率），生产环境下，这个命中率会高很多，同时QPS也会有一定程度的上升

PPS：这个routeCache和MySQL的queryCache比较像，缓存的都是具体的SQL语句，而不是框架里面的带？占位符的语句，queryCache的信息可以参考http://blog.itpub.net/29510932/viewspace-1694922/

 

配置server.xml

processors：用于指定可用线程数，实际上由于现在的多核CPU和超线程技术，这个值可以酌情调高，256-1024

processorExecutor：类似于线程池大小的参数，酌情修改即可，在1.4之后，这个线程池是用来做异步处理逻辑的时候用的，对并发能力的影响相对较小了 16-64

processorBufferPool：BufferPool的大小，原则上来说，调高一些会比较好

processorBufferChunk：每一个Buffer块的大小，processorBufferPool/processorBufferChun可以得到buffer块的数量

server调整总结

processors+processorExecutor会影响到MyCAT可用的线程数，虽然调高点会比较好，但是调的太高会导致频繁的上下文切换和软中断，在实际调整中，用top观察sys和si的百分比，如果服务器/虚拟机并没有什么不干净的后台程序和其他的服务在运行，sys在10%-15%之内，si在5%之内是比较理想的状态；

processorBufferPool+processorBufferChunk影响的server缓存，保持processorBufferChunk大小合理的情况下，增加buffer块的数量才是关键；

 

 <!— CPU核心数越多，可以越大，当发现系统CPU压力很小的情况下，可以适当调大此参数，如4核心的4CPU，可以设置为16，24核心的可以最大设置为128——>  

 <property name="processors">1</property> 

下面这个参数为每个processor的线程池大小，建议可以是16-64，根据系统能力来测试和确定。 

<property name="processorExecutor">16</property>  

</system> 

System中以下重要参数也根据情况进行调整

processorBufferPool ：每个processor分配的Socket Direct Buffer，用于网络通信，每

个processor上管理的所有连接共享，processorBufferChunk为Pool的最小分配单元，每个POOL的容量即为processorBufferPool/processorBufferChunk，默认前者为1024 * 1024 * 16=16M，后者为4096字节。processorBufferPool参数的调整，需要观察show @@processor的结果来确定： 

BU_PERCENT为已使用的百分比、BU_WARNS为Socket Buffer Pool不够时，临时创新的新的BUFFER的次数，若百分比经常超过90%并且BU_WARNS>0，则表明

BUFFER不够，需要增大processorBufferPool。基本上，连接数越多，并发越高，需要的POOL越大，建议BU_PERCENT最大在40-80%之间。