近段时间部署和测试了一个mycat+4 Percona+tokudb的水平拆分集群，前段应用是将一类奖状数据不断地写入到这个库中，只有insert操作，前几天运行状态还比较好。
从昨天开始，由于业务量突然增加了一些，磁盘IO负载变得很高，而且仔细分析之后，发现磁盘读的性能远远高于磁盘写的性能，这完全是有问题的。因为insert操作肯定主要是写操作，而且写都是顺序写，读操作应该不会太大。
经过对mycat和mysql多方面的查看，都难以解释的通，不太确定问题的方向和原因。后来与同事沟通，又回到了系统的起点：
先确认cpu，然后确认内存，结果发现内存中cache已经用满，开始用了大量的swap分区，由此为出发点，确认思路如下：
于是再次与同事沟通：
应该就是内存不足，才需要读取swap
top里看一下各个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命令：
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. 真正好的架构设计，不仅仅是软件的设计，而是整个软件，硬件，业务相互结合和配合的设计。