控制需要大量内存的多线程应用程序答案

【问题标题】：Control Memory-Hungy Multi-Threaded App控制需要大量内存的多线程应用程序
【发布时间】：2012-02-21 05:43:16
【问题描述】：

这是一个非常开放的问题。

基本上，我有一个计算应用程序，可以启动 N 个场景的测试组合。
每个测试都在一个专用线程中进行，包括读取大型二进制数据、对其进行处理并将结果放入数据库。

如果线程数太大，应用程序会变得流氓，耗尽所有可用内存并挂起。 利用所有 CPU+RAM 功能的最有效方法是什么（高性能计算，即 12 核/16GB RAM）不会让系统崩溃（如果“启动了太多”并发线程，“太多”当然是一个相对概念）

我必须指定我有一个包含 N 个工人的工人缓冲区队列，每次一个人完成并死亡时，都会通过队列启动一个新的人。到目前为止，这工作得很好。但我想避免“手动”和“凭经验”设置同时线程的数量，并拥有一个智能的可扩展系统，该系统在系统可以正确处理的情况下一次丢弃尽可能多的线程，并停止在“合理”的内存使用（目标服务器专用于应用程序，因此除了系统之外的其他应用程序没有问题）

PS：我知道 .Net 3.5 带有线程池，而 .Net 4 具有有趣的 TPL 功能，我现在仍在考虑这些功能（到目前为止我还没有深入研究过）。

PS 2：阅读this post 后，我对“不要这样做”的答案感到有些困惑。虽然我认为这样的要求对于内存要求很高的计算程序来说是公平的。

编辑
看完this post我会尝试使用WMI features

【问题讨论】：

线程池从1.0开始就在.NET中
如果最大化性能是唯一目标，对我来说听起来很简单。您永远不想拥有比 CPU 内核更多的线程。如果事实证明您没有足够的 RAM，则硬件不平衡。添加更多内存。不要忘记现实检查，实际检查所有核心是否达到 100%。如果不是，那么线程不是解决方案。使用太多线程只会产生问题。
@HansPassant 确实如此，但前提是线程不阻塞（文件 i/o 等），如果有更多可能有助于保持性能。
@kenny - 如果有阻塞线程，那么瓶颈就在其他地方。总是 I/O。添加更多线程不会使 I/O 更快。
@HansPassant true，但它可以让CPU做其他未被阻塞的操作。

标签： c# .net performance

【解决方案1】：

.NET 中的所有内置线程功能都不支持根据内存使用情况进行调整。您需要自己构建它。

您可以预测内存使用情况或对内存不足的情况做出反应。替代品：

在启动新任务之前查看系统上的可用内存量。如果它低于 500mb，请等待释放足够的空间。
在任务到来时启动任务，并在其中一些任务因 OOM 而开始失败时立即进行限制。稍后重新启动它们。这种替代方法很浪费时间，因为您的进程会疯狂地进行垃圾收集以避免 OOM。

我推荐（1）。

您可以查看可用系统内存或您自己的进程内存使用情况。为了获得内存使用情况，我建议使用 Process 类查看私有字节。

如果您在 16GB 系统上留出 1GB 的缓冲区，那么您的运行效率会达到 94%，而且非常安全。

【讨论】：

是的 2 绝对糟透了 :-) 而 1 就是我要做的。但我想看看在被称为异端之前我会被扔多少石头^^有可用的代码吗？
刚刚偶然发现这篇文章中发现的 WMI 功能：stackoverflow.com/questions/3296211/… 此处参考：msdn.microsoft.com/en-us/library/windows/desktop/… 听起来很有趣。
我添加了一条关于如何了解内存使用情况的注释。手动猜测的内存限制会很好。只要确保在收到 OOM 时给自己发送一封电子邮件，以便进行调整。
哦，好的，我明白了。我可以使用 WorkingSet64 并将其限制为系统总内存的百分比。我必须使用 VisualBasic.Devices.ComputerInfo.TotalPhysicalMemory （虽然它听起来令人困惑，但不是 VB 特定的），正如 Hans Passant 在我在编辑中引用的 pos 中所建议的那样
不，不要使用工作集。工作集是当前分页的内存量（粗略地说）。它可以在你的应用程序不做任何事情的情况下改变！使用内存计数器要非常小心......正如我所说的那样使用私有字节。私有字节是不与其他进程共享的内存。它大致对应于您的分配。不幸的是，无论是在 Windows 上还是在 Linux 上，都没有一个计数器可以告诉您真实的内存使用情况（由于共享，这样的事情不存在）。