C# 调试长时间运行的mono/C应用程序中的内存泄漏

我有一个C#程序，在Ubuntu虚拟机上运行，作为使用mono 5.10的服务器。偶尔，程序开始使用大量内存，直到最终崩溃。这样的内存泄漏发生通常需要几天的时间，而且我无法在本地重现这个问题

在过去的几天里，我使用mono log profiler来按需收集堆照片。这给了我一个15Gb以上的文件。当内存泄漏发生时，我设法从中获取了一个heapshot，它在Xamarin profiler中显示如下：

运行

mprof report

也会生成类似的无用报告

两者都不能真正帮助调试问题。显然threadpool有问题，但似乎没有办法弄清楚是什么

能够查看对象的分配位置可能会有所帮助，但这需要在探查器中启用

alloc

，这是不可能的，因为它将生成文件大小

是什么导致了大量的

IThreadPoolWorkItem

s？应用程序使用了30-40%的CPU，因此任务的调度速度似乎不会超过CPU的处理速度

有没有办法列出线程池作业引用的对象？这至少可以让我确定哪段代码运行得如此频繁<代码>mprof报告仅显示我所能看到的反向引用，这没有多大帮助，因为

IThreadPoolWorkItem

显然属于

线程池

本身

更新：任务没有（磁盘）IO绑定。泄漏时，读取速度为每秒10 kbs，这不会使磁盘饱和

再想一想：如果计划了很多任务，我是否也应该看到很多独立的

IThreadPoolWorkItem

对象？由于

IThreadPoolWorkItem

不是一个结构，因此实际对象应该有一个单独的条目，

IThreadPoolWorkItem[]

将只是一个指针数组。因此，这表明那些

IThreadPoolWorkItem[]

s只是（大部分）空

null

指针的数组

---

更新：

线程池。GetAvailableThreads

显示2个工作线程和0个完成端口线程处于活动状态，这似乎表明

线程池运行正常。自定义日志还再次表明，我没有安排太多的任务，并且安排的任务很快就完成了。
该应用程序使用了30-40%的CPU，因此任务的安排速度似乎不会超过CPU的处理速度。
或者可能是
任务
是IO绑定的？@mjwills似乎不太可能，因为我在监控中没有看到任何IO峰值。但下次发生内存泄漏时，我会再次检查。