某环境解决卡顿问题的思路和过程

背景

部分环境经过一段时间的运行后出现了卡顿现象.
严重时出现了 jdbc的data access的异常提示信息. 

接到这个问题后,自己进行了一些处理.
这里总结一一下问题的处理过程以及思路

问题现象

应用服务器是 linux + springboot开发的应用
数据库是 Windows2012r2+SQL2012的数据库
分别在两个物理机上面, 配置类似,大约都是8c32G的配置 或者是更高
数据库的数据文件大约有100G

应用服务器经常反馈登录慢,启动慢等问题

思路与解决

整体分析
确认同事的说法, 登录产品进行验证的确出现了很高的延迟

1. 打开F12 进入network进行查看,发现有很多请求出现了 十几秒甚至分钟级别的操作. 判断系统有问题

2. 同事之前部署过 actuator 直接使用grafana 展示 主要是展示GC和应用服务器的使用情况
当时发现GC 每小时不到3次. 应用服务器CPU压力不大
但是明显能够发现有分支级别的http请求返回.

3. 查看数据库, 物理机层面发现IO的延迟都是20ms左右没有太大瓶颈.感觉很奇怪
进入操作系统, 发现存在任务管理器->性能->磁盘响应延迟到了 2秒级别 发现IO问题已经非常严重. 

4. 第一个解决办法, 先将数据库迁移到SSD类型的存储上面. 因为前期为了数据安全采用的2THDD*RAID6的设置
虚拟机运行了很多, 加之有快照和虚拟机存在较多的碎片, 所以存在较高的风险

5. 虚拟机迁移完毕之后再次验证, 发现在高并发情况下 使用hikari的监控有大量的连接超时操作
登录服务器,发现应用和数据库存在较大的时间差异, 修改配置, 增加ntp到阿里云的同步处理
并且将同步频率修改到 1小时一次, 避免再次出现问题

6. 继续运行未再现问题. 

思考

1. 不管什么类型的环境,只要有了数据量和并发的要求,  数据库与应用都必须得拆开
   并且建议不属于不同的主机上面, 避免互相干扰. 

2. 数据库的存储尽量要好一些, 至少延迟不能太高. 高延迟会带来很多奇奇怪怪的问题.

3. 增加监控尤其是GC,thread,hikari连接池,以及主机,网络监控
   有条件增加对数据库尤其是慢SQL, 阻塞SQL的监控. 实时发现,督促解决. 

4. 出现问题要逐个逐层分析, 逐层验证, 不建议一次修改太多变量, 避免问题定位失真. 

5. 应用服务器虽然不太考验IO,但是如果有大量的零散文件还是会影响文件系统的性能. 
   建议不要在应用服务器上面存储太多零散文件.  

6. 数据库要对大型表,大数据,大行数,以及大量变更的表入录台账, 通过分区表,归档历史数据等方法来规避
   大表索引层级出现问题导致性能下降的情况. 

7. 出现问题不要惊慌, 解决问题的过程就是能力提升的过程. 全面分析,抓住重点,解决问题. 

8. 监控,指标很重要,收集足够的信息能够避免进入歧途.