如何排查占用内存过大的对象或者类_OOM_dump使用_cp_scp

原创 已于 2022-05-02 23:01:02 修改 · 1.1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #oom

于 2022-05-02 22:50:03 首次发布
本文介绍了如何排查Java应用中内存占用过大的问题，包括使用psefgrepjava查看进程，生成dump文件，利用jmap和jvisualvm分析内存使用情况，关注新生代、老年代和栈的空间占用。通过调整幸存区大小减少Full GC，以及通过gc日志分析内存问题。同时，分享了在Linux服务器之间传输文件的方法，如scp和ftp。

如何排查占用内存过大的对象或者类

ps ef grep java可以看到使用的进程 然后根据进程生成dump文件 分析gc情况
然后（确认能重启启动前 不能敲命令 只生成dump文件 不然内存会爆 只能下载文件 ）
如果内存够用
jmap -heap 进程ID 查看内存使用情况 查看栈 新生代 老年代栈所占空间

jps -lvm
用于查看当前机器上已装载的jvm
在这里插入图片描述
生成dump文件
需要进程ID 文件名：20170307.dump
jmap -dump:format=b,file=20170307.dump 16048

jvisualvm分析 可以知道大对象是哪个类哪个集合

增大幸存区内存，避免晋升到老年代 频繁full gc

gc日志文件可以看元空间 或者 幸存区或者老年代的问题

linux不同服务器间传文件,linux服务器之间文件传输
https://blog.youkuaiyun.com/weixin_39817012/article/details/116581998

cp只能在本机使用

方法二：scp命令

scp命令可用于用一台服务器向另一台服务器上传文件

scp -p file.tar.gz zhangsan@172.168.11.12:/home/zhangsan

把当前目录下的 file.tar.gz 推送到 172.168.11.12 服务器的 /home/zhangsan 目录下，使用zhangsan用户，回车输入密码，这个文件就会传到这台服务器指定的目录下了

Linux 服务器之间文件传输

ftp mobaXterm

都可以把服务器的文件拿到win系统

