近段時間部署和測試了一個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. 真正好的架構設計，不僅僅是軟件的設計，而是整個軟件，硬件，業務相互結合和配合的設計。