我有一个相当简单的应用程序，它接收一个包含大约500k行数据的数据文件，解析数据，组织它然后将其插入Azure表。大约有2000个这样的文件，我需要在加载所有数据的过程中顺利运行。
我使用WindowsAzure.Storage v5.0.2插入数据，使用Microsoft.tpl.dataflow v4.4.24进行并行化。在移动到下一个文件之前，每个文件都已完成处理并且所有任务已完成。我也处理了所有可能的对象，并在每个文件加载结束时将其他所有内容设置为Null。
尽管尝试尽可能小心，但RAM使用率会稳步上升，直到崩溃进程为止。当它启动时，它会跳转到1 GB的RAM并稳步爬升，直到进程崩溃超过9GB的RAM消耗。 注意 - 这是在一台相当大的计算机上定位x64。垃圾收集定期进行，但似乎不会影响内存问题。
此时我对内存泄漏的来源完全感到困惑，并且对如何诊断问题一无所知。
更新
经过大量工作并遵循以下建议后，我发现我使用的并行化允许更多的同步插入过程比我预期的更多。看起来插件已经完成，我的代码正在开始下一个插入。实际上，并行流程刚刚报告了状态但尚未完成。这导致了大量的同步插入积压，扼杀RAM并使系统崩溃。这也让我超过了我的IOPS限制，我认为触发了限制，使问题复杂化。
解决这个问题需要大量的工作和许多不同的分析方法，但下面的建议让我朝着正确的方向前进。
答案 0 :(得分：0)
搜索“故障排除.net内存泄漏”会产生大量结果，但最好的结果可能是http://blogs.msdn.com/b/tess/archive/2009/05/12/debug-diag-script-for-troubleshooting-net-2-0-memory-leaks.aspx。
基本上，使用DebugDiag生成内存泄漏分析报告，然后查找哪些对象占用了所有内存。您可能会看到一种类型的对象，您没有意识到您不断添加到集合中而不会在以后删除它。