记录一次线上系统变慢排查问题及优化

线上系统在用户使用过程中，突然变慢。相信伙伴们也碰到过相似的问题。经过逐一排查，最终问题得以解决。解决分析问题都是依托我司系统的实际使用情况，在实际问题处理中还要具体问题具体分析。以下分析步骤仅供参考：
1.系统部分功能截图介绍，系统中大量的学生成绩分析统计信息。大概有几百万的数据量。表格展示信息并非固定格式，都是根据当前院系所设课程和学生参与情况动态生成计算数据。计算量很大，因此一部分数据是提前计算好的。部分需要实时计算的，才在页面查询时计算出来。
已下功能点代码是通过异步编排查询和sql尽量单表查询部分数据作缓存处理，来实现快速和实时展示变更数据。

以下功能点代码是通过提前计算，和部分展示异步编排来实现，以为表格不固定，数据是以json的形式动态存储。在解析json时会有大量的嵌套循环解析。

已下功能点代码是通过异步编排查询来实现快速和实时展示变更数据。







2.查找问题分析：
排查服务器是否内存不足，JVM是否频繁发生Full GC。（我们系统采用JDK8，parNew+CMS方式）
JVM 查看情况，发现并没有大量的Full GC发生。GC基本都是在YGC发生

排查服务器物理和虚拟内存是否达到饱和

3.排除以上问题，根据页面请求响应情况，查看响应慢的接口地址，查找代码分析业务逻辑和sql编写问题。
在多层嵌套循环中，尽量将sql语句写到循环外面，如果由于业务需要，不得不写入，就要重点监控其执行时间。

再循环内的修改和插入操作要尽量放在循环外，以批量方式提交，减少和数据库的IO操作。

3.发现系统中嵌套循环中查询sql语句变慢导致，基本执行一次大约1.3S。如果有几百名学生就是几百秒很显然需要优化处理。（在系统数据量少的时候，是不能暴露查询缓慢地问题的，大约数据达到几十万就会很明显）仅是这样一张单表查询的sql就会导致系统响应很慢，为此我们为该表添加了联合索引。查询性能由1.5s降低到0.46s左右。（未加索引之前，由于响应时间长，进场出现锁表的情况）可通过以下语句排查
select*from information_schema.INNODB_LOCKS;
show PROCESSLIST;

4.为了发现系统中执行时间比较长的SQL语句，进行了数据库慢查询日志修改。

show VARIABLES like ‘slow%’;

set global slow_query_log=on; #打开慢查询日志

set global alow_query_log_file=/var/log/mysql/slow_log #日志存储路径

show VARIABLES like ‘long%’;

set global long_query_time=1 #设置查询查过1s的sql记录到日志中，最对sql逐一分析解决。

5.最后为了提高系统整体性能，将数据库的缓存设置开启。该设置可根据系统实际情况设置。系统查询效率提升了百倍。以可以很好的支持用户使用。当然，还是根据系统实际情况和架构复杂度以及数据容量，是否以后进行业务剥离微服务和分库分表处理。（系统出现缓慢问题是在系统数据量变大后暴露的，我们的系统单表几十万数据量的时候就出现了查询缓慢问题。数据量小的时候很难暴露）

show VARIABLES like ‘query_cache%’;
set global query_cache_type=on; #打开缓存

再打开缓存后，要重启系统建立对数据库的重新连接。才会生效