dotnet core调试docker下生成的dump文件

最近公司预生产环境的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

时间: 2024-10-06 19:32:34

dotnet core调试docker下生成的dump文件的相关文章

[Android]生成heap dump文件(.hprof)

Android生成heap dump文件(.hprof) 一个heap dump就是一个程序heap的快照,可以获知程序的哪些部分正在使用大部分的内存. 它保存为一种叫做HPROF的二进制格式.对于Android执行android.os.Debug.dumpHprofData(hprofPath)方法后所生成的文件,需要把.hprof文件从Dalvik格式转换成J2SE HPROF格式.使用AndroidSDK提供的hprof-conv工具可执行该转换操作. hprof-conv dump.hp

在Windows下生成的shell文件在上传到Linux上发现无法执行

为了批量生成shell文件,我在Windows下用knime循环生成一批shell文件,在上传到Linux上执行时发现报错: [[email protected] Stock]$ ./f_wdt_outsource_outbound_header.sh -bash: ./f_wdt_outsource_outbound_header.sh: /bin/sh^M: 坏的解释器: 没有那个文件或目录 [[email protected] Stock]$ 在将shell文件内的代码完全复制到一个新建的

【dotNet Core】Swagger下简单的给WebApi分组

Startup.cs下ConfigureServices代码 这里主要在DocInclusionPredicate控制输出那些api. Startup.cs下Configure代码 给Controllers或Action添加[ApiExplorerSettings(GroupName= "ApiGroupName")] ApiGroupAttribute 若不想使用Microsoft.AspNetCore.Mvc下的ApiExplorerSettingsAttribute,可以自己建一

/var/spool/clientmqueue 下生成太多文件处理

问题现象: linux操作系统中的/var/spool/clientmqueue/目录下存在大量文件. 原因分析: 系统中有用户开启了cron,而cron中执行的程序有输出内容,输出内容会以邮件形式发给cron的用户,而sendmail没有启动所以就产生了这些文件: 解决办法: 1. 将crontab里面的命令后面加上> /dev/null 2>&12.知识点:2>:重定向错误.2>&1:把错误重定向到输出要送到的地方.即把上述命令的执行结果重定向到/dev/nul

android studio下生成jni头文件

cd app/src/main javah -d jni -classpath ../../build/intermediates/classes/debug net.sourceforge.lame.Lame 头文件 net_sourceforge_lame_Lame.h 会放在app/src/main/jni目录下

docker生成dotnet core镜像

使用docker生成dotnet core项目镜像.需要编写Dockerfile文件.编写方法有两种,如下: 第一种:将发布成功的项目,直接生成镜像. FROM microsoft/dotnet:2.2-aspnetcore-runtime WORKDIR /app EXPOSE 5000 COPY bin/Debug/netcoreapp2.2/publish/ app/ ENV ASPNETCORE_URLS http://*:5000 ENTRYPOINT ["dotnet",

调试SQLSERVER (一)生成dump文件的方法

调试SQLSERVER (一)生成dump文件的方法 调试SQLSERVER (二)使用Windbg调试SQLSERVER的环境设置调试SQLSERVER (三)使用Windbg调试SQLSERVER的一些命令 我们知道调试程序主要有两种方法 一种是:live debugging (附加进程 使进程hang住) 生产环境最好不要live debugging 一种是:post-mortem debugging or reading dump files (生成dump文件然后进行分析) 现在介绍一

使用dbghelp生成dump文件以及事后调试分析

前言 在产品的实际应用环境中,如果我们的程序在客户那里出现了问题,例如程序异常了,而这个时候的现象又不能还原或者很难还原重现,那么只有使用dump文件来保存程序的当前运行信息,例如调用堆栈等,同时使用符号文件来定位问题了;这里主要讲解使用dbghelp库来生成输出dump文件,同时使用符号文件和windbg来分析问题.样例代码 1 #include "stdafx.h" 2 #include <Windows.h> 3 #include <iostream> 4

通过Swashbukle给DotNet Core Web API 增加自动文档功能

DotNet Core Web API给开发者提供了一个很好的框架来开发Restful的API.那么这些API接口该如何管理起来呢?Swagger是一个很好的选择,Swagger不需要开发者额外去维护接口文档,只要开发者的接口遵循Restful的规范,Swagger就会根据API接口生成文档. 对于前后端分离的开发模式,前后端开发者一般会先定义好接口,然后各自独立开发,后端开发者可以使用Swagger很快的生成没有业务逻辑的接口文档,接口返回的是Mock Data,这样前端开发人员就可以更早的开