使用sidecar container dump 正在运行的容器
本文最后更新于:7 小时前
引言
memory dump
是分析线上程序内存占用非常好的工具
在windows
上可以直接任务管理器右键生成dump
,假如需要根据条件比如CPU 内存占用到多少生成dump
可以使用procdump
额外的,还可以使用dotmemory.exe
创建dump
而linux
呢?
可以使用dotnet-dump
或 dotnet-gcdump
经我测试,dotnet-gcdump
安装后可直接执行命令无问题,但在dump
中未发现更多数据,于是尝试使用dotnet-dump
但是我在正式服务器上安装一堆东西执行命令后却报错:
1 |
|
GPT
告诉我这是因为docker run
时未添加特权参数--cap-add=SYS_PTRACE --security-opt seccomp=unconfined
导致的
但问题是,我只需要为这个线上容器(Container
)创建dump
而不是要重新起一个容器
本文介绍解决方法
解决方案
微软的官方文档里面有提到这种方法:Collect diagnostics in Linux containers
即为sidecar container
就是另起一个带有特权参数的容器,通过命名空间共享(share a process namespace)
在特权容器中创建dump
这里给出我的命令
以下命令皆由AI生成
操作步骤
正常使用dotnet-dump
的命令
这里先给出正常情况下,特权参数启用testServer
时的命令以做参考
1 |
|
这里因为我的服务用的.NET 5.0
因此选用5.0
的版本,假如不知道对应安装的dotnet-dump
版本可查看dotnet-dump versions
PS:测试时可以使用docker commit test007 test007-2
命令临时将安装的内容保存,方便调试
sidecar container dotnet-dump
生成dump
正常sidecar
应该是这样的命令
1 |
|
这里使用安装了dotnet-dump
的临时image
:test007-2
生成的dump
文件为Host
的/tmp/dumps/myapp.dmp
但实际执行会发现报错:
Process 1 not running compatible .NET runtime.
微软的官方文档里有提到这个报错:Use .NET CLI tools in a sidecar container or from the host
它的方案是共享/tmp
路径,这里我没明白什么意思,但是我找到另一种支持的方法
sidecar container createdump
生成dump
在Microsoft.NETCore.App
中已经自带了createdump
程序,可以直接生成dump
这个文件位于容器的/usr/share/dotnet/shared/Microsoft.NETCore.App
目录中,根据你安装的runtime
版本有所不同,因此首先我找到本地自带的createdump
版本
1 |
|
直接使用createdump
创建dump
1 |
|
生成的dump
文件为Host
的/tmp/dumps/myapp.dmp
1为test007
中dotnet
服务的pid
,可以通过命令查询
5.0.5
为本机mcr.microsoft.com/dotnet/aspnet:5.0
的createdump
版本
同时,使用aspnet:5.0
的镜像还避免了正式服务多实例数据异常的风险,可以说是一劳多得,一箭双雕
传输
dump
文件一般很大,所以需要压缩传输
tar -czvf dump.tar.gz /tmp/dumps/myapp.dmp
假如压缩后还是很大,且正式服务器带宽不大,可以看我之前的文章: