蝴蝶效应与“数据库慢查询雪崩“"/>
蝴蝶效应与“数据库慢查询雪崩“
昨天是周四,下午进行了平淡无奇的大屏数据排查问题,随后部署升级。傍晚,忽然系统大屏界面出现个别的报错:"网络连接超时,请重试"。
瞄了一眼后,发现是前端调用后端接口外部数据源查询超时,而且这些接口最近没有太大的改动。随即找其他平台同事沟通、反馈,得到了一切正常的答复....
于是博主觉得可能是网络延时、卡顿问题(在用VPN),就没再注意了。
第二天,晨会后再查看门户大屏数据,出现了雪花般的报错,瞬间就清醒了.....
排查一番系统后,发现登录功能、后台用户管理功能一切正常,只有大屏数据异常。博主觉得还是数据库查询慢问题,就找其他平台同事开会沟通问题,得到了可能是新增sql关联的表业务太多。
灵光一闪,博主隐隐感觉还是不太对,开始查询服务器详细日志,发现数据库日志出现大量的DM报错日志。仔细一看,发现是连接池获取数据库连接超时。
博主想了想数据库连接池配置,150个最大连接,加上数据库连接池的空闲回收、定时清理机制,不应该会出现在这个“几并发”的业务场景。
博主仔细分析了下,有了一个大概的猜测:
1)DM数据库性能有点异常(诱因问题)
2)部分代码写的不太规范,导致问题1翻倍(隐藏问题)
结论:不规范代码占用数据库连接池不释放。刷新几次页面,新来的HTTP请求导致所有的数据库链接都被慢SQL占用。其他HTTP请求进来,就会等待从连接池中获取可用链接,超过15s后,浏览器端断开了请求。而后端的HTTP请求线程还在等待,等到30s后,则获取数据库连接超时,就抛出了如上图所示的异常问题。
有了这个思路,博主就开始尝试临时解决下问题:
1)设置数据库查询超时时间
2)增大数据库连接池最大个数到300...
由于1)还要改代码,所以博主直接改了2),增到了500。信心满满的重启了服务。
结果:
博主经过一番痛定思痛,意识到临时解决2)是不可取的,1)还行。但还是要解决下系统数据库连接池连接被占满的根源问题---》代码不规范问题。 Ex:for循环查询库...没意义的查询等等...
做了上述操作,博主就开始顺便让同事排查每个模块功能的代码、SQL,进行实际测试、验证、筛选问题代码、慢SQL。
下午和同事评审这些问题代码、SQL。最慢的一个统计接口查询耗时能够达到78s..... 而且部分sql查询达到了 22s以上。
至此,问题基本上都有了定位。后续外部主要和其他平台同事排查 sql查询超级慢的问题。内部同时开始Review问题代码,也在在线文档上给出了每个接口的修改意见。
再后面,博主修复了部分接口,重新部署、升级了服务,系统貌似暂时恢复了正常。
总结:这是一次由于DM数据库异常超时的蝴蝶在 系统不规范代码(7*5层循环,翻几十倍)的翅膀煽动下,刮起了一阵风(单次HTTP请求长期占用链接),最终引起了隔壁大洋海啸(系统整个大屏数据统计全都宕机)的故事。
个人:代码规范性才是最值得我们开发人员需要注意的。要带着思考去写代码,而不是为了工作写代码。
THANKS~~
更多推荐
蝴蝶效应与“数据库慢查询雪崩“
发布评论