故障排查实战案例——某电器ERP系统日志暴增

前言

  本篇文章写在新春佳节前夕,也是给IT运维朋友一个警醒,在春节长假前请妥善体检自己的系统安心过个年。

  千里之堤毁于蚁穴,一条看似简单的语句就能拖垮整个系统,您的SQL Server很久没体检了吧? 就像一块藏着刀片的蛋糕!怎能安度春节?

  日志暴增的问题处理过很多,这只是很常规的一次,但是对于不是很熟练的运维兄弟,可能日志暴增这样的问题会被一带而过,或者解释成突发情况而不去处理,那么隐患依然存在,在春节这样的长假发生可怎么办呢?

  本文使用的工具:SQL专家云平台专业体检工具 :www.zhuancloud.com

场景描述

  本案例是一个很成熟的ERP厂商的产品,接到用户紧急电话,说他们日志突然暴增磁盘告警,50G的数据库日志已经达到200G。

  

  看到这有的看官可能会说,肯定是没定时做日志备份导致日志不断变大!或者说才200G 一点也不大呀!

  没错,日志不备份缺失会有这样的问题,但这情景是小儿科,不会拿出来写案例的,200G 确实也不大,但要分场景,在此客户平均10个G 的场景下 200G已经是爆炸式的问题了!

  为什么会拿出来写案例,就是因为想要告诉大家排查这样问题的思路,不要让这样的暴增单纯的说成突发情况!

问题分析

  拿到收集文件我直入主题,查看日志的增长情况、写入状态、问题时间点等信息

  

  在日志的分配空间我们了解到日志是在11点43分左右突然暴增一直增长到13点左右达到240G

  

  分配空间也是同样的情况在11点43分左右暴增,后期在1点半的下降就是日志备份让使用空间被释放。

  

  

  日志文件的写入也符合这个时间点,在11点43分左右写入达到40MB/秒,并且持续了1个多小时。

  

  通过这几张图,我们很清晰的就能定位到日志暴增的时间点,下面只要找到对应时间点的语句即可!

  我的排查思路有些不同,持续1个小时的写入,必然伴随着日志文件的增长(文件增长设置固定值100MB),这里需要提一下:这就是固定增长的好处,因为当达到240G 如果按照默认10%增长,那么一次需要增24G 磁盘已经没有那么多空间,则会导致报错,系统中断!

  回到排查思路,这里我直接查看对应时间点系统的等待情况:

  

  直接找到日志文件增长的等待类型,查看运行的语句确实运行时间是从11点15到13点15,和日志增长的情况吻合!!

  就这样,只花了10分钟就定位到问题,找到语句,由于存储过程加密,我无法看到里面的代码,但是暴增的语句已经找到,需要软件厂商自行处理啦!!

  就是这样简单,打完收工!所以不要放过这样的问题排查!

后怕

  为什么说不能放过这样问题的排查!!!

  首先,这个系统正准备上集群,集群大家都知道单机变多台,必然涉及到数据的同步,同步是要有消耗的,对写入的性能会有影响,细心的小伙伴可能已经看到这个语句消耗了多少资源,逻辑读,写,影响行数有多少了

  

  没错,64亿的逻辑读!为什么会产生这么大的日志,导致暴增!因为写入1亿次,影响行数19亿,并且执行的时间不是在夜间的维护期,而是在中午11点15开始,这么大的处理在集群方案部署的时候一定要高度警惕,这么大的同步量完全可能导致集群严重延迟,甚至宕机!所以这不单单是一次日志暴增问题的排查了,也是对系统功能更加细致的了解,如果这样的问题没有及早发现,就算集群后期测试也不一定会被测试到,进而导致集群上线后的悲催。

PS:继逻辑读 23亿,34亿,45亿后这个案例有刷新了我见过的最大逻辑读 64亿!

  纪念一下

--------------博客地址---------------------------------------------------------------------------------------

博客地址 http://www.cnblogs.com/double-K/

 

欢迎转载,请注明出处,谢谢!

-----------------------------------------------------------------------------------------------------

总结

  系统运维就是保证系统平稳运行的工作,看似简单但个中奥妙和心酸只有运维人才能体会,不要放过每一个细节,一个简单突发情况处理可能引出一系列问题,而解决这些问题又是保证系统平稳运行基础,请给运维人多一些关爱吧,比如春节来个大红包,哇哈哈哈哈!!

  有的小伙伴已经开始春节休假了,祝大家新春快乐,系统平安!

----------------------------------------------------------------------------------------------------

注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

时间: 2024-10-11 02:28:57

故障排查实战案例——某电器ERP系统日志暴增的相关文章

数据库实战案例—————记一次TempDB暴增的问题排查

