一、 问题现象
1. 连接数飙升
- 8.21 8点起，主库活跃连接数显著飙升，至10:30左右逼近数据库最大连接数
平时活跃会话平均数约31
问题期间活跃会话平均数高达322，超出正常10倍以上
从连接用户看，其中一个用户明显高于其他
- 12-16点，将该用户连接切换至从库，从库连接数显著飙升
- 16点后，cs_rw用户连接切换回主库，业务量较低时，平均连接数也达到135，远高于之前的高峰期值
2. 服务器负载飙升
由于活跃连接数暴增，查询量明显增加，服务器负载飙升
同时查询出现大量LWLock等待，执行速度降低，加剧连接堆积问题
二、 问题分析与处理
1. 问题分析
与业务共同分析，有以下可能会导致数据库连接数飙升：
- 用户数增加
- 业务量增加
- 应用连接池变更
- 缓存失效，连接直接打入数据库
经过与业务和供应商共同排查，结果如下：
- 用户数较上周无明显增加
- 业务量较上周无明显增加，但BI报表的特点是一个报表对应多个SQL，可能存在连接放大的问题
- BI报表应用在周六有执行过升级，但并不涉及连接池修改（业务也未使用连接池）
- 缓存未失效，且缓存使用率略有上升
其中最引人注意的是BI报表应用在周六有执行过升级，因为连接数飙升的恰好是BI报表应用，且在周末业务负载低，若升级后有异常，在周一8点业务开始工作时出现也符合逻辑。
开发与供应商继续排查，发现8.21起，BI报表请求日志量是之前的10倍以上，有明显异常，且符合连接数上涨情况。
在报表页面F12调试发现，当前在打开一个报表页面时，会将其中所有图表均进行加载，在数据库中执行查询，而之前正常时只会加载用户正在看的几个图表。
正常时，若首屏窗口只能看到以下两个图片，则只有这两个图片会被加载（对于本例则生成两个SQL发送到数据库执行）。
再往下拉，才加载后面图片（看到后面两个报表时，对应的SQL才会发送到数据库查询）
而问题发生时，即使首屏只能看到两个报表，也会将本页中所有报表SQL提前发送至数据库查询。而由于部分BI报表过于复杂，会有一个报表页面包含数十个甚至上百个图表的情况，当同时加载到数据库时，便会造成连接数爆涨、负载飙升。
供应商也反馈，页面加载方式的改变与周末升级有关，属于前端优化项之一，且为硬编码，无配置文件可修改。
2. 解决方法
当天供应商单独修改前端代码包，交给开发替换升级后代码包。替换后，业务恢复。
观察替换后数据库活跃连接数，可以看到已恢复正常。
三、 懒加载与预加载
一些扩展知识：上面的两种加载方式对应前端术语分别是——懒加载，预加载。直观感受一下两者的区别
Native lazy-loading of images with zero Javascript - DEV Community
预加载（左图）：在页面打开时即陆续加载其中内容，即使用户不看
- 优点：用户体验好，由于预先加载完成，用户看后续内容不需等待
- 缺点：耗费资源，增加服务器负载，严重时可能引发系统故障（比如本例）。如果用户确实不需看后续内容，预加载部分会完全浪费
懒加载（右图）：只加载用户看到的内容
- 优点：节约资源，服务器负载较低；另外由于一次需加载的内容少，首屏内容展示可能较快
- 缺点：用户体验较差，看后续内容需要等待。如果加载耗时过长，对于一般网页可能流失用户
参考：
AddyOsmani.com - Native lazy-loading for iframes is here!
Native lazy-loading of images with zero Javascript - DEV Community