线上服务mcelog负载异常分析处理流程

一、问题概述:

Nginx服务器,HP,有冗余,其中一台服务器mcelog负载比较高,日志秒级别,已经影响了此服务器业务。

tail -f /var/log/mcelog

#注意看此信息是不断循环,注意看

Transaction:Memory scrubbing error
MemCtrl:Corrected patrol scrub error
 Erroroverflow
Corrected  error

#注意看其它信息

CPU16 BANK 9
MCE11

337335    MCi_MISCregister valid
337336    MCi_ADDRregister valid
337337    MCA:MEMORY CONTROLLER MS_CHANNEL1_ERR
337338    Transaction:Memory scrubbing error
337339    MemCtrl:Corrected patrol scrub error
337340   
337341    STATUScc0048c0000800c1 MCGSTATUS 0
337342    MCGCAP1000812 APICID 8 SOCKETID 0
337343    CPUIDVendor Intel Family 6 Model 45
337344    Hardwareevent. This is not a software error.
337345    MCE10
337346    CPU16 BANK 9
337347    MISC90011000010008c ADDR 15e0e2000
337348    TIME1495308194 Sun May 21 03:23:14 2017
337349    MCGstatus:
337350    MCistatus:
337351    Erroroverflow
337352    Correctederror
 
337353    MCi_MISCregister valid
337354    MCi_ADDRregister valid
337355    MCA:MEMORY CONTROLLER MS_CHANNEL1_ERR
337356    Transaction:Memory scrubbing error
337357    MemCtrl:Corrected patrol scrub error
337358   
337359    STATUScc0003c0000800c1 MCGSTATUS 0
337360    MCGCAP1000812 APICID 9 SOCKETID 0
337361    CPUIDVendor Intel Family 6 Model 45
337362    Hardwareevent. This is not a software error.
337363    MCE11
337364    CPU17 BANK 9
337365    MISC90011000010008c ADDR 15e0f8000
337366    TIME1495308194 Sun May 21 03:23:14 2017
337367    MCGstatus:
337368    MCistatus:
337369    Erroroverflow
337370    Correctederror

tail -f /var/log/messages

二、mcelog简单说明

2.1)mcelog此服务是什么?

检查硬件错误,特别是内存和CPU错误的工具

2.2)mcelog工作模式?

cron  trigger (效率高低问题)

daemon (centos目前形式) 默认日志打到/var/log/mcelog

2.3)mcelog安装

yum install mcelog or 编译即可。

三、问题分析:

3.1)error信息:

Transaction:Memory scrubbing error
MemCtrl:Corrected patrol scrub error
Erroroverflow
Corrected  error

注意,通过上面的报错信息可以判断内存可能出了问题,因为mcelog日志报错,则很可能是硬件信息故障。

3.2)其它信息

MCE(Machine Check Exception)是一类计算机硬件错误。可能原因有:

内存报错,内存缓存故障,cpu故障,也可能和主板,总线有关系。

CPU16 BANK 9

CPU 17 BANK 9  ...

bank定义:

传统内存系统为了保证CPU的正常工作,必须一次传输完CPU在一个传输周期内所需要的数据。而CPU在一个传输周期能接收的数据容量就是CPU数据总线的位宽,单位是bit(位)。内存与CPU之间的数据交换通过主板上的北桥芯片进行,内存总线的数据位宽等同于CPU数据总线的位宽,这个位宽就称之为物理Bank。bank:一直想通过bank和上面日志,排查可能哪个插槽有问题。这里希望大家给予提示。

3.3)查看服务器各指示灯:

正常。(这里很意外,不过如果问题刚产生不久,指示灯也不会立马出问题)

3.4)咨询朋友

建议:一般硬件出了问题,建议换内存,备份数据等。

四、处理顺序(renzhiyuan.blog.51cto.com)

4.1)先平滑迁移业务保障业务正常运行。

4.2)备份数据,并确保数据的可用性。

4.3)切勿重启,先尝试清楚内存缓存,inode,目录。排除缓存问题。

4.4)如果负载很高,可考虑关闭mcelog服务。

4.5)hp服务器有硬件分析功能,可先排查。

4.6)准备相同规格内存条,尝试更换内存条(最好不要动每个内存原本的位置,一般内存不是很多,可尝      试,要是能判断哪个插槽出问题,可先替换)

4.7)如果更换内存条无效,则可能其它硬件问题,考虑维修处理。

4.8)以上所有进度和结果,做备案,并及时和领导反映。

时间: 2024-12-05 01:00:09

线上服务mcelog负载异常分析处理流程的相关文章

线上服务应急与技术攻关方法论

海恩法则和墨菲定律 海恩法则指出: 每一起严重事故的背后,必然有29次轻微事故和300起未遂先兆以及1000起事故隐患. 海恩法则强调两点: (1)事故的发生是量的积累的结果: (2)再好的技术,再完美的规章,在实际操作层面,也无法取代人自身的素质和责任心. 根据海恩法则,一起重大事故发生之后,我们要在处理事故和解决问题的同事,还要及时的对同类问题的「事故征兆」和「事故苗头」进行排查并处理,以防止类似问题的再次发生,将问题在萌芽状态就将其解决掉,这可以作为互联网企业线上应急的指导思想. 墨菲定律

