一.发生了什么? 1.那是一个阳光明媚的下午,老婆和她的闺蜜正在美丽的湖边公园闲逛(我是拎包拍照的). 2.突然接到甲方运营小妹的微信:有个顾客线上付款了,但是没有到账,后台卡在微信支付成功(正常状态是充值成功). 我第一反应是第三方充值系统挂了吧(之前第三方系统接口经常超时,各种小问题),然后让运营小妹查下后台的异常提示. 3.过了2分钟之后,我还是不放心,用手机(当时没有背电脑出门)登陆后台看了下,发现后台已经进不去了,猜测可能是我的网络不好(公园的移动信号不给力,只有1格信号). 4.过了…
前言 今天组长在做站内巡检的时候,发现header内有一条meta标签的content显示为乱码. <meta name="description" content="�����…
1.事故描述 本月 8 日上午十点多,我们的基础应用发生生产事故.具体表象为系统出现假死无响应.查看事发时间段的基础应用 error 日志,没发现明显异常.查看基础应用业务日志,银行结果处理的部分普遍很慢,大都在十分钟以上. 2.AWR 报告 向 DBA 要了一下那个时间段的 AWR 报告,发现以下三个地方有些异常: 2.1.CPU 利用率过高 如上图所示,CPU利用率:1883.25分钟DB时间/(16核心*119.45分钟采样时间段时间) = 98.54%,CPU 利用率过高. 2.2.行锁…
可以很明显可以看到我们这个集合的数据严重分布不均匀. 一共有8个分片,面对这个情况我首先想到的是手动拆分数据块,但这不是解决此问题的根本办法. 造成此次生产事故的首要原因就是片键选择上的问题,由于片键选择失误,在数据量级不大的时候数据看起来还是很健康的,但随着数据量的暴涨,问题就慢慢浮出了水面,我们使用的组合片键并不是无规律的,片键内容是线性增长的,这就导致了数据的不正常聚集.由于数据分布不均匀,我们有两个分片的磁盘使用率接近80%,数据还在持续增长,这个问题必须尽快解决. 涉及到此次事故的集合…
管家婆软件工贸版(标准财务+进销存+生产管理)V18.0功能简介 管家婆 工贸版(标准财务+进销存+生产管理) 1.整体介绍 管家婆工贸版系列软件是针对国内中小型生产加工企业,将ERP管理思想与几十万管家婆用户使用经验相融会的成果.该系列软件以生产管理为核心,集采购.销售.存货.生产.工资.固定资产.账务管理等模块于一体,通过对企业采购.销售.存货和生产等经营环节信息的全程记录.传递.跟踪和分析,实现对企业物流.资金流.信息流和生产成本控制等在线动态监控和全方位管理,从而整合和优化企业内部资源.…
一.现象 在服务器上通过curl命令调用一个Java服务的查询接口,半天没有任何响应.关于该服务的基本功能如下: 1.该服务是一个后台刷新指示器的服务,即该服务会将用户需要的指示器数据提前计算好,放入redis中,当用户请求指示器数据时便从redis中获取: 2.指示器涉及到的模型数据更新时会发送消息到kafka,该服务监听kafka消息,收到消息后触发指示器刷新任务: 3.对于一些特殊的指示器,其涉及的项目和模型较多,且数据量比较大,无法通过kafka消息来触发刷新,否则一直处于刷新过程中,便…
引子 经过漫长的等待,儿子终于出生了.欣喜之余,就是各种手足无措,顾此失彼了.因为不懂,心里总是慌慌的,有点小毛病,恨不得一步就到医院. 婆媳育儿观念的差异,让心乱如麻的我,又成了风箱里的老鼠,两个不服软的女人都在考验我的智慧,虽是极力从中斡旋,还是免不了爆发了一场婆媳冲突. 还是智慧少了,估计四大名著还得再读一遍(唬一下人应该还是可以的:-D). 不过话说回来了,虽然苦点,累点(当然了,主要还是媳妇和妈累,媳妇放弃工作,放弃辣椒,放弃方便面,也蛮拼了,我也就打打酱油),但抱着娃,看他那惹人爱的…
伴随着今年linux上面最大一个安全漏洞bash漏洞的出现,我们公司也開始了风风火火的漏洞修复工作,机器一多,也就easy出问题,有台64位的linuxserver一不小心就升级了32位 bash 的rpm,因为root,oracle这些用户默认都是通过/bin/bash来登陆的.这就造成了用户不能登陆server造成了极大的困扰,以下就是应对的办法,因为在生产环境解决的时候没法截图,通过虚拟机的环境来模拟当时的情况: 我们通过删除bash的rpm包的方式来模拟生产商bash包装错的情况: 在这…
前情提要 11月末我司商品服务的MongoDB主库曾出现过严重抖动.频繁锁库等情况. 由于诸多业务存在插入MongoDB.然后立即查询等逻辑,因此项目并未开启读写分离. 最终定位问题是由于:服务器自身磁盘 + 大量慢查询导致 基于上述情况,运维同学后续着重增强了对MongoDB慢查询的监控和告警 幸运的一点:在出事故之前刚好完成了缓存过期时间的升级且过期时间为一个月,C端查询都落在缓存上,因此没有造成P0级事故,仅仅阻塞了部分B端逻辑 事故回放 我司的各种监控做的比较到位,当天突然收到了数据库服…
前言   Insert into select请慎用.这天xxx接到一个需求,需要将表A的数据迁移到表B中去做一个备份.本想通过程序先查询查出来然后批量插入.但xxx觉得这样有点慢,需要耗费大量的网络I/O,决定采取别的方法进行实现.通过在Baidu的海洋里遨游,他发现了可以使用insert into select实现,这样就可以避免使用网络I/O,直接使用SQL依靠数据库I/O完成,这样简直不要太棒了.然后他就被开除了. 事故发生的经过.   由于数据数据库中order_today数据量过大,…