前言
非常抱歉,这是一个非常非常严重的生产事故,写下来的主要目的是让自己铭记于心,防止下次发生。(PS:可能也还会发生)
具体过程
事故原因是这样的,偶然一个寂静无声的夜晚,大概十点半的时候,突然,现场反馈没有办法使用了,我丢,啥情况呀。 各种查询都很慢, 提交几十K数据也要十来秒的时间。 当时,误以为是点位不够导致的数据查询慢,压根也没有想到去优化代码,然后扯个谎,让现场多加点空闲点位。 然后,偷偷摸摸的重启了数据库服务,让其恢复正常。 整个过程一丝不苟非常完美。 客户夸夸点赞。
当时没有放在心上,第二天晚上又出现相同的问题,而且也是相同的个时间段。
当时分析:
(1)上线了由于之前都是在客户现场做开发,很多没有加索引,现在运行起来数据量大了,就导致了大量慢查询。
(2) 由于在现场开发,开发测试都是都一个人,很多东西逻辑混乱, 很多必要的引用。
(3) 数据库和程序是部署在同一台服务器上的,数据库没有设置最大的内存限制,数据库会一直执行并将查询的数据保存在内存中。
优化:
(1) 再忙都要进行压力测试。
(2) 避免忘记加索引, 建议在每张表的高频查询上都加上索引,不论数据量是多还是少等等。
(3) 前端高频操作,需要做节流限制,避免短时间多次点击,造成后台资源浪费
(4)代码层面上循环里一定!一定!一定!不要做数据库查询,除非不得已情况
(5) 高频次数据一次性查询添加到缓存中,设置过期阈值。
(6)减少不必要的引用,不需要的统统删除。
(7) 设置数据库最大内存限制,根据平时时间正常运行的值去设置。
(8) 升级服务器 (后面做了双机热备,内存比之前整整多了一倍)
最后
感谢客户领导以及同事的帮助与支持,不然我也没有那么好的一次人生经验!