搬掉绊脚石,将内容不断靠近用户!
keep it simple, stupid!
关键词:CPU时间占比、当前执行的SQL语句、执行时间过长的方法、代码屏蔽
1. 性能分析本质
寻找系统的性能瓶颈(木桶理论/短板效应),并处理系统的性能瓶颈
2. 性能分析主要指标
负载、响应和服务器CPU\MEM\IO等的使用率
3. 性能分析主要工具
LoadRunner、VisualVM、MySql 客户端工具(或类似工具)和Linux命令(或监控工具)
4. 性能分析及处理思路
4.1. 代码
避免代码里面的循环数据库查询(梳理业务,基本都可以实现为非循环方式)
避免代码里面的循环数据库更新处理(插入、更新等),尽量采用批量方式
避免生产新的、耗时和耗内存的对象,即消耗内存,又消耗CPU
比如获取方法调用栈轨迹,有人采用new Throwable().getStackTrace() 方式来获取,就比较有问题了,该对象的生成相对来说很耗资源,测试某个长事务过程中,CPU占比达整个的4%,实际上可以采用Thread.currentThrread.getStackTrace() 来处理该需求
使用private、final和static方法,即使代码结构合理,也能运行更有效率
采用必要的缓存(主要针对不易变化的,非实时性要求的数据,比如字典表,排名等)
4.2. 业务
业务是否可以简化?
简化之后是不是可以去掉不必要的代码?是不是可以实现更简单,逻辑更清晰?
对代码的调整很多其实也是对业务的精炼!
4.3. SQL(MySql)
1、开启慢查询(捕获慢查询SQL语句)
在my.cnf文件[mysqld]后面,添加如下:
slow_query_log
slow_query_log_file=/export/servers/mysql/mysql_slow.log
long_query_time=0.1
2、show full processlist
压力测试期间,捕获当前执行SQL语句,重点关注state列和info列
state列正常情况下应该都是空(应为执行都很快),但假如你看到了sending data, statistics等,很不幸(如果很多),这往往伴随着CPU时间占比很高,这个时候往往表明你需要调整该SQL语句,或者相关调用代码或者其余处理措施(当然,有时候是负载实在太高了!)
Info列则是当前执行的SQL语句,show full processlist中的full的作用就是你可以查看完整的SQL语句
3、解释相关SQL语句
Explain/相关MySql客户端工具
4.4. 配置
1、数据库服务器配置,重点关注以下配置(具体参数配置标准请google):
max_connections=1000
key_buffer_size = 16M :主要针对MyISAM存储引擎
table_open_cache=10000
innodb_buffer_pool_size = 10g :主要针对InnoDB存储引擎
query_cache_size=32m
可通过SHOW GLOBAL STATUS LIKE 'qcache%';查看查询缓存的使用情况,单交易压力
测试表征意义不大,要在混合场景稳定性测试等环境中观察
2、应用服务器配置(内存、线程池)
请参考TOMCAT6性能优化文档 http://shuhucy.iteye.com/admin/blogs/1709296
3、数据库连接池
根据实际需要配置(一般和线程池数目相当)
5. 瓶颈定位方式
5.1. 基于单交易压力测试
单交易压力测试等,最好排除相关影响因数,比如你要测试一个添加,但你需要先进入一个列表,才能处理添加,这个时候,你可能需要在脚本里面将这个列表的代码去掉,避免该处代码对添加事务的影响,使添加事务更纯净,更易于定位问题
5.2. 监控相关服务器资源使用情况
重点关注CPU时间占比,内存等使用情况,可通过top、vmstat等命令监控
比如此次性能分析过程中数据库库服务器CPU占比很容易很高(往往解决了一个又来了另一个),这时可以通过数据库客户端工具摘取当前执行SQL语句,并通过工具分析(或者自己explain),查看索引使用情况,如果没有索引或不存在有效索引,则添加相关索引,并且注意调用该语句的代码是否是循环处理的,如果是循环处理,请提炼至循环外层
5.3. 通过VisualVM进行CPU、内存使用采样及垃圾回收监控
比如通过CPU采用,分析相关方法执行CPU占比,定位执行时间过长的方法,进行相关优化。
5.4. 通过代码屏蔽方式定位
可以通过屏蔽代码的方式以定位瓶颈点或者确认瓶颈点
注意事项:
1、避免压力测试脚本问题及其与环境、配置问题
比如压力测试脚本不纯净,服务器对某一IP过多访问存在限制、线程池配置太小,数据库连接池配置太小,文件打开数超过系统限制等
2、避免问题定位错误
某次压测发现CPU占比很高(90%),进行过一定的分析,发现数据库服务器网络负载在
200多M(浏览器压测情况下没有启用缓存,页面图片量比较大),开始认为是网络带宽问题,但实际上,把页面的代码都注释掉(基本空页面),带宽很低,但CPU并没有降低,最后通过添加MySql查询缓存解决该问题!
某次压测发现数据库服务器A的CPU占比很低,但就是TPS很低(正常情况下,数据库没有压力,适当的迸发环境下TPS一般应比较高),用工具连接数据库服务器,执行show processlist 发现state基本为空,很正常,查询相关配置参数,也没做更改。之后想起来还有另外一台数据库服务器B,会不会是B服务器导致的了?在B服务器上top一看,CPU占比90%,show full processlsit数据库一看,state很多sending data,info列重复很多一个查询语句,explain该语句,发现该语句缺少相应的索引!添加相关索引即TPS恢复正常
keep it simple, stupid!
关键词:CPU时间占比、当前执行的SQL语句、执行时间过长的方法、代码屏蔽
1. 性能分析本质
寻找系统的性能瓶颈(木桶理论/短板效应),并处理系统的性能瓶颈
2. 性能分析主要指标
负载、响应和服务器CPU\MEM\IO等的使用率
3. 性能分析主要工具
LoadRunner、VisualVM、MySql 客户端工具(或类似工具)和Linux命令(或监控工具)
4. 性能分析及处理思路
4.1. 代码
避免代码里面的循环数据库查询(梳理业务,基本都可以实现为非循环方式)
避免代码里面的循环数据库更新处理(插入、更新等),尽量采用批量方式
避免生产新的、耗时和耗内存的对象,即消耗内存,又消耗CPU
比如获取方法调用栈轨迹,有人采用new Throwable().getStackTrace() 方式来获取,就比较有问题了,该对象的生成相对来说很耗资源,测试某个长事务过程中,CPU占比达整个的4%,实际上可以采用Thread.currentThrread.getStackTrace() 来处理该需求
使用private、final和static方法,即使代码结构合理,也能运行更有效率
采用必要的缓存(主要针对不易变化的,非实时性要求的数据,比如字典表,排名等)
4.2. 业务
业务是否可以简化?
简化之后是不是可以去掉不必要的代码?是不是可以实现更简单,逻辑更清晰?
对代码的调整很多其实也是对业务的精炼!
4.3. SQL(MySql)
1、开启慢查询(捕获慢查询SQL语句)
在my.cnf文件[mysqld]后面,添加如下:
slow_query_log
slow_query_log_file=/export/servers/mysql/mysql_slow.log
long_query_time=0.1
2、show full processlist
压力测试期间,捕获当前执行SQL语句,重点关注state列和info列
Id | User | Host | db | Command Time | State | Info |
318236 | root | … | db_name | 7085 | sending data | SELECT … |
state列正常情况下应该都是空(应为执行都很快),但假如你看到了sending data, statistics等,很不幸(如果很多),这往往伴随着CPU时间占比很高,这个时候往往表明你需要调整该SQL语句,或者相关调用代码或者其余处理措施(当然,有时候是负载实在太高了!)
Info列则是当前执行的SQL语句,show full processlist中的full的作用就是你可以查看完整的SQL语句
3、解释相关SQL语句
Explain/相关MySql客户端工具
4.4. 配置
1、数据库服务器配置,重点关注以下配置(具体参数配置标准请google):
max_connections=1000
key_buffer_size = 16M :主要针对MyISAM存储引擎
table_open_cache=10000
innodb_buffer_pool_size = 10g :主要针对InnoDB存储引擎
query_cache_size=32m
可通过SHOW GLOBAL STATUS LIKE 'qcache%';查看查询缓存的使用情况,单交易压力
测试表征意义不大,要在混合场景稳定性测试等环境中观察
2、应用服务器配置(内存、线程池)
请参考TOMCAT6性能优化文档 http://shuhucy.iteye.com/admin/blogs/1709296
3、数据库连接池
根据实际需要配置(一般和线程池数目相当)
5. 瓶颈定位方式
5.1. 基于单交易压力测试
单交易压力测试等,最好排除相关影响因数,比如你要测试一个添加,但你需要先进入一个列表,才能处理添加,这个时候,你可能需要在脚本里面将这个列表的代码去掉,避免该处代码对添加事务的影响,使添加事务更纯净,更易于定位问题
5.2. 监控相关服务器资源使用情况
重点关注CPU时间占比,内存等使用情况,可通过top、vmstat等命令监控
比如此次性能分析过程中数据库库服务器CPU占比很容易很高(往往解决了一个又来了另一个),这时可以通过数据库客户端工具摘取当前执行SQL语句,并通过工具分析(或者自己explain),查看索引使用情况,如果没有索引或不存在有效索引,则添加相关索引,并且注意调用该语句的代码是否是循环处理的,如果是循环处理,请提炼至循环外层
5.3. 通过VisualVM进行CPU、内存使用采样及垃圾回收监控
比如通过CPU采用,分析相关方法执行CPU占比,定位执行时间过长的方法,进行相关优化。
![点击查看原始大小图片](http://dl.iteye.com/upload/attachment/0078/8287/e39e7017-6de0-3e87-aebf-2d9c583f1efb.png)
5.4. 通过代码屏蔽方式定位
可以通过屏蔽代码的方式以定位瓶颈点或者确认瓶颈点
注意事项:
1、避免压力测试脚本问题及其与环境、配置问题
比如压力测试脚本不纯净,服务器对某一IP过多访问存在限制、线程池配置太小,数据库连接池配置太小,文件打开数超过系统限制等
2、避免问题定位错误
某次压测发现CPU占比很高(90%),进行过一定的分析,发现数据库服务器网络负载在
200多M(浏览器压测情况下没有启用缓存,页面图片量比较大),开始认为是网络带宽问题,但实际上,把页面的代码都注释掉(基本空页面),带宽很低,但CPU并没有降低,最后通过添加MySql查询缓存解决该问题!
某次压测发现数据库服务器A的CPU占比很低,但就是TPS很低(正常情况下,数据库没有压力,适当的迸发环境下TPS一般应比较高),用工具连接数据库服务器,执行show processlist 发现state基本为空,很正常,查询相关配置参数,也没做更改。之后想起来还有另外一台数据库服务器B,会不会是B服务器导致的了?在B服务器上top一看,CPU占比90%,show full processlsit数据库一看,state很多sending data,info列重复很多一个查询语句,explain该语句,发现该语句缺少相应的索引!添加相关索引即TPS恢复正常