C#如何调查生产中的OutOfMemoryException

我们有一个用C#开发的WCF服务，它在生产环境中运行，每隔几个小时就会崩溃一次，没有可观察的模式。内存使用量将在250mb左右徘徊一段时间，然后突然内存使用量开始上升，直到它崩溃，并出现4gb的OutOfMemoryException（这是一个32位进程）

我们很难识别问题，我们记录的异常来自代码中的不同位置，可能来自另一个试图使用一些内存的请求，它接收到异常

当进程为4gb时，我们进行了内存转储，当崩溃发生时，内存中有大约750k个数据库对象的列表。我们已经查找了上述对象的查询，但无法确定加载整个表的查询。该服务使用EF6调用数据库

另外需要注意的是，这个问题在我们的试生产环境中从未发生过。如果要加载整个表，那么在我们的预生产环境中，数据库中的数据足以实现这一点。可能是一个带有特定参数的特定调用触发了这个问题，但我们无法确定它

我不知道下一步该怎么解决我们的问题。在这种情况下，有没有一种工具可以帮助我们

---

谢谢

如果您想捕获所有SQL并使用实体，您可以这样打印查询

Context.Database.Log=s=>Debug.Print

如果你把它弄得一团糟，你可以把它输出到一个变量，然后把结果保存到文本文件或数据库中。你将不得不把它包装在所有的Db调用中，不知道你的项目有多大

Context.Database.Log=null

关闭它
这听起来像是一个随着时间的推移而逐渐积累起来的记忆案例（追踪起来从来都不有趣）。您已将其标记为WCF，因此我们正在查看引发OOM异常的IIS工作进程（w3wp.exe）？该服务是一个windows服务。我在现场看到过这个问题，内存增长相当快，从250mb到4gb大约需要一分钟。这是我能够进行内存转储的时候。但是，它仍然是一个无限期运行的进程，接收传入的请求，对吗？没错，当内存使用量增加时，它会接收其他请求。它每分钟处理几个请求。您是否尝试记录所有sql以查看正在运行的查询？这很有趣，我认为可以使用实体框架来完成。这应该对我们有所帮助，因为在生产服务器上运行SQL跟踪数小时可能不是最好的解决方案。这个项目相当大，但是内存转储告诉我们加载了哪些实体，所以我们将首先开始记录对这些实体的请求。