1.事故描述 本月 8 日上午十点多,我们的基础应用发生生产事故.具体表象为系统出现假死无响应.查看事发时间段的基础应用 error 日志,没发现明显异常.查看基础应用业务日志,银行结果处理的部分普遍很慢,大都在十分钟以上. 2.AWR 报告 向 DBA 要了一下那个时间段的 AWR 报告,发现以下三个地方有些异常: 2.1.CPU 利用率过高 如上图所示,CPU利用率:1883.25分钟DB时间/(16核心*119.45分钟采样时间段时间) = 98.54%,CPU 利用率过高. 2.2.行锁…
可以很明显可以看到我们这个集合的数据严重分布不均匀. 一共有8个分片,面对这个情况我首先想到的是手动拆分数据块,但这不是解决此问题的根本办法. 造成此次生产事故的首要原因就是片键选择上的问题,由于片键选择失误,在数据量级不大的时候数据看起来还是很健康的,但随着数据量的暴涨,问题就慢慢浮出了水面,我们使用的组合片键并不是无规律的,片键内容是线性增长的,这就导致了数据的不正常聚集.由于数据分布不均匀,我们有两个分片的磁盘使用率接近80%,数据还在持续增长,这个问题必须尽快解决. 涉及到此次事故的集合…
有个获取登陆用户是否每天第一次登陆系统需求,考虑不需要入库操作,就用redis设置key每天凌晨0点删除 /** * 获取当前时间到凌晨12点的秒数 * @return */ public Long getSecondsNextEarlyMorning() { Calendar cal = Calendar.getInstance(); cal.add(Calendar.DAY_OF_YEAR, 1); cal.set(Calendar.HOUR_OF_DAY, 0); cal.set(Cale…
总结Istio 生产环境用户流量接入方案 方案1 Client -> istioGateway域名(微服务) -> VritualService匹配路由并绑定网关 -> DestinationRule转发Pod规则 -> PodLabel -> Pod 基本xds 转发: lds四层端口 -> rds七层服务 -> cds基准信息 -> eds真实 pod endpoint端口 架构图如下 方案2 Client -> istioGateway域名(微服…
一次因生产事故与chatGpt的对话 前言:生产出现了一个内存溢出的事故,记录错误信息.错误日志如下 org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: Java heap space at org.springframework.web.servlet.DispatcherServlet.doDi…
入职多年,面对生产环境,尽管都是小心翼翼,慎之又慎,还是难免捅出篓子.轻则满头大汗,面红耳赤.重则系统停摆,损失资金.每一个生产事故的背后,都是宝贵的经验和教训,都是项目成员的血泪史.为了更好地防范和遏制今后的各类事故,特开此专题,长期更新和记录大大小小的各类事故.有些是亲身经历,有些是经人耳传口授,但无一例外都是真实案例. 注意:为了避免不必要的麻烦和商密问题,文中提到的特定名称都将是化名.代称. 0x00 大纲 目录 0x00 大纲 0x01 事故背景 0x02 事故分析 0x03 事故原因…
入职多年,面对生产环境,尽管都是小心翼翼,慎之又慎,还是难免捅出篓子.轻则满头大汗,面红耳赤.重则系统停摆,损失资金.每一个生产事故的背后,都是宝贵的经验和教训,都是项目成员的血泪史.为了更好地防范和遏制今后的各类事故,特开此专题,长期更新和记录大大小小的各类事故.有些是亲身经历,有些是经人耳传口授,但无一例外都是真实案例. 注意:为了避免不必要的麻烦和商密问题,文中提到的特定名称都将是化名.代称. 0x00 大纲 目录 0x00 大纲 0x01 事故背景 0x02 事故分析 0x03 事故原因…
一.发生了什么? 1.那是一个阳光明媚的下午,老婆和她的闺蜜正在美丽的湖边公园闲逛(我是拎包拍照的). 2.突然接到甲方运营小妹的微信:有个顾客线上付款了,但是没有到账,后台卡在微信支付成功(正常状态是充值成功). 我第一反应是第三方充值系统挂了吧(之前第三方系统接口经常超时,各种小问题),然后让运营小妹查下后台的异常提示. 3.过了2分钟之后,我还是不放心,用手机(当时没有背电脑出门)登陆后台看了下,发现后台已经进不去了,猜测可能是我的网络不好(公园的移动信号不给力,只有1格信号). 4.过了…
这是悟空的第 170 篇原创文章 官网:http://www.passjava.cn 你好,我是悟空. 本文主要内容如下: 一.前言 最近项目的生产环境遇到一个奇怪的问题: 现象:每天早上客服人员在后台创建客服事件时,都会创建失败.当我们重启这个微服务后,后台就可以正常创建了客服事件了.到第二天早上又会创建失败,又得重启这个微服务才行. 初步排查:创建一个客服事件时,会用到 Redis 的递增操作来生成一个唯一的分布式 ID 作为事件 id.代码如下所示: return redisTemplat…
伴随着今年linux上面最大一个安全漏洞bash漏洞的出现,我们公司也開始了风风火火的漏洞修复工作,机器一多,也就easy出问题,有台64位的linuxserver一不小心就升级了32位 bash 的rpm,因为root,oracle这些用户默认都是通过/bin/bash来登陆的.这就造成了用户不能登陆server造成了极大的困扰,以下就是应对的办法,因为在生产环境解决的时候没法截图,通过虚拟机的环境来模拟当时的情况: 我们通过删除bash的rpm包的方式来模拟生产商bash包装错的情况: 在这…