[转帖]解决Java/MySQL性能问题的思路

https://plantegg.github.io/2023/08/28/%E8%A7%A3%E5%86%B3%E9%97%AE%E9%A2%98%E6%80%9D%E8%B7%AF/

10年前写的，重新发一下

系统性能问题

CPU（基本上WEB服务器没有多少IO，主要是CPU有瓶颈）
- top/vmstat 观察CPU使用率，Load负载，r/b线程数量等；
- IO（数据库大多数时候瓶颈是IO，主要是索引没建好；如果数据库CPU紧张的话，检查一下是不是order by/group by 等操作太多）
- vmstat 观察IO/Util吞吐，磁盘最怕随机读写了（比如：索引命中后，需要离散地从磁盘读数据）
- 对于数据库来说最怕内存不够的时候使用Swap了，所以尽量增大分配给数据库的内存，一旦有Swap就要引起注意了

Java程序问题（运行慢）

先通过 top 查看整个CPU资源使用情况；
通过top -Hp pid查看java进程的每一个线程占用CPU的情况；
如果有一个线程占用CPU过高，有两种可能：
没有内存了，Java垃圾回收线程不停地运行尝试回收内存，但是每次无法收回，确认：
jstat -gcutil pid 1s 观察10多秒钟就能发现了，看是不是内存使用率接近100%了
类似于死循环（hash冲突攻击），就是一个线程一直占用一个核的所有CPU资源（其实一个线程总是占用一个核超过50%的资源都是不太正常的），解决：
用我的checkPerf脚本，定位这个线程具体执行的任务（能具体到某一行），对应看代码解决。

    如果有很多线程，每个线程占用的CPU都不多(基本都在10%以下)，那基本是正常的，只是程序并发确实很高。

如果死锁：

    jstack -l pid 多执行几次，统计一下stack中总是在等待哪些锁，可以对锁id进行排序统计（sort uniq grep）

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

一旦触发频繁地抛出异常，CPU占用率会急剧地上升（抛异常比正常情况下会慢2个数量级）主要是由于：Throwable的构造函数中会调用native的fillInStackTrace()，这个方法就会构造整个异常栈了。

Java内存的问题，如果有内存泄露（就是执行完fgc/old gc后不能回收的内存不断地增加）：
怎么确认没有内存了：
jps -lmv pid 先确认你的参数，也就是你给JVM分配了多大的堆(-Xmx 比如1G); 然后jstat -gcutil pid 1s 看看GC运行情况，如果(O/E 两列基本接近100%的话就是内存不够了)
内存不够分两种：一种是真的不够，就是你们的系统很庞大需要1G以上的内存，而你只分配了1G，这个没什么好说的，增大内存，物理内存不够就投钱买；
第二一种是你们的代码写的烂，有内存泄露，这样的话分配多少内存都不够，得找出是否有内存泄露，看接下的解决方案

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

每隔一分钟执行一次上面的命令，执行5次以上，看看你们公司报名下的对象数量哪个在一直增加，那基本上就是这个对象引起了泄露；

用课堂上的工具HouseMD(java -Xbootclasspath/a:/usr/java/jdk1.6.0_29/lib/tools.jar -jar housemd-assembly-0.2.2.jar pid)来动态监控创建这个对象的地方（一般来说很多时候创建了这些对象把他们丢到一个HashMap然后就不管了），分析一下有没有释放！

    >trace -s -d ClassName

上面的方法实在没法定位就用: jmap -dump:live,format=b,file=heap.bin pid 导出整个内存（耗时间，需要很大的内存的机器才能对这个导出文件进行分析，会将JVM锁住一段时间）

    在Eclipse的插件EMA中打开这个文件（2G的物理文件需要4G以上的内存，5G以上的需要将近20G的内存来分析了）

    盯着你们公司报名的那些对象，看看引用关系，谁拿着这些对象没释放（是否是必要的），可以一直追查的RootReference

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（然后建好联合索引）

补充一个数据库连接数不够的问题，很多人碰到了，不知道怎么解决：

在mysql 命令行里执行：show variables like ‘%max_connections%’; 看看你们的数据实际配置是多少（比如1000）
show full processlist 数一下多少行，一行代表一个连接，比如这里是1000行，那基本上就是连接数不够了，你要解决的为什么你的数据库需要这么多连接
接下来分析这些连接是从哪来的IP，然后问你自己：根据你们的服务类型的特点需要这么多连接吗？

数据库性能问题提问请给出：

show full processlist;
查询语句;
表结构(包括索引结构);
数据库引擎类型;