一次核心线上磁盘差点爆满坑人事件... 推荐 原创 任志远Ray 2017-08-27 05:41:51 博主文章分类:经历 ©著作权 文章标签 核心 一次 线上磁盘 文章分类 Oracle 数据库 ©著作权归作者所有:来自51CTO博客作者任志远Ray的原创作品,谢绝转载,否则将追究法律责任 每天忙的博客都没时间更新,(近期会更新rac,ods等方面)此刻的我可以下班了(夜班一周一两次吧),因为换了工作,对整体系统架构及业务都没特别熟悉。本想现在回家休息,可是心情不怎么美丽,刚刚经历了一场核心磁盘差点爆满事件,有点不痛快,吐槽一下,也算是分享一下自己的经验吧!情况是这样的:夜晚做一个核心跑批(涉及到几万用户的账户资金扣款,不容出错),在二次逻辑导库(Oracle)的时候,突然接到数据中心的电话,两台 主机1 主机2 应用服务器下的/fns目录96%了,说可不可以快点清理一下。(数据中心有集中式监控,但是操作大部分我们处理,何况是夜晚,技术支持不在)于是尽快排查,因为应用服务不知道root,而且磁盘空间都很紧张,权限很严格。找到数据库备份目录后,判断了一下dmp文件大小,当前备份增长很快,一会儿%98了。还有8G空间,但是根据备份文件比较,还有20G才备份完。此刻和时间赛跑...不爽1:1)%96了才告警,这不是坑人么,阈值怎么设置的啊!2)核心应用恰好在导库,删错东西,影响批扣,领导肯定不高兴,甚至追责任。目前发现仅仅/tmp下有可怜的空间,和数据中心打电话问有没有之前备份,貌似不是和数据库相关的人值班,给不了我确切答案,想和领导打电话确认可不可以临时删除之前备份,电话不通。不爽2:1)为什么磁盘空间那么小,真的怀疑我在操作假的核心服务器,短时间还扩容不了。(机房异地)2)直属领导联系不通,虽然知道有上个月的归档,但是没得到允许不敢删除啊。于是告诉自己冷静,冷静。此刻只剩下4G空间,如果影响批量,就麻烦了。紧急在/tmp下创建临时目录,将一些dmp.gz mv过去,剩余空间在增长(gz文件 2-3G,dmp文件,40-50G),还好先缓解一下,但是我得至少腾出20G,才能解决问题。想想可不可以用tar 压缩,然后加参数删除源文件,刚执行压缩到tmp下,立马觉得不行,ctrl+c,同时立刻报警 /tmp 使用率 %100。因为文件太大了。不爽3:1)脚本被修改,为什么没有接到通知,临时压缩有风险啊 哎。。。2)脑子已经不敢确定xz gzip tar压缩,压缩过程会不会有临时处理文件,那样死的更快。两台应用挂载同一个目标主机盘,gpfs文件系统格式,还没有确定用的什么方式挂载。(nfs或者其它),但是我已经没时间想这些了,空间又不够了 %98了。先在/tmp下创建临时目录,缓解一下压力。评估了一下,两个/tmp各分担一下,恰好批量完成,剩下4G空间。不爽4:1)如果两台tmp空间不够的话,大家如果是我怎么办?(后期尝试密码碰运气进入oracle用户进去了)此刻,批量完成,心里松了口气。看着可怜的4G空间,心里不知道该说些什么。然后我想了一下,gzip,xz压缩是应该可以的(因为之前从来没有遇到过磁盘空间不够的情况,没深入理解这两个命令压缩原理),压缩之后,空间恢复。不爽5:1)脚本被修改没通知,领导肯定会问。不确定是不是同事,还是厂家 哎。。。万一是前者,又涉及到 工作没交接清楚问题,我也不好说。2)因为和领导打了电话,领导肯定会问情况,还没想好怎么说。3)工作交接,处理过程,以及建议等后续问题。然后,我困了,要回家休息了,也许这只是一个意外吧!不知道大家遇到这种情况,该怎么处理!因为公司东西是机密,不可以透露,这里仅仅分析我的个人经历吧,个人情感,经验博客,谢绝转载! 赞 收藏 评论 分享 举报 上一篇:corosync+pacemaker+http高可用操作手记 下一篇:Oracle RAC集群本地时间和远程时间不一致? 提问和评论都可以,用心的回复会被更多人看到 评论 发布评论 全部评论 () 最热 最新 相关文章 记一次redis热key、大key引发的线上事故 背景Redis中间件,我们主要是用来做缓存,缓解数据库的访问压力,我们搭建的是redis集群在一个风和日丽的下午,突然收到运维的报警信息运维:小李,你们使用的redis中间件所在的服务器,有大量的流量流出,宽带快要占满了,网卡都冒烟了,严重影响其他服务,快速排查解决下,如果一时半会解决不了,我们只能kill掉redis的进程,避免影响其他服务小李:我们立刻排查,有需要协助的,请你们帮忙我们redi 数据 Redis redis 记一次生产KubeSphere日志无法正常采集事件 一、前言时间可追溯到2023年11月7号下午,研发同事反馈项目线上日志平台某个服务只能不能看近期的日志了,于是乎,我登上KubeSphere平台进行查看,正常研发反馈一样,日志收集展示只停留在10月15号那天,之后就没有了,另外其它的服务是正常的二、问题跟踪定位分析结合已有的知识积累做了如下猜想,是不是日志系统对应的PVC存储卷是否被打满了,导致日志索引被锁定。间接影响服务的日志采集呢?还有一方面 Kubesphere日志 记一次网络架构调整 一、说明公司K8S集群配置需要,需要重新调整网络结构网络架构:网络架构说明:是一台路由器,接一台交换机,下面串两台交换机路由器:192.168.10.2523台交换机:没有做任何配置(12、13、14机柜交换机)二、需求新集群需要复用老集群的3台机柜交换机新集群总体上包含多个单独子网的网段,每个网段中有一个集群新集群的master节点需要继续使用老集群中的两台ESXI服务器三、新架构拓扑思路说明: 网络架构 子网 单臂路由 记一次磁盘空间爆满导致的持久化报错 环境:3.0.7 redis八节点集群4主4从 开发测试环境操作:清除集群持久化数据 #redis-cli -c -p 6383 -h 172.31.103.238 登陆之后cluster nodes 察看节点信息 登陆master节点进行删除 flushall在其中一个节点执行时抱错:172.31.103.238:6383> flushdb(error) MISCONF Redi redis 抱错处理 记录一次linux线上服务器被黑事件(转) 1.原因:本来在家正常休息了,我们放在上海托管机房的线上服务器突然蹦了远程不了,服务启动不了,然后让上海机房重启了一次,还是直接挂了,一直到我远程上才行。 2.现象:远程服务器发现出现这类信息Hi, please view: http://pastie.org/pastes/10800563/text?key=hzzm4hk4ihwx1jfxzfizzq&n 记一次服务器被黑的事件 一次线上fullgc排查 .#背景 接到机器告警,告警信息是:【(SpanFullGCCollectionCount:18)FGC次数:18.0 FGC时间:32 解决方案 类加载 重新启动 磁盘爆满 linux操作系统中,经常会遇到磁盘空间满的问题。遇到这样的问题,先查下是什么文件过大或过多引起的,至于引起这个更深一层的原因,先不探讨先使用 df -h 查看挂载点情况du -s -h ./*看下目录的占用情况(如下图)。(或者du -m --max-depth=1或du -h --max-depth=1du:用于统计linux中文 linux 空间 操作系统 这一次,我差点就废了! “加班996,住院ICU!“虽然这句话经常被程序员们拿来自黑,但是它太真实了!这一次,小鹿就差点废了!上周五,发完最后一篇文,腰疼的属实厉害,无论是坐着还是站着,都疼的要命,实在受不了,就去医院检查了一下,结果可想而知。去年10月份,回家帮家里浇地干活,在高处抬重物,腰部用力太大,一下就晃到腰了,自从那时候,腰部就会出现偶尔的疼痛。当时去跌打扭伤的小诊所看了看,说是没什么大事,伤筋动骨100天嘛, Java 记一次差点翻车的生产变更 今天不谈技术,讲一下前不久变更差点翻车的事。 运维 变更 记一次路由器BUG—大写的坑人 斐讯路由器Phicomm路由器Tenda水星……想必,用户都知道这些问题:1,重启可以解决的问题都不称之为问题;2,有时候重启都难以解决,必须重新设置;甚至回复出厂设置;当别人的设备终端链接好好的网络,你的出问题了why? 我人品这么差?NO,太不自信了。可能需要重新设置一下“斐讯路由器Phicomm路由器”... 重启 ico IT 记一次redis线上问题 阅读大概需要4分钟一个生产中的问题,建议阅读四颗星现象分析可能原因调查原因概念详细介绍紧急处理办法预防办法现象redis-cluster某个分片内存飙升,明显比其他分片高很多,而且持续增长。并且主从的内存使用量并不一致。(个别可能导致服务无法启动)分析可能原因对于 redis 出现这种现象,一般都会从这个这几个方面考虑redis-cluster的bug (这个应 经验分享 记一次线上OOM问题 首先是jmap -dump:format=b,file= file.hprof导入MAT工具定位的问题是StandardManager和Sta 内存泄漏 用户信息 查看源码 记一次线上故障处理 前言 下面信息裁剪了一些,有的不确定了就拍脑袋定了,大体情况还是和实际相似。 整体过程 最开始接到告警 一个周六的 9:00 接到钉钉告警A应用线上 499 数量大量增加, A应用的背景介绍 先说下A应用的背景,我们A应用每天上亿次访问,主要是给别的厂商买接口的,按照各个厂商的调用量收钱,A 应用的 kafka nginx 服务器 记录一次差点被诈骗的事情经过 看过那么多次的诈骗,一直以为这样的事情不会发生在我的身上,我那么聪明,怎么可能被骗钱?事情的经过是这样的。秋招后, 被骗 互联网公司 一次搞懂SpringBoot核心原理:自动配置、事件驱动、Condition 前言 SpringBoot是Spring的包装,通过自动配置使得SpringBoot可以做到开箱即用,上手成本非常低,但是学习其实现原理的成本大... spring tomcat 加载 一次线上tomcat假死问题排查 线上部署了一个java web服务到tomcat中,前面有nginx进行轮训。发现一个问题,总是有个一个tomcat莫名其 sed tomcat java 记一次 Kafka 集群线上扩容 前段时间收到某个 Kafka 集群的生产客户端反馈发送消息耗时很高,于是花了一段时间去排查这个问题,最后该集群进行扩容,由于某些主题的当前数据量实在太大,在对这些主题迁移过程中花费了很长一段时间,不过这个过程还算顺利,因为 Java 记一次mysql线上问题排查 背景是这样的,我们有个系统每天都会调起多个定时任务,首先quartz每分钟会调起一次检查时间的任务,如果发现时间到达设定的任务执行时间,java代码会向数据库里写入一条记录 mysql 数据库 java 定时任务 连接池 记一次惊险的线上事故 起因:最近上线了一版关于敏感内容过滤的一个需求,半夜上线时,一切正常,but....在第二天中午时段,突然报警并有线上反馈相关功能有问题,查elk日志显示相关接口耗时很大,并且有部分连接都超时了(包括redis mysql 以及部分调用外部的http请求也是,系统响应巨慢,平常几毫秒十几毫秒的接口,突然变的无比的慢)本来是午饭午休时间,但是看到这些问题,瞬间我就清醒了,吓得我浑身哆嗦。排查说清这次 文件描述符 重启 贴图 记一次Postgres CPU爆满故障 问题描述 公司项目测试环境调用某些接口的时候,服务器立即崩溃,并一定时间内无法提供服务。 问题排查 服务器配置不够 第一反应是服务器需要升配啦,花钱解决一切!毕竟测试服务器配置确实不高,2CPU + 4Gib,能干啥?不过问题是今天突然发生的,而且说崩就崩。凭着严谨的态度,还是要刨根问底地找下问题。 ... Postgres CPU CPU爆满故障