mysql数据库部分性能问题分析及优化
2016-07-09 14:35
453 查看
好久没更新东西,都更新在自己的本地word中了,比较忙碌,最近在python+selenium搞自动化方面的东西,后续有开发个自己的监控系统的想法(python搞比较好,虽然python掌握得很low,这个可以学,对!),python搞起来,有多余的精力再去搞鼓那些,先记录下公司刚做的一个项目的部分性能问题一些分析思路:
目前在做公司一个项目性能测试xxxxx,后端主要涉及的接口有N多个,在性能压测中出现很多性能问题,比如JDBC连接池问题、数据库瘫痪、配置问题,接口调用问题,sql问题,数据库索引问题,服务器cpu问题等,其他一些应用还需要涉及到JVM方面等。
部分性能问题已做优化:
1.目前出现的问题jdbc连接池和数据库配置问题已做相应的调整。
2.其中一个表中已添加合适的索引,从新压测后,这些问题都得到改善。
调整优化后重新压测稳定性和速度都得到很大提高,其中监测到两个sql存在性能问题,还在进一步确认中。
现在主要问题集中在:10并发压测中,整个app端界面的所有操作响应大于10s,且长时间白屏,无法正常响应。
分析:压测采用jmeter压测后端所有调用的接口,10并发混合综合压测接口,jmeter所有接口平均响应时间大于10s,tps、吞吐量较低,手动访问APP端界面的所有操作响应大于10s,且长时间白屏,无法正常响应。
后端所有服务器单独分开隔离分析,经过监控分析得出:排除应用服务器和其他一些服务器的问题(不同应用可能会涉及到连接redis,mongodb,调用其他服务器的服务等),问题集中在mysql服务器和mysql数据本身性能上。数据库服务器最直接的反应是内存方面没问题,user态的cpu利用率直接大于95%,10并发量,并不算高,cpu利用却如此高,这cpu并不算垃圾,就算垃圾也算是垃圾中的战斗机。部分人说更换更好的服务器cpu不就好了,哎,当时就想,没解决本质问题,在牛x的cpu也一样受不了,又不是很大并发下导致cpu利用率高。于是把所有接口业务拆分开,对不同接口调用进行监控分析,以及在不同数据库数据量都记录下来服务器端性能,定位到最终导致cpu瓶颈的本质问才能解决问题,确定这思路,最后范围缩小到其中一个接口业务问题,这个接口每次操作都会去写入更新两个表的数据,就经验分析,这个接口对两个表同时做数据处理,在这样的数据量下数据库方面也不会有问题,此时两张表的数据量分别为60万和200万左右,又不大。
目前定位到10并发下app端所有操作都大于10s的源头,先记录下来这些,下一步需要开发配合拉出这块业务逻辑代码、分析这代码块处理的逻辑,并且针对这块代码的执行去监控数据库的执行情况,最终定能解决问题。下周一具体分析更新。
原因及优化:
①、导致cpu利用率高的原因是每次绑定邮箱的时候程序会去判断user_info表中是否存在已绑定的邮箱号,而此时user_info表中存在60万数据,邮箱列未加索引,全表遍历数据,判断完满足条件后往user_info中插入邮箱信息(此时user_task表200万数据),并向user_task表更新三条记录。需要在user_info表的email检索列上面添加索引
②、show full processlist查看到大量sql解析所有列的语句,查看代码,程序中使用select * from user_info where email = {email},该语句把所有列解析出来,需要耗费大量IO,该业务只判断user_info里面是否存在该邮箱就可以,所以只需要select email from user_info where email = {email},避免过多解析增加磁盘IO开销。
优化前后数据库cpu利用率监控对比如图:
优化前:
优化后:
经过优化后,10并发下压测“绑定邮箱接口”数据库cpu使用率由之前的99%下降到5%左右。
目前在做公司一个项目性能测试xxxxx,后端主要涉及的接口有N多个,在性能压测中出现很多性能问题,比如JDBC连接池问题、数据库瘫痪、配置问题,接口调用问题,sql问题,数据库索引问题,服务器cpu问题等,其他一些应用还需要涉及到JVM方面等。
部分性能问题已做优化:
1.目前出现的问题jdbc连接池和数据库配置问题已做相应的调整。
2.其中一个表中已添加合适的索引,从新压测后,这些问题都得到改善。
调整优化后重新压测稳定性和速度都得到很大提高,其中监测到两个sql存在性能问题,还在进一步确认中。
现在主要问题集中在:10并发压测中,整个app端界面的所有操作响应大于10s,且长时间白屏,无法正常响应。
分析:压测采用jmeter压测后端所有调用的接口,10并发混合综合压测接口,jmeter所有接口平均响应时间大于10s,tps、吞吐量较低,手动访问APP端界面的所有操作响应大于10s,且长时间白屏,无法正常响应。
后端所有服务器单独分开隔离分析,经过监控分析得出:排除应用服务器和其他一些服务器的问题(不同应用可能会涉及到连接redis,mongodb,调用其他服务器的服务等),问题集中在mysql服务器和mysql数据本身性能上。数据库服务器最直接的反应是内存方面没问题,user态的cpu利用率直接大于95%,10并发量,并不算高,cpu利用却如此高,这cpu并不算垃圾,就算垃圾也算是垃圾中的战斗机。部分人说更换更好的服务器cpu不就好了,哎,当时就想,没解决本质问题,在牛x的cpu也一样受不了,又不是很大并发下导致cpu利用率高。于是把所有接口业务拆分开,对不同接口调用进行监控分析,以及在不同数据库数据量都记录下来服务器端性能,定位到最终导致cpu瓶颈的本质问才能解决问题,确定这思路,最后范围缩小到其中一个接口业务问题,这个接口每次操作都会去写入更新两个表的数据,就经验分析,这个接口对两个表同时做数据处理,在这样的数据量下数据库方面也不会有问题,此时两张表的数据量分别为60万和200万左右,又不大。
目前定位到10并发下app端所有操作都大于10s的源头,先记录下来这些,下一步需要开发配合拉出这块业务逻辑代码、分析这代码块处理的逻辑,并且针对这块代码的执行去监控数据库的执行情况,最终定能解决问题。下周一具体分析更新。
原因及优化:
①、导致cpu利用率高的原因是每次绑定邮箱的时候程序会去判断user_info表中是否存在已绑定的邮箱号,而此时user_info表中存在60万数据,邮箱列未加索引,全表遍历数据,判断完满足条件后往user_info中插入邮箱信息(此时user_task表200万数据),并向user_task表更新三条记录。需要在user_info表的email检索列上面添加索引
②、show full processlist查看到大量sql解析所有列的语句,查看代码,程序中使用select * from user_info where email = {email},该语句把所有列解析出来,需要耗费大量IO,该业务只判断user_info里面是否存在该邮箱就可以,所以只需要select email from user_info where email = {email},避免过多解析增加磁盘IO开销。
优化前后数据库cpu利用率监控对比如图:
优化前:
优化后:
经过优化后,10并发下压测“绑定邮箱接口”数据库cpu使用率由之前的99%下降到5%左右。
相关文章推荐
- 项目中遇到的mysql group by having
- Mysql服务启动遇到“某些服务启动后自动停止”的问题的解决方案
- MySQL配置文件my.cnf参数优化和中文详解
- php示例代码之使用mysqli对象
- php示例代码之使用MySQLi接口
- php示例代码之使用mysql_fetch_object函数
- php示例代码使用mysql_fetch_assoc函数
- php示例代码之使用list函数和mysql_fetch_row函数
- Mysql Binlog三种格式介绍及分析
- php示例代码之 使用PHP的MySQL标准函数
- WordPress忘记账户密码最简单的解决方案
- mysql无法远程连接到数据库解决方法
- MySQL事务处理实现方法步骤
- Mysql windows版本的安装
- 2003 - Can connect to MySQL server on localhost (10038)mysql 读取描述文件失败 错误代码:2【亲测可用】
- mysql主从同步延迟优化大全
- 解决Mysql数据库插入数据出现问号(?)的解决办法
- 操作数据表中的记录(增删改查)
- mysql安装图解 mysql图文安装教程(详细说明)
- mysql的备份与恢复