有生之年系列----MySQL分布式集群之MyCAT调优初探（四）

这是有生之年系列的填坑_(:з」∠)_
前作第一篇:http://blog.itpub.net/29510932/viewspace-1664499/
前作第二篇:http://blog.itpub.net/29510932/viewspace-1667814/
前作第三篇:http://blog.itpub.net/29510932/viewspace-1678591/
MyCAT基准测试:http://blog.itpub.net/29510932/viewspace-1726924/和http://blog.itpub.net/29510932/viewspace-1717783/
------------------------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------------------------------

背景：接本应接在基准测试之后就整理，不过有别的事情耽搁了

环境：与基准测试时保持一致，4核32G，MyCAT-1.4-RC，6月17号发布的版本，目前最新发布的版本应该是在7.29，七月底的样子。

相关配置文件：server.xml与cacheservice.properties

文件简介：
server.xml：保存了有关MyCAT的配置信息，包括MyCAT对外暴露的schema（包含这个schema对应的账户名和密码），MyCAT server的连接池等参数配置
cacheservice.properties：缓存区的配置

server.xml示例：

点击(此处)折叠或打开

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- - - Licensed under the Apache License, Version 2.0 (the "License");
  3.         - you may not use this file except in compliance with the License. - You
  4.         may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0
  5.         - - Unless required by applicable law or agreed to in writing, software -
  6.         distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT
  7.         WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the
  8.         License for the specific language governing permissions and - limitations
  9.         under the License. -->
  10. <!DOCTYPE mycat:server SYSTEM "server.dtd">
  11. <mycat:server xmlns:mycat="http://org.opencloudb/">
  12.         <system>
  13.         <property name="processors">32</property>
  14.         <property name="processorExecutor">256</property>
  15.         <property name="processorBufferPool">204800000</property>
  16.         <property name="processorBufferChunk">40960</property>
  17.                 <!--默认是65535 64K 用于sql解析时最大文本长度 -->
  18.         <property name="maxStringLiteralLength">65535</property>
  19.                 <!--<property name="sequnceHandlerType">0</property>-->
  20.                 <!--<property name="backSocketNoDelay">1</property>-->
  21.                 <!--<property name="frontSocketNoDelay">1</property>-->
  22.                 <!--<property name="processorExecutor">16</property>-->
  23.                 <!--
  24.                         <property name="mutiNodeLimitType">1</property> 0：开启小数量级（默认） ；1：开启亿级数据排序
  25.                         <property name="mutiNodePatchSize">100</property> 亿级数量排序批量
  26.                         <property name="processors">32</property> <property name="processorExecutor">32</property>
  27.                         <property name="serverPort">8066</property> <property name="managerPort">9066</property>
  28.                         <property name="idleTimeout">300000</property> <property name="bindIp">0.0.0.0</property>
  29.                         <property name="frontWriteQueueSize">4096</property> <property name="processors">32</property> -->
  30.         <property name="defaultSqlParser">druidparser</property>
  31.         </system>
  32.         <!--
  33.         <user name="root">
  34.                 <property name="password">root</property>
  35.                 <property name="schemas">test</property>
  36.         </user>
  37.         <user name="root_read">
  38.                 <property name="password">root_read</property>
  39.                 <property name="schemas">test</property>
  40.                 <property name="readOnly">true</property>
  41.         </user>
  42.         -->
  43.         <user name="test">
  44.                 <property name="password">test</property>
  45.                 <property name="schemas">test</property>
  46.         </user>
  47.         <!-- <cluster> <node name="cobar1"> <property name="host">127.0.0.1</property>
  48.                 <property name="weight">1</property> </node> </cluster> -->
  49.         <!-- <quarantine> <host name="1.2.3.4"> <property name="user">test</property>
  50.                 </host> </quarantine> -->
  51. </mycat:server>

PS：MyCAT对外暴露的schema，是可以使用readonly模式的，如上面配置文件中的加红部分；

processors：用于指定可用线程数，实际上由于现在的多核CPU和超线程技术，这个值可以酌情调高，这里调到了虚拟机核数的八倍，感觉稍稍有点高了，实际上四倍or五倍就差不多了

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

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

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

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

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

cacheservice.properties示例：

点击(此处)折叠或打开

  1. #used for mycat cache service conf
  2. factory.encache=org.opencloudb.cache.impl.EnchachePooFactory
  3. #key is pool name ,value is type,max size, expire seconds
  4. pool.SQLRouteCache=encache,1500000,60
  5. pool.ER_SQL2PARENTID=encache,2000,180
  6. layedpool.TableID2DataNodeCache=encache,3000,18000
  7. layedpool.TableID2DataNodeCache.TESTDB_ORDERS=10000,18000

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/

时间： 2024-09-20 05:52:11

有生之年系列----MySQL分布式集群之MyCAT调优初探（四）的相关文章

MySQL分布式集群之MyCAT（三）rule的分析

            首先写在最前面,MyCAT1.4的alpha版本已经发布了,这里面修复了不少的bug,也完善了一细节,之前两篇博客已经做了一些修改 ---------------------------------------------------------------------------------这才是本体~----------------------------------------------------------------------------------   

