MySql单表最大8000W+ 之数据库遇瓶颈记

2018-06-22 07:50:15来源:未知 阅读 ()

新老客户大回馈,云服务器低至5折

前言

昨晚救火到两三点,早上七点多醒来,朦胧中醒来发现电脑还开着,赶紧爬起来看昨晚执行的SQL命令结果。由于昨晚升级了阿里云的RDS,等了将近两个小时 还在 升降级中,早上阿里云那边回复升级过程中出现异常,正在加紧处理。。。有点蛋疼

 

项目介绍

这个项目主要分为WEB、WEB-Manager、WEB-API、APP(ANDROID、IOS) 。

开发语言主要是ASP.NET 

数据库MySql

架构采用了ASP.NET +EF+ORM   Unity依赖注入 采用了DDD的部分实践 

ORM使用的是AutoMapper

使用了Redis缓存

Log4net记录文件日志,刚开始使用Mongodb记录日志,用了一段时候后取消了。

WEB端使用了angularjs    

API层通过JSON数据与APP进行交互,用户状态通过access_token进行传递

数据库层目前是基于仓储(Repositor)模式实现的

刚开始项目急于上线多数采用Linq +lambda 的查询方式,在实践过程中发现变态的业务调整和快速的请求响应,将其复杂的查询改成了原生SQL,通过Context.DataBase.SqlQuery  执行

 

其他的技术就不一一介绍了

目前访问量较大的是APP端, 最大并发 1300+

主要是API的压力比较大,日均 100W+ 请求,API 目前 部署在Windwos server 2012上,  接口在50个以上

数据库使用的是阿里云的单机MySql  RDS 5.6 版本,10盒12G,连接数2000,iops 6000  

目前 单表最大是8000W+数据。物理文件300G,APIlog日均100W+,API与业务系统完全独立,除了DBLog日志还有Log4g.net生成的文件日志。

目前采用的是阿里云的负载,一主一从  购买的阿里云负载      两台应用均为 8盒16G ,10M带宽 ,资源文件上了CDN。

主的上面部署了WEB端和WEB管理后台,从的上面只有API。

数据库遇瓶颈

        最近用户量突破10+以上,最大并发1300+  从前天晚上开始数据库CPU居高不下,一时达到100%临界点,导致很多SQL命令执行发生错误,链接拒绝。阿里云的报警短信也随之而来,随即我停掉了IIS应用,因为不停止应用MySql数据库很难复苏,大概过了5分钟之后数据库恢复正常,然后再开启IIS应用。蛋疼的是阿里云的负载健康检查也提示异常,但有点不解的是健康状态显示异常,请求仍然在继续分发,很是不解。立马我将IIS 应用程序池资源回收,停止然后再重启,这里给个提示  重启IIS应用程序池的时候最好先停止掉IIS应用,然后再重启IIS应用程序池,不然访问量大的情况下很难起起来。过了几分钟之后负载上的健康检查显示正常。

       上阿里云后来看了下各个监控指标,显示流量从前一个小时开始 突然猛增,我以为是有攻击,但跟踪了几个连接发现是正常请求,但360的防御助手显示确实有几个攻击,但那几个请求根本不足以拉跨数据库,大概也就几十个请求,   几个简单的  XSS攻击 这里贴下:攻击的数量不是太多,但主要攻击的内容和参数就这个几种类型

url/'%22/%3E%3C/script%3E%3Cscript%3Ealert()%3C/script%3E
url/'%22+onmouseover=alert()+d='%22

url/matrix_callback.php    

url/index.php?option=com_fields&view=fields&layout=modal&list%5Bfullordering%5D=updatexml(0x3a,concat(1,md5(233)),1)

后来发现是数据库遇到危机了,CPU几度达到了100%,活跃连接数和非活跃连接数都比平时都要高很多。目前数据库中有一张最大的表超8000W条数据,超300W以上的也有十几张,是查询拖垮了数据库,平时开发的时候我们都是要求查询类的SQL要求0.03秒之内完成。但涉及到这几张大表的查询我们设定到0.5秒之内返回。今天肯定是查过0.5秒了,

我查了下阿里云控制台的慢SQL日志,眼下系统运行还稍微正常,就拿那些慢SQL 一个一个的优化,不能立马发版,也就是不能改写SQL代码,只能从索引上进行优化了。就这样把慢SQL逐一过了一遍,大约有20多个  超2秒执行的,最慢的达到了10秒,最大的解析行数达到了10W行以上,哎 应该是下面的兄弟写sql不严谨,否则不会出现解析行数超10W+的,但兄弟挖的坑 我哭着也要去填。就这样用explain 调整索引的方式逐一过了一遍,之前通过表空间已经做过一次优化了。

到昨晚又到了高并发的时候,数据库又报警了,还好只是报警没有给我crash掉。与客户那边沟通下来,决定进行数据库扩容。现在扩容到了16盒64G 连接数14000 iops16000。

增加了一个应用几点,现在是一主两从

应该能撑一段时间了

 

接下来需要着手上读写分离, 针对比较大的表进行拆分,代码和数据库继续优化。尽量做到最优。

再下来着手上分布式   因为架构的演变是根据市场营销情况而定,不能走太前更不能走到市场的后面

周末比较累 写的比较简短,有时间再续

 

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:【SignalR学习系列】1. SignalR理论介绍

下一篇:【SignalR学习系列】2. 第一个SignalR程序