dotnet core调试docker下生成的dump文件
最近公司预生产环境.net core应用的docker容器经常出现内存暴涨现象,有时会突然吃掉几个G,触发监控预警,造成容器重启。
分析了各种可能原因,修复了可能发生的内存泄露,经测试本地正常,但是发到预生产还是会有内存暴涨现象,反而更改GC模式后内存使用保持较低水平,百思不得其解,所以想到使用调试dump文件方式来分析应用内存状况。
环境:
lldb:3.9
dotnetcore:2.1.6
docker image:microsoft/dotnet:2.1.6-aspnetcore-runtime
(根据文档,dotnetcore2.0需要使用lldb3.6,但是我尝试了没有成功,lldb使用的dotnetcore版本与dump应用的dotnetcore版本要一致,由于core2.1现在官方只提供2.1.6的runtime文件,故本次测试使用2.1.6版本,如果哪位童鞋在core2.0上调试成功了,麻烦告诉我方法)
linux下需要使用lldb来进行dump分析,但是安装这个太慢,所以我找了个安装好的docker image使用,有兴趣的也可以自行安装,这里就不介绍安装过程了,.net core 本身提供了lldb sos 插件,只要加载使用就好。
启动一个.net core应用容器,这里需要多加几个参数,不然无法创建dump(另外多说一句,docker内crash coredump文件无法生成也是权限原因,我这边启动时都给了权限,如果仅仅是需要使用.netcore提供createdump工具,只需要加--privileged=true):
docker run -d -p 80:80 --name dumptest --ulimit core=-1 --security-opt seccomp=unconfined --privileged=true dumptest:v1
--ulimit core=-1 不限制coredump大小
--security-opt seccomp=unconfined 允许容器执行全部系统调用
--privileged=true 允许createdump访问其他进程
进入容器:
docker exec -it dumptest /bin/bash
创建dump文件:
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.6/createdump 1
(经观察,容器内的跑的应用进程ID都是1,所以直接使用,也可以使用top命令来查看进程ID,创建dump文件在/tmp/coredump.1)
退出容器:
exit
在宿主机创建文件夹/data/docker,并将容器中的dump文件拷贝到宿主机:
cd /&&mkdir data&&cd data&&mkdir docker
docker cp dumptest :/tmp/coredump.1 /data/docker
拉取lldb镜像(此镜像是lldb3.9的dotnetcore版本为2.1.5,有其他需求请自行查找):
docker pull yyoda/dotnet-lldb
启动lldb容器,并将coredump文件路径映射到容器内(如果想要长期使用不要带--rm参数):
docker run -d -v /data/docker:/dump --rm -it --name lldb yyoda/dotnet-lldb:latest /bin/bash
镜像内需要安装dotnetcore2.1.6,为了方便安装,在容器内部使用阿里源:
cd /data/docker
touch sources.list
将下面的源加入sources.list:
deb http://mirrors.aliyun.com/ubuntu/ trusty main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ trusty-security main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ trusty-updates main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ trusty-proposed main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ trusty-backports main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ trusty main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ trusty-security main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ trusty-updates main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ trusty-proposed main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ trusty-backports main restricted universe multiverse
进入lldb容器:
docker exec -it lldb /bin/bash
更新源:
mv /dump/sources.list /etc/apt/source.list
apt-get update
安装dotnetcore2.1.6 runtime(由于网络等原因,如果失败多试几次):
wget -q https://packages.microsoft.com/config/ubuntu/14.04/packages-microsoft-prod.deb
dpkg -i packages-microsoft-prod.deb
apt-get install apt-transport-https
apt-get update
apt-get install dotnet-runtime-2.1
启动lldb:
lldb-3.9 dotnet -c /dump/coredump.1 -o "plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.6/libsosplugin.so"
(如果sos加载失败,启动后输入命令:plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.6/libsosplugin.so
如果runtime加载失败,启动后输入命令:setclrpath /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.6)
输入soshelp命令,出现下图:
查看堆上的对象类型分配情况(由于结果太多,这里加入大于1024byte过滤):
dumpheap -stat -min 1024
查看指定类型对象情况:
dumpheap -mt 00007f2a28b874e8 -min 1024
查看指定对象情况:
dumpobj 00007f2a1400fc88
剩下的就是熟悉sos命令,不在赘述了,大家自行研究吧。。。
ps:附上docker容器内应用崩溃时生成dump方法:
1.容器启动时要带下面两个参数:
--ulimit core=-1
--security-opt seccomp=unconfined
2.宿主机上执行命令,更改dump文件输出路径:
echo '/tmp/core.%t.%e.%p' | sudo tee /proc/sys/kernel/core_pattern
(因为系统在产生 coredump 文件时是根据 /proc/sys/kernel/core_pattern 的设定模板来的,而默认的设定是 /usr/share/apport/apport %p %s %c %P,也就是用管道传apport。然而 Docker 里面的系统不一定有装 apport,并且 /proc 又是直接挂到 Docker 里面的,所以需要设置固定存放位置 /tmp。
%p 所dump进程的进程ID
%t core dump的时间
%e 程序文件名)
测试:
进入容器后执行 kill -s SIGSEGV $$ 触发当前shell终端的段错误。
再次进入容器,在/temp路径下可以看到刚刚生成的dump文件
参考资料:
https://github.com/mikem8361/coreclr/blob/5c22cb85c7cc9173f2fb783bf24c0cbbb6096c89/Documentation/building/debugging-instructions.md
http://blogs.microsoft.co.il/sasha/2017/02/26/analyzing-a-net-core-core-dump-on-linux/
原文地址:https://www.cnblogs.com/iamsach/p/10118628.html
.NET社区新闻,深度好文,欢迎访问公众号文章汇总 http://www.csharpkit.com
dotnet core调试docker下生成的dump文件相关推荐
- C++(Qt)软件调试---linux下生成/调试Core文件(3)
#软件调试 C++(Qt)软件调试-linux下生成/调试Core文件(3) 文章目录 C++(Qt)软件调试---linux下生成/调试Core文件(3) 前言 1.C++生成Core和使用GDB调 ...
- .NET 容器环境下创建应用 dump 文件
.NET 容器环境下创建应用 dump 文件 Intro 有时候我们的应用会出现一些异常的情况,比如内存飙升,线程死锁等等,通过一些 metrics 我们可能大概的了解内存是增长了,但是具体是哪里增长 ...
- [Android]生成heap dump文件(.hprof)
Android生成heap dump文件(.hprof) 一个heap dump就是一个程序heap的快照,能够获知程序的哪些部分正在使用大部分的内存. 它保存为一种叫做HPROF的二进制格式.对于A ...
- ASP.NET Core在Docker下面生成简易验证码
背景 验证码这个功能是十分常见的,各大系统的登录页面都会有.今天介绍一下最为普通的验证码. 无论最终给到前端的是图片格式的验证码还是base64格式的验证码,其实都离不开这样的一步操作,都要先在后台生 ...
- windows7 下WOW6432Node和dump文件生成问题
1,win7生成dump文件 在win7下一直无法生成dump文件,发现需要在注册表 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Err ...
- 记录linux 生成crash dump文件步骤
转载自:https://blog.csdn.net/weixin_42987033/article/details/81746074 执行文件编译时加入-g 命令 例如 g++ -g test.cpp ...
- java 生成dump_java dump文件怎么生成和分析-JMAP用法详解
jmap是java自带的工具 1. 查看整个JVM内存状态 jmap -heap [pid] 2. 查看JVM堆中对象详细占用情况 jmap -histo [pid] 3. 导出整个JVM 中内存信息 ...
- 在Keil C51下生成LIB库文件以及如何使用LIB库文件
如何生成LIB库文件 1.首先准备好生成LIB库文件对应的.c和.h文件,在这里用到的.c和.h文件分别是: "reg303.h" "rjwf303_flash.h& ...
- visual studio 2017发布dotnet core到docker
docker的好处不用多说,有不了解的可移步<docker入门>,作为一个.net方面的老鸟也想早点搭上docker末班车,减少布署中的各种坑.以下我是在Visual Studio 201 ...
最新文章
- 用鸿蒙跑了个 “hello world”!鸿蒙开发初体验
- 关于jsb中js与c++的相互调用
- NET面试题:C#中的lock关键字有何作用
- 计算机组装选择题,计算机组装之组装整机题
- linux创建zip+函数,linux+shell基础知识
- 7.Handling Missing Values
- 七牛切片视频php,音视频切片(HLS)
- 转 《pywinauto进行win32应用程序的测试》
- 算法:移除数组中的数字,不用额外空间27. Remove Element
- Java编写HTTP请求发送XML报文数据
- 夏普ar2048s打印机驱动安装_驱动人生 下载安装打印机驱动的方法
- 目前流行的、强大的基于Java的机器学习开发库精选
- 收藏 | 江苏省各地教师公务员等实际工资爆料
- ARC093F - Dark Horse
- python绘制8×8棋盘_python绘制跳棋棋盘
- oracle的透明网关是什么,ORACLE透明网关的配置
- 计算机网络原理【第四章 网络层】课后习题答案
- 白话解读“中台”技术
- python3 asyncio原理_Python3 asyncio Lock 协程锁实现原理
- 链路聚合(二层链路和三层链路)