前言 很多时候数据库的TempDB.日志等文件的暴增可能导致磁盘空间被占满,如果日常配置不到位,往往会导致数据库故障,业务被迫中断. 这种文件暴增很难排查,经验不足的一些运维人员可能更是无法排查具体原因,导致问题不能彻底解决. 场景描述 客户系统比较稳定,用了5台机器做了AlwaysOn高可用组,完全实现了读写分离.磁盘也做了规划,主库日常操作TempDB需求在20G以下,所以TempDB所在的磁盘只配置了100个G的空间. 本案例是客户突然接到监控报警,显示TempDB磁盘空间不足,可用空间不

【集群实战】NFS服务常见故障排查和解决方法

NFS,全名叫Network File System,中文叫网络文件系统,是Linux.UNIX系统的分布式文件系统的一个组成部分,可实现在不同网络上共享远程文件系统. NFS由Sun公司开发,目前已经成为文件服务的一种标准之一(RFC1904,RFC1813). 其最大的功能就是可以通过网络,让不同操作系统的计算机可以共享数据,所以可以把NFS看做是一个文件服务器.NFS缺点是其读写性能比本地硬盘要差一些. 一.NFS服务常见故障排查: NFS服务出现了故障,主要从以下几个方面检查原因: (1

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程(高俊峰)

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程 第一课 Linux运维经验分享与思路 1.一般把主机名,写到hosts下    127.0.0.1    hostname,因为很多应用要解析到本地.oracle没有这个解析可能启动不了. 2.注释掉UUID以及MAC地址,需要绑定网卡的时候,这个可能会有影响. 3.磁盘满了无法启动,  var下木有空间,无法创创建PID等文件,导致文件无法启动,按e   进入single  然后b  重启进入单用户模式. 4.ssh登陆系

运维实战案例之“Argument list too long”错误与解决方法

作为一名运维人员来说,这个错误并不陌生,在执行rm.cp.mv等命令时,如果要操作的文件数很多,可能会使用通配符批量处理大量文件,这时就可能会出现"Argument list too long"这个问题了. 1.错误现象 这是一台Mysql数据库服务器,在系统中运行了很多定时任务,今天通过crontab命令又添加了一个计划任务,退出时发生了如下报错: #crontab -e 编辑完成后,保存退出,就出现下面如下图所示错误: 2.解决思路 根据上面报错的提示信息,基本判定是磁盘空间满了,

运维实战案例之文件已删除但空间不释放问题解析

1.错误现象 运维的监控系统发来通知,报告一台服务器空间满了,登陆服务器查看,根分区确实没有空间了,如下图所示: 这里首先说明一下服务器的一些删除策略,由于Linux没有回收站功能,我们的线上服务器所有要删除的文件都会首先移动到系统/tmp目录下,然后定期清除/tmp目录下的数据.这个策略本身没有问题,但是通过检查发现这台服务器的系统分区中并没有单独划分/tmp分区,这样/tmp下的数据其实是占用了根分区的空间.既然找到了问题,那么删除/tmp目录下一些大数据即可,执行如下命令,检查/tmp下最

Rsync 12种故障排查及思路

Rsync 故障排查整理 Rsync服务常见问题汇总讲解: ============================================================================================== 1 客户端的错误现象:No route to host rsync服务端开启的iptables防火墙 [[email protected] tmp]# rsync -avz /etc/hosts [email protected]::backup r

Mysql DBA 高级运维学习笔记-MySQL备份与恢复实战案例及生产方案

1.全量备份与增量备份 1.1 全量备份 全量数据就是数据库中所有的数据,全量备份就是把数据库中所有的数据进行备份. 备份所有库: mysqldump -uroot -p123456 -S /data/3306/mysql.sock -F -B –A gzip >/server/backup/mysq_backup_$(date +%F).sql.gz 备份一个库: mysqldump -uroot -p123456 -S /data/3306/mysql.sock -F -B linzhong

Mysql运维管理-MySQL备份与恢复实战案例及生产方案17

1.全量备份与增量备份 1.1 全量备份 全量数据就是数据库中所有的数据,全量备份就是把数据库中所有的数据进行备份. 备份所有库: mysqldump -uroot -p123456 -S /data/3306/mysql.sock -F -B –A gzip >/server/backup/mysq_backup_$(date +%F).sql.gz 备份一个库: mysqldump -uroot -p123456 -S /data/3306/mysql.sock -F -B linzhong

S7700交换机组网部分终端上不了网故障排查

本案例是多年之前遇到的一个真实故障处理过程,之后回想整个过程觉得比较有意思,因此将故障排查记录下来,现在将其分享出来,在其中隐藏了部分敏感信息.由于当时主要是做华为的服务,客户报的故障为S7700交换机的问题,因此本故障排查之初即在于S7700交换机.往往客户报的故障只是一个现象,而该现象又往往具有不确定性,因此我们需要认真的去分析网络环境,以及数据流走向,抓往一个故障点,突破一个故障面的问题.一.问题描述 两台S7700交换机配置VRRP,所有的流量主要走S3700.主S7700交换机.主H3