经过繁重的操作（50,000,000 次迭代）后，可用磁盘空间急剧减少答案

【问题标题】：After a heavy operation (50,000,000 iterations) free disk space extremely decreased经过繁重的操作（50,000,000 次迭代）后，可用磁盘空间急剧减少
【发布时间】：2010-11-20 07:05:00
【问题描述】：

我开发了一个基准式控制台应用程序 (C# 4.0)。在 50,000 或 1,000,000 次迭代中运行良好。然后我将迭代次数增加到 50,000,000。但它花了太多时间，我强迫它退出。该应用程序正常退出，但在我的主驱动器 (C:) 中仍然只有 3.8 GB 可用。测试前可用空间为 14 GB。有 10 GB 被吃掉了！！！请问，谁能解释一下为什么会这样？

大家好，

我在我的项目目录中发现了 *.vsp 文件（9 GB !!!）。是的，这似乎很愚蠢，因为我查找了主驱动器上的每个系统|隐藏文件夹，但我从未想过这个巨大的文件可能在我的项目文件夹中。 50,000,000 次迭代后，我觉得我的系统变慢了，我在 VS2010 中运行了性能向导。但是迭代次数很少，所以我没想到性能向导可以创建这么大的文件！谢谢大家！

【问题讨论】：

你在迭代中做了什么？
执行字符串操作（使用 StringBuilder）。还使用秒表来检索执行时间。
尝试在系统上搜索新文件，你可能会找到一个大文件。听起来它可能是保存在某处的故障转储文件。看看这是否有帮助：msdn.microsoft.com/en-us/library/fk551230.aspx

标签： c# windows-7 window benchmarking

【解决方案1】：

如果没有更多信息（比如测试实际做了什么），我的猜测是程序像筛子一样泄漏了内存，Windows 通过稳定增加交换/分页文件的大小来弥补，在这个过程中占用了你的硬盘空间.你可以看看你的C:\pagefile.sys，看看它有多大。

【讨论】：

其实测试是关于字符串的。仅使用字符串操作和秒表。
您是否将所有参考资料都保存在某个地方？也许您的测试会记录日志？也许使用WinDirStat 来查看所有空间都去了哪里？
不，测试不包括任何 IO 操作。只实现了字符串操作（更准确地说是 StringBuilder.Append() 方法）。
是的，您的建议有帮助：WinDirStat。谢谢！

【解决方案2】：

原因 - 它可能取决于您的字符串操作（例如执行连接与使用 StringBuilder）。

至于空间在哪里，前面说了很可能是你的页面文件。

如果是你的页面文件，回收空间的方法是通过Windows手动将页面文件的大小调整为远低于当前值，然后重新启动。

Windows 键 + 暂停/中断，单击高级系统设置，在性能下，单击设置... 在出现的性能选项窗口中，在虚拟内存下，单击更改...告诉 Windows 停止自动管理页面文件大小。单击 C: 驱动器并将其设置为比现在小得多的自定义大小（例如尝试 1024MB）。

重新启动您的机器，页面文件现在应该更小了。在您重新启动之前，该空间仍将被使用。

您可能希望将分页文件大小重新设置为由 Windows 自动管理。

如果您需要一些帮助来避免导致相同问题的代码，您可能需要提供一些代码 sn-ps。

【讨论】：

更改页面文件大小？我假设您将在重新启动之前进行更改，在这种情况下，您不会注意到任何性能差异。这是基于您将其设置回之后自动管理的假设。如果您将其保持在该大小，即不要让 Windows 再次控制它，您只会注意到拥有一个小页面文件的性能影响。这是非常循规蹈矩的事情，不会给您带来任何问题。

【解决方案3】：

我猜这是因为虚拟内存交换页面增加了，因为 GC 没有在您的迭代循环中运行并且内存使用量增加，然后最终内存被交换到页面文件。有关控制台应用程序中 GC 的更多信息，请参阅http://support.microsoft.com/kb/828988。我从未尝试过，但我认为使用 MTAThread 属性会有所帮助。

【讨论】：

【解决方案4】：

交换空间（虚拟内存）的临时文件。

您的应用会创建文件吗？它使用了多少内存（任务管理器）？

【讨论】：

对不起，我不记得了。我认为它没有得到太多的记忆。但我记得它在 2-3 分钟后使用了 1,700,000 个周期（进程资源管理器、进程属性窗口、.NET 选项卡）