某天收到运维线上警报,服务器内存告警,需要处理一下。此时通过浏览器打开页面,系统可以正常访问,但是有明显卡顿。为了不影响客户使用,先重启了服务释放了内存。由于该项目平时访问量并不大,因此随着程序运行内存占用率的增长比较缓慢,直到第三天才发现从原本的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目录

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

2. dotnet tool 版本问题

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

分析过程

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

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

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

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

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

(上面两张截图是事后截取的,作演示用)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

解决方案

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

11-07 23:07