记一次数据库性能问题解决过程

       话说工欲善其事必先利其器，这里最近发现一个造神器的公司，http://www.oneapm.com/。

先介绍下我的服务器，作为创业公司没有那么多￥去买实体服务器，托管，运维，安全防护都是一个大问题。所有当时还好有点经验，理智的给老板介绍了购买阿里云服务器。一下就搞定了这些所有的烦恼(当时是这么认为的)，并且阿里云提供了服务器状态监控，服务监控。但是这些仍然只是满足了日常监控和运维的需求。一旦遇到详细点的性能监控的需求就嗝屁了。

    本来是在找服务器运行状态监控软件的时候，无意在网上发现了ONEAPM，注册了一个账号后后来没有怎么使用，他们当时还没有推出我需求的服务器监控的软件，后来他们出了新版本后积极联系我，本以为他们和阿里云的东西差不多，后来在他们客服妹妹的悉心调教（我真没有吃过她豆腐）下装了一个试了试，不用不知道一用吓一跳，这个东西比阿里云的监控的详细多了。

上图有图才有真相

阿里云的监控

OneAPM的监控

优势一下就出来了有木有，阿里云的监控只提供了总体的一个数据监控，而OneAPM提供了非常详细的占用信息。虽然Linux下也可以用命令看，但是我是比较懒的人（尼玛事情多的爆啊，能用一分钟解决的问题绝不想花两分钟）

话说他给我解决了什么问题吧，由于最近业务量暴涨，突然多了非常多的写库操作。导致数据库服务器的CPU暴涨一直都是100%，尼玛这东西当时导致监控的服务器和服务各种报警，直接吓尿了，到阿里云监控上只看到了CPU占用了百分之但是那个程序占用的尼玛完全木有任何信息啊全靠自己去慢慢琢磨，老板的要求是服务器报警不能超过30分钟必须解决时间紧迫。当时登陆了ONEapm后台看采集回来的数据，清清楚楚的看到是MySQL数据库。几乎吞噬了所有数据库服务器的CPU这样下去不导致数据库服务器宕机才怪。

接下来用OneAPM的应用监控，查看服务对数据库的读写操作按次数进行排序，基本上是9:1的读写比例。

还好哥当时留了一手有先见之明，在另外的服务器上准备了一个从备份库，并且配置**oeba的读写分离，因为PHP接口用amoeba会报错，所以都是直连的主库。但是分析了最近的写库业务都是来源于Java服务，赶紧把Java的服务都切到**oeba服务的数据库中间件上，做了读写分离后CPU分分钟降到了50%的正常水平，从早上8点报警到中午十二点，基本解决了由大量数据写入数据库导致的CPU暴涨引起的一次性能问题。

这里只是简单记录了一次性能解决的过程和工具，后面继续给大家完善   

《nginx做负载均衡tomcat》

《NFS服务做异地图片存储》

《nginx PHP服务集群》

《amoeba做MYsql读写分离集群》

《构建高可用的后台服务架构》