JackZjj2021
关注
使用kubeadm搭建K8s多节点集群
在技术的广袤天地里，本博客如精准罗盘。剖析前沿科技，深掘代码奥秘，以精炼笔触，带您穿越复杂技术迷宫，速达知识彼岸。
09-01 2642
容器运行时是指用于直接对镜像和容器执行基础操作（比如拉取/删除镜像和对容器的创建（使用镜像）/查询/修改/获取/删除等操作）的软件。最开始的K8s版本只支持Docker作为容器运行时，但为了更好与底层容器技术解耦（同时也是为了兼容其他容器技术），K8s在v1.5.0就引入了容器运行时接口（CRI）。CRI是K8s与第三方容器运行时通信接口的标准化抽象，它定义了容器运行时必须实现的一组标准接口，包括前面所说的针对镜像和容器的各项基础操作。
使用Java VisualVM观察堆内存分配情况
newbaby2012的专栏
06-15 2187
Java VisualVM默认在jdk的bin目录下,我的是C:\Program Files\Java\jdk1.8.0_291\bin:
jvisualvm.exe查看对象占用内存
HelloMonkey__的博客
05-26 2565
jvisualvm.exe查看对象占用内存 (1)写一段程序，保证程序不结束，正常运行 如以下代码： package com.company.hignLevel; import java.io.IOException; import java.util.ArrayList; import java.util.List; public class TestObjSize { //定义一个直接继承Object的类，用于观察 public static class TestObject {
安装Java Visualvm监控堆内存和参数说明
Bruce小鬼
12-09 3875
安装Java Visualvm监控堆内存和参数说明 1.概述 这篇文章介绍使用Java Visualvm工具监控堆内存VisualGC插件的安装以及监控堆内存参数说明。 摘要 VisualGC插件安装 VisualGC监控Jmeter堆内存案例 VisualGC监控界面参数说明 2.安装VisualGC插件 2.1.打开Java Visualvm 本地安装java后，使用cmd命令打开Java Visualvm工具。 jvisualvm 2.2.安装VisualGC插件 Java Visualvm
八、jdk工具之JvisualVM之四--VisualVM 进行性能分析及调优
weixin_34349320的博客
10-25 1414
背景知识 性能分析的主要方式 监视：监视是一种用来查看应用程序运行时行为的一般方法。通常会有多个视图（View）分别实时地显示 CPU 使用情况、内存使用情况、线程状态以及其他一些有用的信息，以便用户能很快地发现问题的关键所在。 转储：性能分析工具从内存中获得当前状态数据并存储到文件用于静态的性能分析。Java 程序是通过在启动 Java 程序时添加适当的条件参数来触发转储操作的。它...
scp命令使用
...
10-28 741
scp是secure copy的简写，用于在Linux下进行远程拷贝文件的命令，和它类似的命令有cp，不过cp只是在本机进行拷贝不能跨服务器，而且scp传输是加密的。可能会稍微影响一下速度。当你服务器硬盘变为只读 read only system时，用scp可以帮你把文件移出来。另外，scp还非常不占资源，不会提高多少系统负荷，在这一点上，rsync就远远不及它了。虽然 rsync比scp会快一点
实时性增强实战：为PREEMPT_RT补丁启用交叉编译支持的6步验证流程
!...# 1. 实时Linux与PREEMPT_RT补丁概述 在工业自动化、机器人控制和高精度测量等对时序敏感的场景中，标准Linux内核的非抢占特性难以满足微秒级响应需求。PREEMPT_RT补丁通过将内核中不可中断的临界区转化为可抢占的...
死机崩溃不再怕，S9012-9018_WS异常调试技巧大全（20年经验总结）
!... # 摘要 本文围绕S9012-9018_WS系统的异常调试问题，系统性地分析了其在实际运行中所面临的调试挑战与技术难点。文章从异常调试的基本原理出发，深入剖析了系统架构、崩溃类型及日志诊断机制，结合实战搭建了完整...
JAVA线上常见问题排查手段
寻路人在人间的博客
04-12 6434
在平时开发过程中，对于线上问题的排查以及系统的优化，免不了和Linux进行打交道。每逢大促和双十一，对系统的各种压测性能测试，优化都是非常大的一次考验。抽空整理了一下自己在线上问题排查以及系统优化的一些经验。 一、系统性能瓶颈在哪 我们常常提到项目的运行环境，那么运行环境包括哪些呢？一般包括你的操作系统、CPU、内存、硬盘、网络带宽、JRE环境、你的代码依赖的各种组件等等。所以系统性...
从崩溃日志定位Flash异常：利用core dump与trace工具链的5步精准诊断法
结合Core Dump与运行时Trace数据，构建“日志→内存快照→执行路径还原”的诊断闭环，是实现精准根因定位的基础。 例如，当内核日志出现`Unable to handle kernel paging request at virtual address XXX`且发
linux dump文件太大-解决方案：远程Linux服务器运行JvisualVM分析java
忆网
09-02 2300
SSH登陆远程Linux服务器是普遍的方式，下面讲述如何使用Putty,Xming工具在Windows机器上SSH登陆到Linux服务器，并运行VisualVM可视化界面程序，进行Java性能分析。 1: 配置Linux服务器上sshd_config文件, 允许X11转发 使用编辑工具打开/etc/ssh/sshd_config，并加上如下语句： X11Forwarding yes 很多ssh...
dump文件解析之探索.Net的内存
weixin_30909575的博客
09-25 353
前言： 对于需要长时间运行的.net程序，有时需要我们查看内存的使用有没有内存泄露问题。 我们可以从dump文件中找到答案。 Dump的看点 用dump文件来分析内存，到底我们需要关心哪些点呢？ 内存的使用情况 HeapSize/object的数量 也就是托管堆使用大小以及托管堆内有多少数量的对象 　　　　1.1 查看有没有存在有占用大量内存的对象 <比...
dump文件深度分析
w7sss的博客
04-11 5430
java内存dump是jvm运行时内存的一份快照，利用它可以分析是否存在内存浪费，可以检查内存管理是否合理，当发生OOM的时候，可以找出问题的原因。综上，dump文件结构还是比较简单的，这对于分析线程的执行情况非常有用，也是每一个Java程序员必须掌握的高级技能之一，你学会了吗？（2）类的静态变量的名称类型及值是放在类对象里面的，成员变量的名称和类型也是放在类对象里面的，但是实例的值是放在实例对象里面的。有一个表格，对象类型，实例个数，实例所占用内存大小，哪种类型的对象占用了内存最多一目了然。
如何排查JVM内存问题并定位
oeSeven的专栏
05-11 1102
今天收到测试小姐姐提的bug，在进行压测的时，内存和CPU都飙高，要我分析一下。 一、首先观察服务器上的内存使用情况： 使用jdk自带的jvisualvm.exe功能（在jdk的bin目录下） 打开后连接远程服务器，具体如何连接请自行百度，连接后壳查看服务器的CPU和内存等情况。 ● 如果是内存泄漏，堆内存会一直往上飙，然后会出现疯狂GC的情况。 ● 我这里没有出现疯狂GC的情况，而是有规律的GC，但每次GC的时候CPU都会飙到70%以上。 ps：截图是问题处理完之后的截图，当时cpu使..
如何使用VisualVM分析java快照
朱登凯的专栏
10-12 1858
当我们遇到一些java运行期间的疑难问题时，比如占用内存过大或假死等现象，往往想到的是dump一个快照出来分析一下。今天用一个最简单的例子来分享一下我分析java快照的方法。 代码实例 我喜欢用最简单的分析问题，太复杂的代码有太多噪音。下面是一些非常简单的代码。 package com.example; public class UserInfo { private String name; private String role; private int age;
jvisualVM调优案例
epitomizelu的专栏
06-28 1961
一，jvisualVM介绍 jvisualVM是一款jdk自带的图像化jvm性能监控工具，可以： 实时监控堆内存的变化情况 一键生成堆转储文件并解析并图形化展示 dump线程信息(相当于jstack) 堆内存profiler(相当于jmap -histo展示堆内对象直方图) CPU、内存、线程、已加载的类统计 二，实时监控堆内存使用情况 很棒的一点是，这个图是动态变化的，可以动态的看见堆内存各区域的动态变化： eden区内存占用逐渐增多 eden区垃圾回收 eden区对象复制到幸存区 幸存区对象复制
VisualVM工具的使用
m0_72838865的博客
08-26 1050
VisualVM，能够监控线程，内存情况，查看方法的CPU时间和内存中的对 象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。注意： JMX Server还会随机额外的去监听两个端口，所以在远程连接时我们本地的JMX在连接时也会尝试去连接监听端口。VisualVM使用简单，几乎0配置，功能还是比较丰富的，几乎囊括了其它JDK自带命令的所有功能。在jdk的安装目录的bin目录下，找到jvisualvm.exe，双击打开即可。很显然，多出两个端口。...
通过jvisualvm分析内存泄漏
热门推荐
牧夏的个人博客
01-04 1万+
到jdk的目录下的bin下执行jvisualvm 进去之后，如图 上面是有visual GC这个工具的，但是真实的我刚打开的时候是没有的，需要： 找到希望安装的插件进行安装，因为visual GC这个插件我已经安装过了所以在已安装里面 这里我们再安装下VisualVM-JConsole这个插件 然后关掉原来的窗口，再次启动 因为看效果比较慢，所以 java -Xmx201k -Xmn20...
java深入理解jvm对象内存结构和大小分析（示范四种查看jvm中对象内容和大小的方式）
HumorChen的博客
02-11 5217
该对象的堆内存大小为16字节（不计算对象里指针引用的对象大小，也称为浅堆，如果递归计算引用的对象大小则称为深堆大小），对象状态信息8个字节，对象类型信息4个字节，属性chars的对象指针4个字节（两种不同方法查看对象大小的时候是会有差异的，反正两种方法看大小相差不会超过8字节）在jvm里分配内存是8字节为最小单位的，因此64为jvm假设按指针内存大小为4字节就可以拥有32G的寻址了，8字节则浪费掉了一半，因此jvm做了指针压缩技术，将64位机器上jvm的指针由原本的8字节减小到了4字节。
container_oom_events_total
最新发布
11-19
<think> 我们刚刚讨论过容器网络传输错误总数(container_network_transmit_errors_total)，现在用户转向询问容器发生OOM（内存不足）事件总数的相关信息。根据用户要求，我需要提供关于容器OOM事件总数的详细信息，包括指标含义、监控方法、关联分析等。 用户还提供了两段引用，其中引用[1]提到云原生环境下OOM问题常由Kubernetes/Docker使用者发现，并通过调整内核参数解决；引用[2]则展示了OOM问题的排查步骤和典型内存泄漏场景。这些内容需要融入回答中。 我将构建以下回答框架： 1. 指标含义：解释container_oom_events_total的核心定义 2. 监控方法：提供PromQL查询示例和告警规则 3. 关联分析：结合内存指标和OOM事件分析 4. 排查流程：参考引用[2]的步骤设计容器OOM排查指南 5. 优化建议：根据引用[1]补充内核参数调整等解决方案 特别注意用户要求的技术细节： - 数学表达式需用$...$格式（如内存计算公式） - 生成相关问题需放在最后 - 引用标注要自然融入内容（如[^1]） </think>### `container_oom_events_total` 详解 #### **1. 指标含义** `container_oom_events_total` 是 Kubernetes 中记录**容器因内存不足（Out of Memory）被强制终止的累计次数**的核心指标[^1]： - **数据类型**：计数器（Counter），数值单调递增 - **单位**：OOM 事件次数 - **采集来源**：由 kubelet 通过 cAdvisor 从内核 `oom_kill` 事件中采集 - **关键标签**： - `container`：容器名称（如 `nginx`） - `pod`：所属 Pod 名称 - `namespace`：Kubernetes 命名空间 #### **2. OOM 事件触发原理** 当容器内存使用量满足以下条件时触发 OOM： $$ \text{容器内存使用量} \geq \text{内存限制（memory limit）} \times \text{容忍系数} $$ 其中容忍系数通常为 1.0（即达到 limit 即触发），可通过内核参数 `memory.oom_control` 调整。 #### **3. 监控方法** ##### (1) PromQL 基础查询 ```promql -- 查看所有容器的 OOM 事件总数（按命名空间聚合） sum by(namespace) (container_oom_events_total) -- 计算 OOM 事件增长率（次/小时） increase(container_oom_events_total[1h]) ``` ##### (2) 告警规则示例 ```yaml - alert: ContainerOOMFrequency expr: | # 1 小时内发生超过 3 次 OOM 则告警 increase(container_oom_events_total[1h]) > 3 for: 5m labels: severity: critical annotations: summary: "容器频繁 OOM ({{ $labels.pod }}/{{ $labels.container }}: {{ $value }} 次)" ``` #### **4. 关联指标分析** 需结合以下指标诊断 OOM 根本原因： | **指标** | **分析作用** | |-------------------------------------|-----------------------------------------------------------------------------| | `container_memory_working_set_bytes` | 容器工作集内存（实际使用量），接近 limit 时风险高 | | `container_memory_failcnt` | 内存分配失败次数，提前预警 OOM | | `kube_pod_container_resource_limits` | 检查容器内存限制是否合理（如是否设置过低） | | `process_resident_memory_bytes` | 进程实际占用内存，识别内存泄漏进程 | #### **5. OOM 排查流程**（基于引用[2]优化） 1. **获取内存快照** 添加 JVM 参数：`-XX:+HeapDumpOnOutOfMemoryError` 自动生成堆转储文件（.hprof） 2. **分析内存对象** - 使用 VisualVM 或 MAT 加载 .hprof 文件 - 按对象数量/大小排序，识别异常对象（如 `HashMap$Node` 堆积） 3. **检查引用链** 从 GC Root 追溯对象持有者，常见问题： - 未关闭的数据库连接/HTTP 客户端（引用[2]案例） - `ThreadLocal` 未清理 - 静态集合类持续增长 4. **验证与修复** - 本地复现问题（如模拟高并发场景） - 修复代码后监控 `container_memory_working_set_bytes` 是否稳定 #### **6. 典型优化方案** | **场景** | **解决方案** | |---------------------------|-----------------------------------------------------------------------------| | **内存限制过低** | 调整 Pod 的 `resources.limits.memory`（需参考历史峰值 $ \times 1.2 $） | | **内存泄漏** | 修复代码（如添加 `client.shutdown()` 释放资源，引用[2]案例） | | **内核参数问题** | 调整 `vm.overcommit_memory=2` 和 `vm.swappiness=10`（引用[1]） | | **JVM 堆配置不合理** | 设置 `-Xmx` 不超过容器内存 limit 的 70%（预留空间给非堆内存） | | **容器化机制冲突** | 升级 Kubernetes 和 Docker 版本（云原生环境常见问题，引用[1]） | #### **7. 运维实践** **案例**：某 Java 服务频繁 OOM - **现象**：每小时 OOM 事件 >5 次，`container_oom_events_total` 持续上升 - **分析**： - Heap Dump 显示 `ConcurrentHashMap$Node` 对象占堆 80% - 追溯代码发现 OSS 客户端未调用 `shutdown()`（引用[2]场景） - **解决**： - 添加资源释放逻辑 - 调整容器内存限制从 1GB → 2GB > 修复后 OOM 事件归零，内存工作集稳定在 1.3GB > **注意事项**： > - OOM 后容器会自动重启（`kube_pod_container_status_restarts_total` 增加） > - 生产环境需设置 `livenessProbe` 快速检测容器故障 > - 避免过度依赖 Swap（容器默认禁用，开启会导致性能骤降） --- [^1]: Kubernetes 内存管理文档 [^2]: OOM 问题排查指南
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值