监控报警内存 90%+排查记录

从报警到根因:Java线上问题排查实战手册(附完整命令集) 本文构建了一套完整的Java线上问题排查体系,提出三大核心原则:先恢复后排查、最小侵入性和交叉验证。详细介绍了四类典型问题的排查路径:CPU飙高(通过top、jstack和火焰图定位)、内存泄漏(使用jstat监控GC,jmap生成堆转储)、线程池耗尽(分析线程状态)和死锁检测。强调预防优于排查,建议标准化JVM参数、建立应用监控和检查清单。最后指出真正的专家应通过监控体系、规范标准和预案演练来预防问题发生。附常用命令速查表,帮助开发者系统化解决生产问题。 阅读详情

一、如何定位线上服务 CPU 飙升问题?——从进程到代码行的完整排查流程

最近天天邮件90%,真烦,决定撤底解决一下。本文记录排查流程,从进程 → 线程 → 代码堆栈,层层深入,最终锁定“元凶”。

本文适合有一定 Linux 运维基础、熟悉 Java 或其他 JVM/多线程语言的开发者阅读。


二、第一步:登录服务器,查看高 CPU 进程

使用 top 命令查看系统整体 CPU 使用情况:

top

在输出中,按 P(大写) 可按 CPU 使用率降序排列。你会看到类似:

PID   USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
12345 deploy    20   0 8542340 2.1g  18744 S 108.3 13.2   123:45 java

这里的关键信息:

  • PID = 12345:高 CPU 占用的进程 ID。
  • %CPU = 108.3:说明该进程使用了超过 1 个 CPU 核心(多线程并发)。

✅ 记下这个 PID,它是后续排查的起点。


三、第二步:查看该进程中高 CPU 的线程

一个进程包含多个线程。我们需要找出是哪个线程在“作妖”。

使用 ps 命令查看该进程下的所有线程及其 CPU 占用:

ps -mp 12345 -o THREAD,tid,time,%cpu

输出示例:

USER     TID %CPU  TIME
deploy  28512 15.2  12:34
deploy  28513  2.1   3:21
deploy  28514  0.5   1:02
...
  • TID = 28512:线程 ID(十进制)。
  • %CPU = 15.2%:该线程占用了大量 CPU。

✅ 找到 CPU 占用最高的 TID(如 28512)。


四、第三步:将 TID 转换为十六进制

JVM 的线程 dump(jstack)中,线程 ID 是以 十六进制 形式显示的。因此需要转换:

printf "%x\n" 28512

输出:

6f60

✅ 记下十六进制 TID:0x6f60(实际使用时去掉 0x,直接用 6f60)。


五、第四步:抓取线程堆栈,定位代码

使用 jstack(适用于 Java 应用)导出当前进程的线程快照:

jstack 12345 > jstack.log

然后在 jstack.log 中搜索十六进制 TID:

grep -A 30 "6f60" jstack.log

你会看到类似内容:

"Thread-123" #68 prio=5 os_prio=0 tid=0x00007f8a6f60 nid=0x6f60 runnable [0x00007f8a12345000]
   java.lang.Thread.State: RUNNABLE
        at com.example.service.DataProcessor.process(DataProcessor.java:45)
        at com.example.service.DataProcessor.lambda$handle$0(DataProcessor.java:32)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

🎯 关键信息:

  • 线程名:Thread-123
  • 代码位置:DataProcessor.java 第 45 行
  • 状态:RUNNABLE(正在运行,可能死循环或高频计算)

六、分析可能原因

常见导致 CPU 飙升的原因包括:

  • 死循环(如 while(true) 忘记 break)
  • 高频 I/O 或反射操作(如频繁 JSON 序列化)
  • 正则表达式回溯爆炸
  • HashMap 在高并发下形成死链(旧版 JDK)
  • 自旋锁或 busy-wait 逻辑

在你的代码中,重点检查堆栈顶部的方法逻辑。


七、补充:非 Java 应用怎么办?

  • Go/C++/Python:可用 perf 工具采样:
    perf top -p 12345
    
    或生成火焰图(Flame Graph)分析热点函数。
  • 通用方法:strace -p <PID> 查看系统调用,但可能影响性能,慎用。

总结:排查流程图

CPU 飙升报警
     ↓
top → 找到高 CPU PID
     ↓
ps -mp <PID> → 找到高 CPU TID(十进制)
     ↓
printf "%x" <TID> → 转十六进制
     ↓
jstack <PID> | grep <hex TID> → 定位代码行
     ↓
修复代码 + 压测验证

示例场景回顾

假设你发现:

  • PID = 285
  • TID = 28512(十进制)→ 十六进制 = 6f60
  • jstack 显示线程卡在 FileReader.read() 死循环

