某天收到运维线上警报，服务器内存告警，需要处理一下。此时通过浏览器打开页面，系统可以正常访问，但是有明显卡顿。为了不影响客户使用，先重启了服务释放了内存。由于该项目平时访问量并不大，因此随着程序运行内存占用率的增长比较缓慢，直到第三天才发现从原本的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)
dotnet tool install -g dotnet-counters
dotnet tool install -g dotnet-dump
安装过程中可能遇到的问题：
1. Https 访问证书问题
执行openssl version -a查找安装目录，然后执行cp /etc/pki/tls/cert.pem /usr/local/openssl-1.1.1o/ssl/命令将默认证书放到SSL目录
2. dotnet tool 版本问题
根据服务器上的.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重写这部分代码。目前更新在线上观察一段时间。