记一次线上gc调优的过程

近期线上我们一个后台管理系统运行特别慢，而且经常出现504超时的情况。对于这种情况我们本能的认为可能是代码有性能问题，可能有死循环或者是数据库调用次数过多导致接口运行过慢。应领导要求，我们将主站中进行性能测试的框架代码添加到该后台管理系统中。上线运行一段时间后，查看相关日志可以看到如下分析日志：
mysql 数据库链接数优化:
查看mysql连接数状态
.mysql> show status like ‘Threads%’;
+——————-+——-+
| Variable_name | Value |
+——————-+——-+
| Threads_cached | 58 |
| Threads_connected | 57 | ###这个数值指的是打开的连接数
| Threads_created | 3676 |
| Threads_running | 4 | ###这个数值指的是激活的连接数，这个数值一般远低于connected数值
+——————-+——-+

Threads_connected 跟show processlist结果相同，表示当前连接数。准确的来说，Threads_running是代表当前并发数

查询数据库当前设置的最大连接数
2.mysql> show variables like ‘%max_connections%’;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 1000 |
+—————–+——-+

可以在/etc/my.cnf里面设置数据库的最大连接数
[mysqld]
max_connections = 1000

max_connections 参数可以用于控制数据库的最大连接数：
3.mysql> show variables like ‘%connect%’;
+————————–+——————-+
| Variable_name | Value |
+————————–+——————-+
| character_set_connection | latin1 |
| collation_connection | latin1_swedish_ci |
| connect_timeout | 10 |
| init_connect | |
| max_connect_errors | 10 |
| max_connections | 4000 |
| max_user_connections | 0 |
+————————–+——————-+

Too many connections
很多开发人员都会遇见”MySQL: ERROR 1040: Too many connections”的异常情况，造成这种情况
原因是访问量过高，MySQL服务器抗不住，这个时候就要考虑增加从服务器分散读压力；
另一种原因就是MySQL配置文件中max_connections值过小。

首先，我们来查看mysql的最大连接数：
mysql> show variables like ‘%max_connections%’;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 151 |
+—————–+——-+
1 row in set (0.00 sec)

其次，查看服务器响应的最大连接数:
mysql> show global status like ‘Max_used_connections’;
+———————-+——-+
| Variable_name | Value |
+———————-+——-+
| Max_used_connections | 2 |
+———————-+——-+
1 row in set (0.00 sec)
可以看到服务器响应的最大连接数为2，远远低于mysql服务器允许的最大连接数值。
对于mysql服务器最大连接数值的设置范围比较理想的是：服务器响应的最大连接数值占服务器上限连接数值的比例值在10%以上，如果在10%以下，说明mysql服务器最大连接上限值设置过高。

Max_used_connections / max_connections * 100% = 2/151 *100% ≈ 1%
我们可以看到占比远低于10%（因为这是本地测试服务器，结果值没有太大的参考意义，大家可以根据实际情况设置连接数的上限值）。
再来看一下自己 linode VPS 现在（时间：2013-11-13 23：40：11）的结果值：

mysql> show variables like ‘%max_connections%’;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 151 |
+—————–+——-+
1 row in set (0.19 sec)
mysql> show global status like ‘Max_used_connections’;
+———————-+——-+
| Variable_name | Value |
+———————-+——-+
| Max_used_connections | 44 |
+———————-+——-+
1 row in set (0.17 sec)
这里的最大连接数占上限连接数的30％左右。
上面我们知道怎么查看mysql服务器的最大连接数值，并且知道了如何判断该值是否合理，下面我们就来介绍一下如何设置这个最大连接数值。

方法1：
mysql> set GLOBAL max_connections=256;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like ‘%max_connections%’;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 256 |
+—————–+——-+
1 row in set (0.00 sec)

方法2：
修改mysql配置文件my.cnf，在[mysqld]段中添加或修改max_connections值：
max_connections=128
重启mysql服务即可。

既然不是数据库导致的，通过性能日志也可以确认不是代码中有死循环或者数据库调用次数过多的问题，我们就思考是否为JVM层面的问题。在登录线上机器之后，我们使用首先使用top命令查看了该机器进程的运行情况：

查看cpu使用率，找到cpu 大于100%以上的进程id，进一步查看是具体的哪一个线程运行的cpu如此之高：
top -Hp 2580
结果看到id为2598 的线程运行cpu达到了97%，基本上可以确定是这个线程的运行导致项目整体运行较慢。接下来我们使用jstack命令查看了该进行各个线程运行情况，具体的命令如下：
jstack 2580 >/jstack.log
这里有两点需要注意：
jstack命令需要再jdk的bin目录下执行，并且必须要以当前启动项目tomcat的用户身份运行，如果不是该用户登录的，可以使用如下命令导出线程运行日志：
sudo -u admin ~/jdk/bin/jstack 2580 >/jstack.log

看到有大量的GC操作，导致的缓慢，进一步我们使用：
jstat 命令查看内存使用情况：
jstat -gcutil 2580 1000 5
接下来查看
内存的使用情况
jmap -histo 2580,可以看到，创建的数量比较高，创建频率比较快导致JVM进行了大量的gc工作，最终导致工程性能降低。