线上服务CPU100%问题快速定位实战--转

来自微信公众号 架构师之路 功能问题,通过日志,单步调试相对比较好定位. 性能问题,例如线上服务器CPU100%,如何找到相关服务,如何定位问题代码,更考验技术人的功底. 58到家架构部,运维部,58速运技术部联合进行了一次线上服务CPU问题排查实战演练,同学们反馈有收获,特将实战演练的试题和答案公布出来,希望对大家也有帮助. 题目 某服务器上部署了若干tomcat实例,即若干垂直切分的Java站点服务,以及若干Java微服务,突然收到运维的CPU异常告警. 问:如何定位是哪个服务进程导致CPU

发布或重启线上服务时抖动问题解决方案

发布或重启线上服务时抖动问题解决方案 一.问题描述       在发布或重启某线上某服务时(jetty8作为服务器),常常发现有些机器的load会飙到非常高(高达70),并持续较长一段时间(5分钟)后回落(图1),与此同时响应时间曲线(图2)也与load曲线一致.注:load飙高的初始时刻是应用服务端口打开,流量打入时(load具体指什么可参考http://www.cnblogs.com/amsun/p/3155246.html). 图1 发布时候load飙高 图2 发布时候响应时间飙高 二.问

Linux(2)---记录一次线上服务 CPU 100%的排查过程

Linux(2)---记录一次线上服务 CPU 100%的排查过程 当时产生CPU飙升接近100%的原因是因为项目中的websocket时时断开又重连导致CPU飙升接近100% .如何排查的呢 是通过日志输出错误信息: 得知websocket时时重新 连接的信息,然后找到原因 解决了. 当然这里幸好能通过日志大致分析出原因 那么我就在思考如果日志没有告诉任何信息 但线上CPU还是接近100%那么如何排查呢.所以学习了下排查过程. 通过查阅资料并实践后,这里总结了两种办法.第一种博客满天飞的方法

软件开发交易线上服务_威客平台

革新威客行业的软件开发线上服务交易平台--大大神,在威客行业中现在主要的模式是以移动互联网+线上服务交易+任务发布为主的行业模式.威客行业在不断扩张,但却没有突破重围,达到一个新的高度.大大神平台作为了领先人物突破了威客行业的这个重围.什么是威客?威客是指通过互联网把自己的智慧.知识.能力.经验转换成实际收益的人,他们在互联网上通过解决科学,技术,工作,生活,学习中的问题从而让知识.智慧.经验.技能体现经济价值.因为诚信和制度的问题存在很大弊病,导致工作者成廉价劳动力,各种欺骗行为层出不穷.目前

java线上服务问题排查

1.业务日志相关 如果系统出现异常或者业务有异常,首先想到的都是查看业务日志 查看日志工具: less 或者more grep tail -f filename 查看实时的最新内容 ps:切忌vim直接打开大日志文件,因为会直接加载到内存的 2.数据库相关 java应用很多瓶颈在数据库,一条sql没写好导致慢查询,可能就会带来应用带来致命危害. 如果出现Could not get JDBC Connection .接口响应慢.线程打满等, 需要登录线上库, 查看数据库连接情况:show proc

线上服务 CPU 100%?一键定位 so easy!

转自:  https://my.oschina.net/leejun2005/blog/1524687 摘要: 本文主要针对 Java 服务而言 0.背景 经常做后端服务开发的同学,或多或少都遇到过 CPU 负载特别高的问题.尤其是在周末或大半夜,突然群里有人反馈线上机器负载特别高,不熟悉定位流程和思路的同学可能登上服务器一通手忙脚乱,定位过程百转千回. 对此,也有不少同学曾经整理过相关流程或方法论,类似把大象放进冰箱要几步,传统的方案一般是4步: top oder by with P:1040

(转) 发布或重启线上服务时抖动问题解决方案

转自 http://www.cnblogs.com/LBSer/p/3703967.html 相关: load.jstack.Java编译.Java运行模式 一.问题描述       在发布或重启某线上某服务时(jetty8作为服务器),常常发现有些机器的load会飙到非常高(高达70),并持续较长一段时间(5分钟)后回落(图1),与此同时响应时间曲线(图2)也与load曲线一致.注:load飙高的初始时刻是应用服务端口打开,流量打入时(Load指的是运行队列(run-queue)的长度:L=等

线上系统/tmp 目录不断增长分析与总结

1.问题描述 系统配置为单核4G, web 工程配置堆2G,  /tmp目录 二进制文件不断增加,平均一天增加20G, 手动清理/tmp目录,重启系统,问题依旧. 2.分析 /tmp 目录存放系统运行时产生的临时文件.在Redhat-like系统上,会定期清理/tmp目录下10天未访问的文件.这个机制保证了,linux不会像windows那样在较长时间运行后变得臃肿不堪. 清理脚本位于/etc/cron.daily/tmpwatch,内容如下, #! /bin/sh flags=-umc /us