记一次前端页面加载方式调整导致的数据库连接数暴增

一、 问题现象

1. 连接数飙升

  • 8.21 8点起,主库活跃连接数显著飙升,至10:30左右逼近数据库最大连接数

记一次前端页面加载方式调整导致的数据库连接数暴增_第1张图片

平时活跃会话平均数约31

记一次前端页面加载方式调整导致的数据库连接数暴增_第2张图片

问题期间活跃会话平均数高达322,超出正常10倍以上

记一次前端页面加载方式调整导致的数据库连接数暴增_第3张图片

从连接用户看,其中一个用户明显高于其他

  • 12-16点,将该用户连接切换至从库,从库连接数显著飙升

记一次前端页面加载方式调整导致的数据库连接数暴增_第4张图片

  • 16点后,cs_rw用户连接切换回主库,业务量较低时,平均连接数也达到135,远高于之前的高峰期值

记一次前端页面加载方式调整导致的数据库连接数暴增_第5张图片

2. 服务器负载飙升

由于活跃连接数暴增,查询量明显增加,服务器负载飙升

记一次前端页面加载方式调整导致的数据库连接数暴增_第6张图片

同时查询出现大量LWLock等待,执行速度降低,加剧连接堆积问题

二、 问题分析与处理

1. 问题分析

与业务共同分析,有以下可能会导致数据库连接数飙升:

  • 用户数增加
  • 业务量增加
  • 应用连接池变更
  • 缓存失效,连接直接打入数据库

经过与业务和供应商共同排查,结果如下:

  • 用户数较上周无明显增加
  • 业务量较上周无明显增加,但BI报表的特点是一个报表对应多个SQL,可能存在连接放大的问题
  • BI报表应用在周六有执行过升级,但并不涉及连接池修改(业务也未使用连接池)
  • 缓存未失效,且缓存使用率略有上升

       其中最引人注意的是BI报表应用在周六有执行过升级,因为连接数飙升的恰好是BI报表应用,且在周末业务负载低,若升级后有异常,在周一8点业务开始工作时出现也符合逻辑。

       开发与供应商继续排查,发现8.21起,BI报表请求日志量是之前的10倍以上,有明显异常,且符合连接数上涨情况。

       在报表页面F12调试发现,当前在打开一个报表页面时,会将其中所有图表均进行加载,在数据库中执行查询,而之前正常时只会加载用户正在看的几个图表。

      正常时,若首屏窗口只能看到以下两个图片,则只有这两个图片会被加载(对于本例则生成两个SQL发送到数据库执行)

记一次前端页面加载方式调整导致的数据库连接数暴增_第7张图片

再往下拉,才加载后面图片(看到后面两个报表时,对应的SQL才会发送到数据库查询)

记一次前端页面加载方式调整导致的数据库连接数暴增_第8张图片

       而问题发生时,即使首屏只能看到两个报表,也会将本页中所有报表SQL提前发送至数据库查询。而由于部分BI报表过于复杂,会有一个报表页面包含数十个甚至上百个图表的情况,当同时加载到数据库时,便会造成连接数爆涨、负载飙升。

       供应商也反馈,页面加载方式的改变与周末升级有关,属于前端优化项之一,且为硬编码,无配置文件可修改。

2. 解决方法

当天供应商单独修改前端代码包,交给开发替换升级后代码包。替换后,业务恢复。

观察替换后数据库活跃连接数,可以看到已恢复正常

记一次前端页面加载方式调整导致的数据库连接数暴增_第9张图片

三、 懒加载与预加载

       一些扩展知识:上面的两种加载方式对应前端术语分别是——懒加载,预加载。直观感受一下两者的区别

Native lazy-loading of images with zero Javascript - DEV Community

记一次前端页面加载方式调整导致的数据库连接数暴增_第10张图片

预加载(左图):在页面打开时即陆续加载其中内容,即使用户不看

  • 优点:用户体验好,由于预先加载完成,用户看后续内容不需等待
  • 缺点:耗费资源,增加服务器负载,严重时可能引发系统故障(比如本例)。如果用户确实不需看后续内容,预加载部分会完全浪费

懒加载(右图):只加载用户看到的内容

  • 优点:节约资源,服务器负载较低;另外由于一次需加载的内容少,首屏内容展示可能较快
  • 缺点:用户体验较差,看后续内容需要等待。如果加载耗时过长,对于一般网页可能流失用户

参考:

AddyOsmani.com - Native lazy-loading for iframes is here!

Native lazy-loading of images with zero Javascript - DEV Community

你可能感兴趣的:(性能,PostgreSQL,postgresql,连接数,前端,预加载,懒加载)