MySQL分布式集群之MyCAT（二）schema详解（修正）

        在第一部分,有简单的介绍MyCAT的搭建和配置文件的基本情况,这一篇详细介绍schema的一些具体参数,以及实际作用         首先贴上自己测试用的schema文件,双引号之前的反斜杠不会消除,姑且当成不存在吧... 点击(此处)折叠或打开 ?xml version=\"1.0\"?> !DOCTYPE mycat:schema SYSTEM \"schema.dtd\"> mycat:schema xmlns:mycat=\&qu

MySQL分布式集群搭建

1.准备集群搭建环境 使用6台虚拟机来搭建MySQL分布式集群,相应的实验环境与对应的MySQL节点之间的对应关系如下图所示: 管理节点(MGM):这类节点的作用是管理MySQLCluster内的其他节点,如提供配置数据,并停止节点,运行备份等.由于这类节点负责管理其他节点的配置,应该在启动其他节点之前启动这类节点.MGM节点是用命令"ndb_mgmd"启动的: 数据节点(NDB):这类节点用于保存Cluster的数据,数据节点的数目与副本的数目相关,是片段的倍数.例如,对于两个副本,

MySQL Cluster集群的初级部署教程_Mysql

Mysql Cluster概述    MySql Cluster最显著的优点就是高可用性,高实时性,高冗余,扩展性强.    它允许在无共享的系统中部署"内存中"数据库的Cluster.通过无共享体系结构,系统能够使用廉价的硬件.此外,由于每个组件有自己的内存和磁盘,所以不存在单点故障.    它由一组计算机构成,每台计算机上均运行者多种进程,包括mysql服务器,NDB cluster的数据节点,管理服务启,以及专门的数据访问程序    所有的这些节点构成一个完整的mysql集群体系

MySQL大型分布式集群

本套课程将通过分布式集群和分库分表两部分内容进行讲解 1.主要解决针对大型网站架构中持久化部分中,大量数据存储以及高并发访问所带来是数据读写问题.分布式是将一个业务拆分为多个子业务,部署在不同的服务器上.集群是同一个业务,部署在多个服务器上. 2.着重对数据切分做了细致丰富的讲解,从数据切分的原理出发,一步一步深入理解数据的切分,通过深入理解各种切分策略来设计和优化我们的系统.这部分中我们还用到了数据库中间件和客户端组件来进行数据的切分,让广大网友能够对数据的切分从理论到实战都会有一个质的飞跃.

亿级Web系统搭建：单机到分布式集群

当一个Web系统从日访问量10万逐步增长到1000万,甚至超过1亿的过程中,Web系统承受的压力会越来越大,在这个过程中,我们会遇到很多的问题.为了解决这些性能压力带来问题,我们需要在Web系统架构层面搭建多个层次的缓存机制.在不同的压力阶段,我们会遇到不同的问题,通过搭建不同的服务和架构来解决. Web负载均衡 Web负载均衡(Load Balancing),简单地说就是给我们的服务器集群分配"工作任务",而采用恰当的分配方式,对于保护处于后端的Web服务器来说,非常重要. 负载均衡

很不错的文章---【问底】徐汉彬：亿级Web系统搭建——单机到分布式集群

原文:很不错的文章---[问底]徐汉彬:亿级Web系统搭建--单机到分布式集群 [导读]徐汉彬曾在阿里巴巴和腾讯从事4年多的技术研发工作,负责过日请求量过亿的Web系统升级与重构,目前在小满科技创业,从事SaaS服务技术建设.  大规模流量的网站架构,从来都是慢慢"成长"而来.而这个过程中,会遇到很多问题,在不断解决问题的过程中,Web系统变得越来越大.并且,新的挑战又往往出现在旧的解决方案之上.希望这篇文章能够为技术人员提供一定的参考和帮助.  以下为原文 当一个Web系统从日访问量

activemq 集群-activemq使用kahadb持久化搭建分布式集群后发下消息处理速度明显不如一台机器的性能

问题描述 activemq使用kahadb持久化搭建分布式集群后发下消息处理速度明显不如一台机器的性能 最近在linux下测试ActiveMQ5.11 ,使用两台电脑进行分布式布控,测试处理消息性能时,发现对消息的处理速度远不如一台机器工作处理速度,搭建分布式集群后哪里会影响其速度吗? 解决方案 有谁使用过的?教教怎么配置会提高些消息处理速度 解决方案二: MySQL Master Slave 数据同步,集群mysql master slave projectActiveMq master/sl

MySQL的集群配置的基本命令使用及一次操作过程实录_Mysql

1． 先了解一下你是否应该用MySQL集群. 减少数据中心结点压力和大数据量处理,采用把MySQL分布,一个或多个application对应一个MySQL数据库.把几个MySQL数据库公用的数据做出共享数据,例如购物车,用户对象等等,存在数据结点里面.其他不共享的数据还维持在各自分布的MySQL数据库本身中. 2． 集群MySQL中名称概念.(如上图) 1)Sql结点(SQL node--上图对应为MySQLd):分布式数据库.包括自身数据和查询中心结点数据. 2)数据结点(Data node