.NET Core 3.0应用使用NLog/Serilog在Linux下内存泄漏求助

根据你描述的问题细节，我来梳理下可能的根源、排查方向以及是否需要向日志库开发者反馈的建议：

可能的问题根源 #

• 文件日志的Linux平台特定处理缺陷：
  既然Windows环境完全正常，且仅禁用文件日志后内存增长问题消失，核心矛盾大概率出在日志库对Linux文件系统的IO处理上。比如：
  • 日志库的文件句柄或流对象未正确释放：Linux下文件锁、inode的特性和Windows差异很大，若日志库在持久化日志时，没有及时关闭或回收文件相关资源，长期运行的守护进程会积累大量未释放的缓存（也就是你看到的sbyte数组，这些是日志内容的字节缓存）。
  • 批量日志缓存的回收逻辑bug：NLog和Serilog都支持批量写入日志来提升性能，可能在Linux守护进程这种非交互式环境下，缓存的触发回收条件存在问题，导致缓存的sbyte数组无法被GC及时回收，持续占用内存。
• .NET Core 3.0的Linux GC行为特性：
  .NET Core 3.0是比较老旧的版本（官方支持已终止），它在Linux环境下的GC触发策略可能存在局限性——尤其是守护进程这种后台运行、无用户交互的场景，GC可能不会主动回收那些"看似可回收"的对象，直到内存压力达到阈值（这也解释了你设置MemoryMax后GC开始工作、内存稳定的现象）。而日志库的sbyte数组可能因为某些隐式引用（比如未正确释放的文件流上下文）被标记为存活对象，迟迟无法被回收。

下一步排查建议 #

• 调整日志库配置验证：
  • 检查NLog/Serilog的文件日志配置，比如NLog的KeepFileOpen选项、Serilog的File sink的buffered设置，尝试关闭持久化文件句柄或减小缓存批量大小，看是否能缓解内存增长。
  • 开启日志库的调试日志，观察文件写入过程中是否有异常或未预期的资源持有情况。
• 深入分析内存引用链：
  用dotMemory进一步查看那些sbyte数组的引用来源——如果这些数组被日志库的文件写入器、缓存队列等对象持有，就能直接定位到日志库的资源泄漏点。同时对比Windows和Linux下的内存快照，看引用链的差异，确认是否是平台特定的问题。
• 升级.NET Core版本：
  .NET Core 3.0之后的.NET 5/6/7版本修复了大量Linux环境下的GC和IO相关问题，官方也提供长期支持。尝试升级到较新版本，看问题是否自动消失，这也能帮你区分是.NET runtime的问题还是日志库的问题。

是否应该向日志库开发者反馈？ #

完全应该！你已经做了非常充分的对比测试：跨平台差异验证、多日志库复现、禁用文件日志后的验证，还有具体的内存分析数据和临时解决方案，这些信息对开发者定位bug极其有价值。

反馈时记得提供完整的信息：

• .NET Core 3.0的具体版本、Debian 10的内核版本
• NLog/Serilog的具体版本号
• 你的日志配置文件内容
• .service文件的完整配置
• dotMemory快照中sbyte数组的引用链截图（如果可以的话）

内容的提问来源于stack exchange，提问作者Marino F