由一次mycat+mysql水平拆分集群问题引发的思考


近段时间部署和测试了一个mycat+4 Percona+tokudb的水平拆分集群,前段应用是将一类奖状数据不断地写入到这个库中,只有insert操作,前几天运行状态还比较好。


从昨天开始,由于业务量突然增加了一些,磁盘IO负载变得很高,而且仔细分析之后,发现磁盘读的性能远远高于磁盘写的性能,这完全是有问题的。因为insert操作肯定主要是写操作,而且写都是顺序写,读操作应该不会太大。



经过对mycat和mysql多方面的查看,都难以解释的通,不太确定问题的方向和原因。后来与同事沟通,又回到了系统的起点:
先确认cpu,然后确认内存,结果发现内存中cache已经用满,开始用了大量的swap分区,由此为出发点,确认思路如下:
由一次mycat+mysql水平拆分集群问题引发的思考_第1张图片


于是再次与同事沟通:
应该就是内存不足,才需要读取swap
top里看一下各个mysql实例占用的内存大小
就你发的这些图来看,是有查询操作。
insert操作因为要维护索引,应该会有跌宕读,但是否会以查询的形式体现我就不确认了
先要确认内存争用是mysql触发,还是其它进程
对于数据库服务器,swap最好不要使用
有些极端的场景,会把swap设置成0,就是为了避免用磁盘上的文件交换
这个会对性能造成很大影响的
你现在可以需要先调小innodb的内存参数,然后将会话相关的参数也都逐个往小了调
先把内存争用降下来


于是根据整个系统的物理内存为48g,各个实例的内存最多为50%,现在四个实例,每个实例分配6g内存,由于tokudb采用的是 非directio的模式 “tokudb_directio = 0”,所以讲各个实例的内存设置为4g,让更多的内存用于系统的cache,使系统读操作都使用系统cache,不使用swap分区,保证内存命中率,减少磁盘IO操作。


这样修改了之后,系统的资源变为:

通过iostat看,写请求也大于读请求了,insert操作的状态正常了:
由一次mycat+mysql水平拆分集群问题引发的思考_第2张图片


通过这个问题的处理,我有几点感悟:

1. 对于架构设计和性能方面的问题,还是应该回到最初:
系统资源监控:
cpu
内存
磁盘
网络
总体


对应的stat命令:
vmstat
iostat    iotop
mpstat
ifstat
dstat

深刻理解这些基本的系统资源,原理,查看方法,才能认识清楚性能和架构问题,并找到问题解决的突破口; 


2. 对于水平拆分来说:
聊天记录:
从这个问题的处理也感觉到,硬件资源不足,只有一个机器,只从软件mycat+mysql这种方式进行水平拆分,资源消耗和争用的问题还是比较大的
水平拆分不能只从mycat,mysql软件上水平拆,硬件系统资源也要充分,或者够用才行
不然所有的事务都在一台物理机上,资源争用和问题,还是会很多的;
尤其是面对业务负载压力和变化的时候,即使mycat分片很合理,cpu,内存,磁盘IO这些资源不足,整体性能还是会有很多问题的

光mycat 逻辑上分片还不行
要合理利用硬件 特别是io 资源
防止硬件热点
一个磁盘 分太多的分片是没用的 io 竞争
合理利用 网络io 磁盘 io 内存 cpu
比如rain0 根rain10 几块 盘 每个分片在哪个盘上 这才是真正dba 需要规划的
dba 真正的是规划好这些底层的资源优化


3. 真正好的架构设计,不仅仅是软件的设计,而是整个软件,硬件,业务相互结合和配合的设计。







你可能感兴趣的:(架构设计)