北大青鸟华美校JAVA程序性能分析及调优浅析.docx

JAVA程序性能分析及调优浅析 搬掉绊脚石，将内容不断靠近用户！ keep it simple, stupid！ 关键词：CPU时间占比、当前执行的SQL语句、执行时间过长的方法、代码屏蔽 1.性能分析本质 寻找系统的性能瓶颈（木桶理论/短板效应），并处理系统的性能瓶颈 2.性能分析主要指标 负载、响应和服务器CPUMEMIO等的使用率 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列 IdUserHostdbCommandTimeStateInfo 318236root…ads_online7085SleepSELECT … 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性能优化文档 3、数据库连接池 根据实际需要配置（一般和线程池数目相当） 5.瓶颈定位方式 5.1. 基于单交易压力测试 单交易压力测试等，最好排除相关影响因数，比如你要测试一个添加，但你需要先进入一个列表，才能处理添加，这个时候，你可能需要在脚本里面将这个列表的代码去掉，避免该处代码对添加事务的影响，使添加事务更纯净，更易于定位问题 5.2. 监控相关服务器资源使用情况 重点关注CPU时间占比，内存等使用情况，可通过top、vmstat等命令监控 比如此次性能分析过程中数据库库服务器CPU占比很容易很高（往往解决了一个又来了另一个），这时可以通过数据库客户端工具摘取当前执行SQL语句，并通过工具分析（或者自己explain），查看索引使用情况，如果没有索引或不存在有效索引，则添加相关索引，并且注意调用该语句的代码是否是循环处理的，如果是循环处理，请提炼至循环外层 5.3. 通过VisualVM进行CPU、内存使用采样及垃圾回收监控 比如通过CPU采用，分析相关方法执行CPU占比，定位执行时间过长的方