千万别在论坛、群里问，我的机器好慢怎么回事？我的机器内存泄露了怎么回事？
　　这类大而空的问题一点意义都没有，其实谁都不知道。你要做的是用下面的思路、方法、工具去定位它
　　解决问题思路
　　Java程序问题(运行慢)
　　先通过 top 查看整个CPU资源使用情况;
　　通过top -Hp pid查看java进程的每一个线程占用CPU的情况;
　　如果有一个线程占用CPU过高，有两种可能：
　　没有内存了，Java垃圾回收线程不停地运行尝试回收内存，但是每次无法收回，确认：
　　jstat -gcutil pid 1s 观察10多秒钟就能发现了，看是不是内存使用率接近100%了
　　类似于死循环(hash冲突攻击)，就是一个线程一直占用一个核的所有CPU资源(其实一个线程总是暂用一个核超过50%的资源都是不太正常的)，解决：
　　用我课堂的checkPerf脚本，定位这个线程具体执行的任务(能具体到某一行)，对应看代码解决。
　　如果有很多线程，每个线程占用的CPU都不多，那基本是正常的。
　　如果死锁：
　　jstack -l pid 多执行几次，统计一下stack中总是在等待哪些锁，可以对锁id进行排序统计(sort uniq grep)
　　上面列出来的都是明显的瓶颈，最可怕的是哪里都没有明显的瓶颈，哪里都要偷一点点资源走，这是可以试试JProfiler这样更专业一点的工具，同时要配合自己对业务的了解来解决。
　　Java内存的问题，如果有内存泄露(就是执行完fgc/old gc后不能回收的内存不断地增加)：
　　快速解决：jmap -histo:live pid 来统计所有对象的个数(String/char/Integer/HashEntry 这样的对象很多很正常，主要是盯着你们公司的包名下的那些对象)
　　每隔一分钟执行一次上面的命令，执行5次以上，看看你们公司报名下的对象数量哪个在一直增加，那基本上就是这个对象引起了泄露;
　　用课堂上的工具HouseMD来动态监控创建这个对象的地方(一般来说很多时候创建了这些对象把他们丢到一个HashMap然后就不管了)，分析一下有没有释放!
　　上面的方法实在没法定位就用: jmap -dump 导出整个内存(耗时间，需要很大的内存的机器才能对这个导出文件进行分析，会将JVM锁住一段时间)
　　在Eclipse的插件EMA中打开这个文件(2G的物理文件需要4G以上的内存，5G以上的需要将近20G的内存来分析了)
　　盯着你们公司报名的那些对象，看看引用关系，谁拿着这些对象没释放(是否是必要的)
　　MySQL 数据库的性能问题
　　大部分情况下是磁盘IO的问题(索引没建好、查询太复杂);
　　索引问题的话分析慢查询日志，explain 他们挨个解决。
　　偶尔也有数据库CPU不够的情况，如果并发高CPU不够很正常，如果并发不高，那很可能就是group by/order by/random之类的操作严重消耗了数据库的CPU
　　mysql -e “show full processlist” | grep -v Sleep | sort -rnk6 查看那些SQL语句执行的太长
　　拿出这个SQL语句分析他们的执行计划: explain SQL 然后改进;
　　分析慢查询日志，统计top10性能杀手的语句，挨个explain他们，然后改进(具体改进办法具体分析，这里只谈思路)
　　总结一下数据库问题就只有这三招：show full processlist/分析慢查询日志/explain(然后建好联合索引)
　　原文链接：http://database.ctocio.com.cn/66/12654066.shtml

千万别在论坛、群里问，我的机器好慢怎么回事？我的机器内存泄露了怎么回事？
　　这类大而空的问题一点意义都没有，其实谁都不知道。你要做的是用下面的思路、方法、工具去定位它
　　解决问题思路
　　Java程序问题(运行慢)
　　先通过 top 查看整个CPU资源使用情况;
　　通过top -Hp pid查看java进程的每一个线程占用CPU的情况;
　　如果有一个线程占用CPU过高，有两种可能：
　　没有内存了，Java垃圾回收线程不停地运行尝试回收内存，但是每次无法收回，确认：
　　jstat -gcutil pid 1s 观察10多秒钟就能发现了，看是不是内存使用率接近100%了
　　类似于死循环(hash冲突攻击)，就是一个线程一直占用一个核的所有CPU资源(其实一个线程总是暂用一个核超过50%的资源都是不太正常的)，解决：
　　用我课堂的checkPerf脚本，定位这个线程具体执行的任务(能具体到某一行)，对应看代码解决。
　　如果有很多线程，每个线程占用的CPU都不多，那基本是正常的。
　　如果死锁：
　　jstack -l pid 多执行几次，统计一下stack中总是在等待哪些锁，可以对锁id进行排序统计(sort uniq grep)
　　上面列出来的都是明显的瓶颈，最可怕的是哪里都没有明显的瓶颈，哪里都要偷一点点资源走，这是可以试试JProfiler这样更专业一点的工具，同时要配合自己对业务的了解来解决。
　　Java内存的问题，如果有内存泄露(就是执行完fgc/old gc后不能回收的内存不断地增加)：
　　快速解决：jmap -histo:live pid 来统计所有对象的个数(String/char/Integer/HashEntry 这样的对象很多很正常，主要是盯着你们公司的包名下的那些对象)
　　每隔一分钟执行一次上面的命令，执行5次以上，看看你们公司报名下的对象数量哪个在一直增加，那基本上就是这个对象引起了泄露;
　　用课堂上的工具HouseMD来动态监控创建这个对象的地方(一般来说很多时候创建了这些对象把他们丢到一个HashMap然后就不管了)，分析一下有没有释放!
　　上面的方法实在没法定位就用: jmap -dump 导出整个内存(耗时间，需要很大的内存的机器才能对这个导出文件进行分析，会将JVM锁住一段时间)
　　在Eclipse的插件EMA中打开这个文件(2G的物理文件需要4G以上的内存，5G以上的需要将近20G的内存来分析了)
　　盯着你们公司报名的那些对象，看看引用关系，谁拿着这些对象没释放(是否是必要的)
　　MySQL 数据库的性能问题
　　大部分情况下是磁盘IO的问题(索引没建好、查询太复杂);
　　索引问题的话分析慢查询日志，explain 他们挨个解决。
　　偶尔也有数据库CPU不够的情况，如果并发高CPU不够很正常，如果并发不高，那很可能就是group by/order by/random之类的操作严重消耗了数据库的CPU
　　mysql -e “show full processlist” | grep -v Sleep | sort -rnk6 查看那些SQL语句执行的太长
　　拿出这个SQL语句分析他们的执行计划: explain SQL 然后改进;
　　分析慢查询日志，统计top10性能杀手的语句，挨个explain他们，然后改进(具体改进办法具体分析，这里只谈思路)
　　总结一下数据库问题就只有这三招：show full processlist/分析慢查询日志/explain(然后建好联合索引)
　　原文链接：http://database.ctocio.com.cn/66/12654066.shtml