记录一次内存泄漏排查过程

某天收到运维线上警报，服务器内存告警，需要处理一下。此时通过浏览器打开页面，系统可以正常访问，但是有明显卡顿。为了不影响客户使用，先重启了服务释放了内存。由于该项目平时访问量并不大，因此随着程序运行内存占用率的增长比较缓慢，直到第三天才发现从原本的10%跳到了45%。初步怀疑有内存泄漏问题需要进行线上排查。

调试内存泄漏教程 - .NET | Microsoft Learn

服务器环境

Linux：CentOS Linux release 7.6.1810 (Core)
.NET SDK：.NET SDK (5.0.408)

安装诊断工具

在服务器上安装dotnet tool下的诊断工具

dotnet-counters 是一个性能监视工具，用于临时运行状况监视和初级性能调查。
dotnet-dump 是在未涉及任何本机调试器的情况下收集和分析 Windows、Linux 和 macOS 转储的方法。可以运行 SOS 命令来分析崩溃和垃圾回收器 (GC)

shell 复制代码

dotnet tool install -g dotnet-counters
dotnet tool install -g dotnet-dump

安装过程中可能遇到的问题：

1. Https 访问证书问题

NuGet.Protocol.Core.Types.FatalProtocolException: 无法加载源 https://api.nuget.org/v3/index.json 的服务索引。

---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.

---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot

执行openssl version -a查找安装目录，然后执行cp /etc/pki/tls/cert.pem /usr/local/openssl-1.1.1o/ssl/命令将默认证书放到SSL目录

2. dotnet tool 版本问题

Unable to find package dotnet-counters. No packages exist with this id in source(s): nuget.org

或

error NU1202: Package dotnet-counters 8.0.452401 is not compatible with net5.0 (.NETCoreApp,Version=v5.0) / any. Package dotnet-counters 8.0.452401 supports: net6.0 (.NETCoreApp,Version=v6.0)

根据服务器上的.NET SDK版本，指定版本号完成的安装。版本号：https://www.nuget.org/packages/dotnet-counters

分析过程

通过Top命令查看进程资源占用情况，输入M按内存使用百分比排序，并获取到程序PID。

运行dotnet-counters monitor -p 6309，查看程序运行信息，发现Gen 2和LOH占用大量内存。

关于GC相关内容可以看官方文档ASP.NET Core 中的内存管理和模式

（上面两张截图是事后截取的，作演示用）

运行dotnet-dump collect -p 6309，在当前目录生成程序内存dump文件

运行dotnet-dump analyze core_20231026_162034分析dump文件，进入交互式shell，通过SOS命令分析文件内容。相关SOS命令可以查看官方文档dotnet-dump 诊断工具

运行dumpheap -stat -min 85000，查看大于85000 B的对象，可以看到有78个大System.Byte[]类型的对象。

运行dumpheap -mt -min 85000查看具体的大对象列表。GC 会为大型对象（大于 85,000 字节）创建特殊内存区域，称为大型对象堆 (LOH)。

运行dumpobj 00007fdfbd54ead0，查看对象内容。

比对下各个对象内容，大部分为乱码，少数显示Exif和JFIF等字符。联想到最近项目更新中包含了一部分图片处理相关功能，因此初步怀疑是ImageResize的代码有问题，导致了内存泄漏。

运行gcroot 00007f8c51457968，查看对象引用情况，没有任何对象引用。

重写修改了代码后上线，随着相关接口被调用，程序的内存占用依旧会上涨。通过dotnet-counters查看发现Gen2和LOH占用大量内存没有被回收。

查阅官方文档的过程中发现，临时大对象会导致第 2 代 GC，但是不理解为什么这些内存没有被回收。

解决方案

2023-10-27 更新 ：原本项目中使用System.Drawing对图片进行压缩处理，综合考虑后选择使用SixLabors.ImageSharp重写这部分代码。目前更新在线上观察一段时间。