那你就可以立即检查该读取逻辑,很可能是未正确处理 EOF 或缓冲区。


希望这篇整理能帮助大家在面对 CPU 飙升问题时,不再手忙脚乱。性能问题不可怕,可怕的是没有排查路径。掌握这套方法,你就能在“甜蜜约会”之余,依然做团队中最稳的救火队员 💪!

欢迎在评论区分享你的排查经历,或者提出更复杂的场景,我们一起攻克!


记一次RAID5阵列卡蜂鸣器误报警的排查与静音实战 本文详细记录了RAID5阵列卡蜂鸣器误报警的排查过程与解决方案。通过分析阵列卡报警机制,提供了等待重构完成、删除重建阵列、临时静音和永久关闭蜂鸣器等四种实战方法,并探讨了数据重要性、重构进度等决策因素。文章还分享了预防措施,如定期检查硬盘健康度和合理规划RAID级别,帮助IT运维人员有效应对类似问题。 阅读详情

相关推荐

企业级开发和运维中,Shell 脚本常用于自动化运维、批量处理、监控报警

phonenight的博客 641

【线上问题】线上服务器内存使用量已达到90%报警-内存泄漏

2016-05-06中午11:56,收到“[sentry2]2016-05-06 11:56:09 xxxxxxhost xxx.xxx.xxx.xxx 内存使用已达到90.18%”报警。首先在脑海浮现的,应该哪里出现内存泄漏了。 一、确认问题 马上到 Sentry 监控系统查看了该服务的“服务器监控”指标,发现其中2台机器的内存使用量都超过了90%,另外2台尽然没有监控数据(以前是...

简放视野的专栏 7037

从报警到定位:我是如何用jmap+MAT三小时解决线上JVM内存飙升的

本文详细记录了作者在线上JVM内存飙升告警后,如何利用jmap工具获取堆内存快照,并结合MAT(Memory Analyzer Tool)进行深度分析,在三小时内成功定位并解决内存泄漏问题的全过程。文章重点分享了生产环境安全dump、MAT分析大型堆转储文件的实战技巧,并探讨了Spring生态下常见的内存陷阱与防范措施。

weixin_28273593的博客 394

从报警到定位:一次完整的JVM堆外内存泄漏排查流水账

本文详细记录了从监控报警到最终定位JVM堆外内存泄漏的全过程。通过NMT、pmap和gdb等工具的多维分析,发现FastJSON的ASM动态类生成导致元空间泄漏,并提供了修复方案与防御措施。文章为开发者提供了完整的堆外内存泄漏排查方法论和工具链建议。

egg99的博客 931

SpringBoot内存泄漏排查:11种实战方法与工具详解

内存泄漏是Java应用中常见的性能杀手,尤其在SpringBoot框架中,自动装配和依赖注入机制可能引发隐蔽的对象持有问题。理解JVM内存管理原理是诊断基础,通过GC日志分析、堆转储检查等技术手段,可以定位ThreadLocal误用、缓存失控等典型场景。工程实践中,结合JDK工具链(如jmap、jstack)与Arthas等诊断工具,能有效应对生产环境突发OOM问题。本文基于电商系统百万级日活实战经验,详解从基础监控到高级分析的完整解决方案,帮助开发者构建可靠的内存治理体系。

weixin_34128839的博客 346

当服务器报警响起:CPU、内存、磁盘使用率飙升的诊断与处置

某微服务架构的支付系统报警,主节点的 CPU 使用率 90%,内存 85%,从节点磁盘 I/O 高企。假设你运营一个电商平台,双十一促销期间,订单量暴增导致 CPU 使用率飙到 95%,内存占用 90%,磁盘 I/O 接近瓶颈。某服务器 CPU 使用率 100%,内存 95%,运行 netstat -tunap,发现大量来自未知 IP 的 TCP 连接。检查 /var/log/syslog 或 /var/log/messages,寻找异常事件,如 OOM Killer 触发或内核错误。

大模型大数据攻城狮的专栏 933

内存兼容性故障排查:从开机报警到系统蓝屏的完整解决方案

内存是计算机的核心组件,负责数据的临时存储与高速交换。其工作原理基于主板内存控制器与内存条SPD芯片中预设的频率、时序、电压等参数进行协同工作。稳定的内存子系统对于系统性能和数据完整性至关重要,不兼容或不稳定的内存会直接导致开机失败、系统崩溃和数据损坏。在工程实践中,当插入未知或非标内存时,常因SPD信息不匹配或电气参数超出主板兼容性列表(QVL)范围,而触发开机报警(POST失败)或后续的系统蓝屏(如IRQL_NOT_LESS_OR_EQUAL错误)。排查此类问题需遵循从硬件到软件的完整链路:首先进行物理

weixin_30319153的博客 366

服务可用性:为什么监控和日志记录很重要?

作者:禅与计算机程序设计艺术 随着云计算、微服务等新技术的发展,服务端的架构也在发生变化。传统单体架构已无法满足需求,新的服务架构要求复杂的系统架构,包括服务发现,负载均衡,熔断机制,限流保护,隔离故障等一系列组件的结合来确保服务的高可用,降低故障率。因此,自动化运维工具的引入势必会成为趋势。 而监控和日志记录对于服务可用性和可观察性是至

AI天才研究院 3614

PolarDB性能监控与报警规则设置保姆级教程:告别数据库卡顿,实时掌握运行状态

本文提供PolarDB性能监控与报警规则设置的详细教程,帮助用户实时掌握数据库运行状态,避免卡顿问题。涵盖关键性能指标解读、报警规则配置实战、监控看板定制技巧及高级诊断功能应用,适用于MySQL和PolarDB用户,提升数据库管理效率。

janckywong963的专栏 377

保姆级教程:用ROS2 Humble + Gazebo Classic 从零搭建一个能键盘控制的差分AGV模型

本文提供了一份详细的ROS2 Humble与Gazebo Classic教程,指导用户从零开始搭建一个键盘控制的差分AGV模型。内容涵盖环境配置、Xacro文件设计、Gazebo仿真集成以及键盘控制实现,特别针对常见问题提供解决方案,帮助开发者快速掌握ROS2机器人仿真技术。

weixin_30387423的博客 169

STM32CubeMX——循迹传感器TCRT5000的使用

前言 人生如逆旅,我亦是行人。 ————苏轼《临江仙·送钱穆父》 一、介绍 TCRT5000描述:(带有晶体管输出的反射光学传感器) TCRT5000是一种反射式光学传感器,它包括一个红外发射器和一个3.5mm引线封装的光电晶体管,可阻挡可见光。还具有1mA 典型被测输出电流,2.5mm峰值工作距离,可应用传感与仪表,工业等行业。 TCRT5000具有紧凑的结构,其中发射光源和探测器布置在同一方向,通过使用来自物体的反射红外光束来感知物体的存在。工作波长为950毫米,探测器由光电晶体管组成

W_Oilpicture的博客 1万+

排查问题流程

本文章来源于:https://github.com/Zeb-D/my-review ,请star 强力支持,你的支持,就是我的动力。 [TOC] 也有同事经常反馈遇到一些棘手的问题不知道怎么去排查,排查问题的思路很重要,希望自己遇到问题时,也能够从容、高效地定位到根因。因此,我就与你说说我在应急排错方面积累的心得。这都是我多年自己总结出来的,希望对你有所帮助。当然了,也希望和大家一起说说自己平时...

在此立一个IT职业上的flag:https://github.com/Zeb-D/my-review 1万+

工艺边与定位孔设计经验规则总结

工艺边是在SMT焊接时,为了PCB和导轨接触预留的PCB边。工艺边和PCB的接触部分一般需要开槽,或者使用邮票孔,以方便后期去除工艺边。

fydar的博客 1987

jvm线上内存问题排查

背景: 正在和同事在外面吃饭,突然钉钉报警,有一个服务的机器内存飙到百分之90%多。和同事大概聊了一下说是队列累积,机器消费不过来,具体原因也没有深问,又一同事,说看一下是那个对象占的内存,使用jmap,jstat。当时我也在旁边围观,由于之前有看过,我就说jmap在生产环境敢使用吗? jmap,jstat的作用? jmap 是内存影像工具,jmap用于生成堆转储快照(一般称为dump或者hea...

weixin_40413961的博客 566

【WRF-UCM】BEP+BEM 模拟:README

【WRF-UCM】BEP+BEM 模拟:README

WW、forever的博客 223

第4章:外包接单全攻略——Upwork/电鸭/猪八戒从0到第一单

> - 三个外包平台的详细对比(适合人群、抽成、防骗) > - 每个平台的Profile优化模板(可直接复制修改) > - 用AI写Proposal的3个Prompt模板(我实测回复率提升50%) > - 报价策略与防骗指南(附5个危险信号) > - 我的第一单复盘:从注册到收款的全过程(含聊天记录脱敏)

sfishfly的博客 577

【Linux笔记】十八、监控工具:Zabbix的安装及使用

意思就是:比如我们现在的linux系统是自带有php解释器和python解释器,假如现在的python解释器是python2,我们要安装一个python3,那你在yuminstallpython3时,就会把和整个操作系统有关的依赖环境进行一个升级或者更新,那这就可能会影响到其他程序了呀。开机启动就用systemctl命令,因为我们的mariadb是yum安装的,yum安装就会自动生成一个mariadb-server的单元文件,这个文件就可以用systemctl去管理。zabbix可以使用多种方式监视。

因为热爱所以坚持 1481

如何对正射影像DOM(卫星影像、无人机航拍影像)进行拼接、合并以及去黑边(附 Global Mapper Pro 24.0 安装包(中文注册版))

为什么要对正射影像DOM进行拼接?影像去黑边、影像拼接的操作和步骤。

从地图看世界的专栏 4300

Jpom项目监控与报警:邮件、钉钉、微信多通道实时通知终极指南

想要让你的项目监控不再"沉默"?Jpom项目监控与报警功能为你提供全方位、多渠道的实时通知解决方案。作为一款简而轻的低侵入式在线构建、自动部署、日常运维软件,Jpom的项目监控报警系统支持邮件、钉钉、企业微信等多种通知方式,确保你第一时间掌握项目异常情况。 ## 🚀 Jpom监控报警核心功能 Jpom的监控报警系统能够主动感知项目运行状况,当检测到异常时,立即通过预设的通道发送报警信息。无论

gitblog_00444的博客 390

STM32CubeMX之emWin移植

“前面两章介绍了SDRAM和LTDC的使用,本篇文章将介绍emWin移植到STM32。”硬件环境:STM32F429IGT6软件环境:STM32CubeMX v5.5.0...

zhang062061的专栏 2827

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

企业级开发和运维中,Shell 脚本常用于自动化运维、批量处理、监控报警、部署发布等场景。

在企业级开发和运维中,Shell 脚本常用于自动化运维、批量处理、监控报警、部署发布等场景。一、自动化部署脚本场景:实现代码拉取、编译、服务重启等部署流程自动化。示例:Git 拉取代码并重启服务bash/bin/bash# 定义变量# 拉取最新代码echo "代码拉取失败!exit 1# 编译(若需要)# 重启服务echo "服务重启失败!exit 1echo "部署成功!

phonenight的博客 762

数学建模模型总结

这是本人在两年内准备参加数学建模竞赛搜集到的模型资料,已经经过了本人的筛选和整理,希望能够对准备参加数学建模竞赛的学弟学妹们提供一些帮助!

Node.js生产环境性能监控方案(附完整代码):快速定位90%的运行时问题

快速定位Node.js生产环境90%运行时问题,本文提供JavaScript Node.js优化的完整监控方案,涵盖性能追踪、内存泄漏检测与错误告警,适用于高并发服务。附可落地代码,值得收藏。

InitFlow的博客 901

pscad IEEE标准系统搭建说明

pscad IEEE标准系统搭建说明,包含典型的IEEE 9节点、14节点、30节点、39节点和118节点系统。内含标准测试系统的原始数据和潮流结果。

最新的sdio 4.0 spec 协议标准 带书签 高清完整PDF版

Part-E1-SDIO-Specification-Ver4.00-Final-120220.pdf:最新的sdio 4.0 spec 协议标准 带书签 高清完整PDF版,包括SDIO 接口的外设,SDIO 接口官方协议等。

生产监控报警一:阿里云 RDS 监控报警

2019独角兽企业重金招聘Python工程师标准>>> ...

weixin_34356310的博客 614

Java服务CPU与内存过高问题排查实战指南

在Java应用性能优化领域,CPU使用率过高和内存泄漏是两大核心挑战,直接影响服务稳定性和响应效率。其原理通常涉及线程调度、垃圾回收机制与对象生命周期管理。深入理解这些底层机制,对于构建高可用系统具有重要技术价值。在实际应用场景中,无论是电商秒杀、实时数据处理还是微服务架构,不当的线程同步、未关闭的资源引用或缓存策略失效都可能导致资源异常消耗。本文聚焦于Java服务性能诊断,系统介绍如何利用jstack、MAT等工具链,结合火焰图与堆转储分析,快速定位死循环、内存泄漏等线上问题,提升工程团队的问题排查与解决

weixin_33721427的博客 447

记一次cpu飙升问题排查

首先问题是这样的,周五正在写文档,突然收到了线上报警,发现cpu占用达到了90多,上平台监控系统查看容器,在jvm监控中发现有一个pod在两个小时内产生了61次youngGc一次fullGc,这个问题特别严重且少见,由于我之前也没有排查过此类问题,所以也是百度,但整个过程也有一些自己的思考,所以跟大家分享一下~

jcc4261的博客 663
上一篇: Java快速开发框架居然没用条件化配置
下一篇: 一张图+一句话,记住所有 JVM 垃圾收集器!
旷野说
博客等级 码龄9年 361粉丝 86原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值