<td id="cl7yg"></td>

        <code id="cl7yg"></code>

          天极传媒£º
          天极网
          比特网
          IT专家网
          52PK游戏网
          极客修
          全国分站

          北京上海广州深港南京福建沈阳成都杭州西安长春重庆大庆?#25103;?/a>惠州青岛郑州泰州厦门淄博天津无锡哈尔滨

          产品
          • 网页
          • 产品
          • 图片
          • 报价
          • 下载
          全高清投影机 净化器 4K电视曲面电视小家电滚筒洗衣机
          您现在的位置£º 天极网 > 开发>新闻>解决Java/MySQL性能问题的思路

          解决Java/MySQL性能问题的思路

          博客 2013-07-04 14:49 我要吐槽

          ¡¡¡¡千万别在论坛¡¢群里问£¬我的机器好慢怎么回事£¿我的机器内存泄露了怎么回事£¿

          ¡¡¡¡这类大而空的问题一点意义都没有£¬其实谁都不知道¡£你要做的是用下面的思路¡¢方法¡¢工具去定位它

          ¡¡¡¡解决问题思路

          ¡¡¡¡Java程序问题(运行慢)

          ¡¡¡¡先通过 top 查看整个CPU资?#35789;?#29992;情况;

          ¡¡¡¡通过top -Hp pid查看java进程的每一个线程占用CPU的情况;

          ¡¡¡¡如果有一个线程占用CPU过高£¬有两种可能£º

          ¡¡¡¡没有内存了£¬Java垃圾回收线程不停地运行尝试回收内存£¬但是?#30475;?#26080;法收回£¬确认£º

          ¡¡¡¡jstat -gcutil pid 1s 观察10多秒钟就能发现了£¬看是不是内存使用率接近100%了

          ¡¡¡¡类似于死循环(hash冲突攻击)£¬就是一个线程一直占用一个核的所有CPU资源(其实一个线程总是暂用一个核超过50%的资源都是不太正常的)£¬解决£º

          ¡¡¡¡用我课堂的checkPerf脚本£¬定位这个线程具体执行的任务(能具体到某一行)£¬对应看代码解决¡£

          ¡¡¡¡如果有很多线程£¬每个线程占用的CPU都不多£¬那基本是正常的¡£

          ¡¡¡¡如果?#28010;ø£?/P>

          ¡¡¡¡jstack -l pid 多执行几次£¬统计一下stack中总是在等待哪些锁£¬可以?#36816;øid进?#20449;?#24207;统计(sort uniq grep)

          ¡¡¡¡上面列出来的都是明显的瓶颈£¬最可怕的是哪里都没有明显的瓶颈£¬哪里都要偷一点点资源走£¬这是可以试试JProfiler这样更专业一点的工具£¬同时要配合自己对业务的了解来解决¡£

          ¡¡¡¡Java内存的问题£¬如果有内存泄露(就是执行完fgc/old gc后不能回收的内存不断地增加)£º

          ¡¡¡¡快速解决£ºjmap -histo:live pid 来统计所有对象的个数(String/char/Integer/HashEntry 这样的对象很多很正常£¬主要是盯着你们公司的包名下的那些对象)

          ¡¡¡¡每隔一分钟执行一次上面的命令£¬执行5?#25105;?#19978;£¬看看你们公司报名下的对象数量哪个在一直增加£¬那基本上就是这个对象引起了泄露;

          ¡¡¡¡用课堂上的工具HouseMD来动态监控创建这个对象的地方(一般来?#23707;?#22810;时候创建了这些对象把他们丢到一个HashMap然后就不管了)£¬分析一下有没有释放!

          ¡¡¡¡上面的方法实在没法定位就用: jmap -dump 导出整个内存(耗时间£¬需要很大的内存的机器才能对这个导出文件进行分析£¬会将JVM锁住一?#38382;?#38388;)

          ¡¡¡¡在Eclipse的插件EMA中打开这个文件(2G的物理文件需要4G以上的内存£¬5G以上的需要将近20G的内存来分析了)

          ¡¡¡¡盯着你们公司报名的那些对象£¬看看引用关系£¬谁拿着这些对象没释放(是否是必要的)

          ¡¡¡¡MySQL 数据库的性能问题

          ¡¡¡¡大部分情况下是?#25490;ÌIO的问题(索引没建好¡¢查询太复杂);

          ¡¡¡¡索引问题的话分析慢查询日志£¬explain 他?#21069;?#20010;解决¡£

          ¡¡¡¡偶尔也有数据库CPU不够的情况£¬如果并发高CPU不够很正常£¬如果并发不高£¬那很可能就是group by/order by/random之类的操作严重消耗了数据库的CPU

          ¡¡¡¡mysql -e ¡°show full processlist¡± | grep -v Sleep | sort -rnk6 查看那些SQL语句执行的太长

          ¡¡¡¡拿出这个SQL语句分析他们的执行?#33529;? explain SQL 然后改进;

          ¡¡¡¡分析慢查询日志£¬统计top10性能杀手的语句£¬挨个explain他们£¬然后改进(具体改进办法具体分析£¬这里只谈思路)

          ¡¡¡¡总结一下数据库问题就只有这三招£ºshow full processlist/分析慢查询日志/explain(然后建好联合索引)

          ¡¡¡¡原文链接£ºhttp://database.ctocio.com.cn/66/12654066.shtml

          £¨作者£º看引擎责任编辑£º王玉平£©
          请关注天极网天极新媒体 最酷科技资讯
          扫码赢大奖
          评论
          * 网友发言均非本站立场£¬本站不在评论栏推荐任何网店¡¢经销商£¬谨防上当受骗£¡
          办公软件IT新闻整机
          ×Ïҹʱʱ²ÊÈí¼þ

          <td id="cl7yg"></td>

              <code id="cl7yg"></code>

                <td id="cl7yg"></td>

                    <code id="cl7yg"></code>