近段时间部署和测试了一个mycat+4 Percona+tokudb的水平拆分集群,前段应用是将一类奖状数据不断地写入到这个库中,只有insert操作,前几天运行状态还比较好。
从昨天开始,由于业务量突然增加了一些,磁盘IO负载变得很高,而且仔细分析之后,发现磁盘读的性能远远高于磁盘写的性能,这完全是有问题的。因为insert操作肯定主要是写操作,而且写都是顺序写,读操作应该不会太大。
经过对mycat和mysql多方面的查看,都难以解释的通,不太确定问题的方向和原因。后来与同事沟通,又回到了系统的起点:先确认cpu,然后确认内存,结果发现内存中cache已经用满,开始用了大量的swap分区,由此为出发点,确认思路如下:![]()
于是再次与同事沟通:应该就是内存不足,才需要读取swaptop里看一下各个mysql实例占用的内存大小就你发的这些图来看,是有查询操作。insert操作因为要维护索引,应该会有跌宕读,但是否会以查询的形式体现我就不确认了先要确认内存争用是mysql触发,还是其它进程对于数据库服务器,swap最好不要使用有些极端的场景,会把swap设置成0,就是为了避免用磁盘上的文件交换这个会对性能造成很大影响的你现在可以需要先调小innodb的内存参数,然后将会话相关的参数也都逐个往小了调先把内存争用降下来
于是根据整个系统的物理内存为48g,各个实例的内存最多为50%,现在四个实例,每个实例分配6g内存,由于tokudb采用的是 非directio的模式 “tokudb_directio = 0”,所以讲各个实例的内存设置为4g,让更多的内存用于系统的cache,使系统读操作都使用系统cache,不使用swap分区,保证内存命中率,减少磁盘IO操作。
这样修改了之后,系统的资源变为:
通过iostat看,写请求也大于读请求了,insert操作的状态正常了:
![]()
通过这个问题的处理,我有几点感悟:
1. 对于架构设计和性能方面的问题,还是应该回到最初:系统资源监控:cpu内存磁盘网络总体
对应的stat命令:vmstatiostat iotopmpstatifstatdstat
深刻理解这些基本的系统资源,原理,查看方法,才能认识清楚性能和架构问题,并找到问题解决的突破口;
2. 对于水平拆分来说:聊天记录:从这个问题的处理也感觉到,硬件资源不足,只有一个机器,只从软件mycat+mysql这种方式进行水平拆分,资源消耗和争用的问题还是比较大的水平拆分不能只从mycat,mysql软件上水平拆,硬件系统资源也要充分,或者够用才行不然所有的事务都在一台物理机上,资源争用和问题,还是会很多的;尤其是面对业务负载压力和变化的时候,即使mycat分片很合理,cpu,内存,磁盘IO这些资源不足,整体性能还是会有很多问题的
光mycat 逻辑上分片还不行要合理利用硬件 特别是io 资源防止硬件热点一个磁盘 分太多的分片是没用的 io 竞争合理利用 网络io 磁盘 io 内存 cpu比如rain0 根rain10 几块 盘 每个分片在哪个盘上 这才是真正dba 需要规划的dba 真正的是规划好这些底层的资源优化
3. 真正好的架构设计,不仅仅是软件的设计,而是整个软件,硬件,业务相互结合和配合的设计。
由一次mycat+mysql水平拆分集群问题引发的思考
最新推荐文章于 2024-07-05 17:17:32 发布