如果谁的耐心不好, 就让他去看MAT里的objects信息.
有项目出现了OOM的情况
我在公司这边有一台内存比较高的Win10机器.
然后帮助同事进行了dump文件的分析.
为了备忘, 这里简单总结一下.
公司网络限速.
总结为: 下载2h,mat分析40min,人工分析50min 总计耗时约4h
分步骤的详细时间为:
1. 虽然公司限速,但是将下载速度提高到了5MB/S左右.(必须百度会员加持)
2. 客户现场因为磁盘限制,没有进行压缩(严重抗议公司节约采购机器的费用)
一个31G堆区的hprof文件大约35G左右.进行了raw模式的上传.
3. 百度会员加持下的百度云盘大于2个小时下载完(3600*5M*2)
4. 然后直接进行mat的分析. mat的堆区设置为50G. 分析时间大约为40min
5. 分析完之后进行简单处理因为卡顿,大约至少要花50min才能基本看完.
6. 同时一个项目使用压缩方式上传dump文件. 35G压缩完4G, 下载20min. 解压缩5min
效率提升较高
mat 解析完之后第一个界面一般是overview的界面
在biggest Objects By retained size 界面内
左键单击最大的内存区域.
第一步可以选择 Java basics
选中 Thread details
基本上可以确认这个问题的堆栈信息.
注意这一步确认的是 异常的堆栈,但是可能无法判断具体的数据
第二步可以确认有异常的数据
第二步可以选择 List objects
任意选中 incomming 和outcomming 应该都可以(我比较菜不知道两者的区别)
进入objects对象里面.
注意 我这次分析的是 GroupDocs的内存对象. 每一级应该都可以看到具体的对象名
单位为了简单起见, 可以在一级之内进行查看.
这里我的dump 里面一层一共是 116个对象.
挨个点. 大概是在 108个左右就可以看到具体的对象名了.
对象名字的特点为 某个 xlsx 文件.
然后将文件反馈给现场, 就能够根据id查询到具体的文件了
比较好定位问题了就.
好像GroupDocs的方式能够找到具体的文件
但是其他都没有文件打开,所以objects 里面没有具体的对象.
不过既然是水blog 还是多看了一眼redisson的对象信息.
注意不要点 是 super和blocker开头的 的对象信息. 会卡很久.
注意 JAVA-LOCAL 里面可能存很多密钥信息. 比如AMQP里面就比较危险.
产品里面有非常多的redisson的相关进程.
逐个进行打开也没有发现比较奇怪的数据
然并卵 没看懂.
通过WPF的按钮、文本输入框实现了一个简单的SpinBox数字输入用户组件并可以通过数据绑定数值和步长。本文中介绍了通过Xaml代码实现自定义组件的布局,依赖属性的定义和使用等知识点。