由于个人疏忽导致现场服务器崩溃的一次总结

前言

非常抱歉,这是一个非常非常严重的生产事故,写下来的主要目的是让自己铭记于心,防止下次发生。(PS:可能也还会发生)

具体过程

事故原因是这样的,偶然一个寂静无声的夜晚,大概十点半的时候,突然,现场反馈没有办法使用了,我丢,啥情况呀。 各种查询都很慢, 提交几十K数据也要十来秒的时间。 当时,误以为是点位不够导致的数据查询慢,压根也没有想到去优化代码,然后扯个谎,让现场多加点空闲点位。 然后,偷偷摸摸的重启了数据库服务,让其恢复正常。 整个过程一丝不苟非常完美。 客户夸夸点赞。
当时没有放在心上,第二天晚上又出现相同的问题,而且也是相同的个时间段。
当时分析:
(1)上线了由于之前都是在客户现场做开发,很多没有加索引,现在运行起来数据量大了,就导致了大量慢查询。

(2) 由于在现场开发,开发测试都是都一个人,很多东西逻辑混乱, 很多必要的引用。

(3) 数据库和程序是部署在同一台服务器上的,数据库没有设置最大的内存限制,数据库会一直执行并将查询的数据保存在内存中。

优化:

(1) 再忙都要进行压力测试。

(2) 避免忘记加索引, 建议在每张表的高频查询上都加上索引,不论数据量是多还是少等等。

(3) 前端高频操作,需要做节流限制,避免短时间多次点击,造成后台资源浪费

(4)代码层面上循环里一定!一定!一定!不要做数据库查询,除非不得已情况

(5) 高频次数据一次性查询添加到缓存中,设置过期阈值。

(6)减少不必要的引用,不需要的统统删除。

(7) 设置数据库最大内存限制,根据平时时间正常运行的值去设置。

(8) 升级服务器 (后面做了双机热备,内存比之前整整多了一倍)

最后

感谢客户领导以及同事的帮助与支持,不然我也没有那么好的一次人生经验!

  • 10
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值