20191025-生产事故记录

【现象】:EJF调用PLM的接口,短时间内出现大量下单请求,导致网络阻塞,数据库连接池达到上限,接口崩溃;

【环境】:服务器使用的是阿里云,centos7 + docker + redis + netcore,网络带宽5M,数据库最大连接数设置了3000;

【分析】:接口出现崩溃现象后——

1、检查了docker服务,正常,未挂;

2、本地使用 Navicat for Mysql 工具可以正常连接数据库;

3、检查应用服务器连接数据库,(发现无法连接,重启数据库服务恢复正常--昨天 & 正常可以连接,重启数据库服务仍旧异常--今天);

4、重启应用服务器,接口可以使用,但异常缓慢,后检查发现Redis服务为正常启动;

5、通过运维报告,峰值时段,数据流量超过了带宽上限 5M ,达到了 11M+--今天;昨天的峰值在 7M+ 左右,同样超过了带宽上限;

6、服务器上调用数据库也是走的外网地址,占用带宽;

【结论】:初步结论主要从两方面分析——

第一,带宽上限调高到了 50M,这样单个传输的最大值约在 50M/8 ≈ 6.25M,目前接口中最大数据量大约在 400 ~ 500 KB ;

第二,检查代码连接数据库是否正确,是否正确释放(这个没发现代码有啥不合理的地方);

【再论】:程序使用的是异步调用,如果短时间内大量高并发访问,带宽不足的前提下,很有可能导致传输拥堵。连接无法正常释放,新的请求继续开启新的连接,如此循环往复,这样可能就是导致连接数达到上限的可能原因。

原文地址:https://www.cnblogs.com/lishidefengchen/p/11738545.html

时间: 2024-08-07 04:57:07

20191025-生产事故记录的相关文章

因我而起的生产事故

首先,祝大家新年快乐!应该陆陆续续开始踏上了回家的征程吧! 生产事故 产品上线一段时间之后,技术支持反馈客户现场一个进程总是挂掉或者不干活!最开始不紧不慢的查找问题,后来老大很生气说:生产事故很严重,你们居然不重视!成立了一个应急小组,专门解决此问题,其中包括我! 事故原因 经过2.3天没日没夜的艰苦奋斗,终于找到进程挂掉的原因,问题因我而起.大约去年8月,做一个项目,与大数据对接,把数据推给它,然在加上了推送部分的代码,最开始那个模块是没有日志的,然后给加上了日志打印,当时也没考虑那么多,多线

生产事故(MongoDB数据分布不均解决方案)

可以很明显可以看到我们这个集合的数据严重分布不均匀. 一共有8个分片,面对这个情况我首先想到的是手动拆分数据块,但这不是解决此问题的根本办法. 造成此次生产事故的首要原因就是片键选择上的问题,由于片键选择失误,在数据量级不大的时候数据看起来还是很健康的,但随着数据量的暴涨,问题就慢慢浮出了水面,我们使用的组合片键并不是无规律的,片键内容是线性增长的,这就导致了数据的不正常聚集.由于数据分布不均匀,我们有两个分片的磁盘使用率接近80%,数据还在持续增长,这个问题必须尽快解决. 涉及到此次事故的集合

记录一次我的造成的生产事故

原文地址:https://www.cnblogs.com/feifeicui/p/8999531.html

凌晨1点突发致命生产事故,人工多线程来破局!

有一个读者问我:你认为一个程序员具备什么样的能力,才算得上是厉害的程序员? 我答:拥有解决问题的能力的程序员. 这个回答貌似有点抽象,不要紧看下面的文章你会慢慢有所了解. 一.解决问题的能力 很多年前,当我还是一个小菜鸟的时候,我的领导经常告诉我,解决问题的时候,不要局限于技术本身,并且形象的给我举了一个例子. 有一次两个程序员一直讨论,如何判断两台服务器之间是否网络正常,争争吵吵了很久.旁边的一个测试说,Ping 一下不就知道了吗?就这样他们用 Java 代码实现了 Ping 操作解决了这个问

生产事故:误删/lib64,移走/lib64目录

事故背景: 有一台机器装不上nagios监控,yum install openssl报一个关于"libkrb5.so.3"冲突的错误. 解决过程: 1./lib64事故 关于"libkrb5.so.3"冲突的错误,查了一些文章没有解决,就想着把libkrb5卸掉,rpm -e libkrb5.rpm,卸载有关联冲突,然后就rpm -e libkrb5.rpm --nodeps(事实证明,如果不清楚软件的依赖,最好不要"--nodeps"),一卸载

2015年2月13日服务器无法访问事故记录以及经验总结

 计划2015年每天写一篇文章 提问请移步 http://weibo.com/p/1001603810113986105909 如果您不想看完整过程的话,那么直接看经验总结,转发留存吧! 事故主要问题 手工修改过IP设置,因此使用图形界面修改将导致出错,后果就是路由表错误 机房相关经验 需要关注机房的允许维护的时间,特别是公众假期 需要准备好详尽的交通路线,例如这个机房出租车司机可能更熟悉原来的名称:松下电视机厂 需要关注机房的门禁管理,身份证是一定要带的,之前的机房还有需要提前自制工卡的情

深入认识二进制序列化--记一次生产事故的思考

一 概要 二进制序列化是公司内部自研微服务框架的主要的数据传输处理方式,但是普通的开发人员对于二进制的学习和了解并不深入,容易导致使用过程中出现了问题却没有分析解决的思路.本文从一次生产环境的事故引入这个话题,通过对于事故的分析过程,探讨了平时没有关注到的一些技术要点.二进制序列化结果并不像Json序列化一样具备良好的可读性,对于序列化的结果大多数人并不了解,因此本文最后通过实际的例子,对照MSDN的文档对于序列化结果进行详细解析,并意图通过本次分析对于二进制序列化的结果有直观和深入的认识. 二

从一次生产事故说起——linux的单用户模式,救援模式等等

伴随着今年linux上面最大一个安全漏洞bash漏洞的出现,我们公司也开始了风风火火的漏洞修复工作,机器一多,也就容易出问题,有台64位的linux服务器一不小心就升级了32位 bash 的rpm,由于root,oracle这些用户默认都是通过/bin/bash来登陆的,这就造成了用户不能登陆服务器造成了极大的困扰,下面就是应对的办法,由于在生产环境解决的时候没法截图,通过虚拟机的环境来模拟当时的情况: 我们通过删除bash的rpm包的方式来模拟生产商bash包装错的情况: 在这个以前,我们先来

完了!生产事故!几百万消息在消息队列里积压了几个小时!

作者:中华石杉 来源:https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/mq-time-delay-and-expired-failure.md 一.面试题 如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决? 二.面试官心里分析 你看这问法,其实本质针对的场景,都是说,可能你的消费端出了问题,不消费了,或者消费的极其极其慢.接着就坑爹了,可能

set QUOTED_IDENTIFIER ON事故记录

作业执行失败: 看了一下执行脚本 delete  top(8000) from "interface"."完成" where  loggid in( select loggid from "interface"."完成20150601" ) 然后再sqlserver query执行一下,发现是可以成功的.然后执行语句 set QUOTED_IDENTIFIER ON 再执行作业还是失败的,然后将脚本改为 set QUOTED_