.NET 进程可以分配的最大内存 [英] Maximum Memory a .NET process can allocate
问题描述
垃圾收集器可以为 .NET 进程分配的最大内存是多少?当我编译到 x64 时，Process.GetCurrentProcess.MaxWorkingSet 返回大约 1.4GB，但是当我编译到 AnyCPU (x64) 时返回相同的数字.对于 x64，它应该更像是任务管理器中显示的限制"值.我如何获得在所有情况下超过时都会导致 OutOfMemory-Exceptions 的正确数字?
What is the maximum memory the garbage collector can allocate for a .NET process? When i compile to x64, Process.GetCurrentProcess.MaxWorkingSet returns about 1,4GB, but when i compile to AnyCPU (x64) the same number is returned. For x64 it should be more like the "Limit" value that is displayed in the Task Manager. How can i get the correct number that will cause OutOfMemory-Exceptions when exceeded in all cases?
该方法应该返回的一些示例:
Some examples what the method should return:
1)机器配置:x64-Windows，4GB物理内存，4GB页面文件
-作为 64 位进程:8GB
- 作为 32 位进程:1.4GB
1) Machine Configuration: x64-Windows, 4GB physical memory, 4GB page file
-As 64-Bit process: 8GB
-As 32-Bit process: 1.4GB
2) 机器配置:x64-Windows，1GB物理内存，2GB页面文件
-作为 64 位进程:3GB
- 作为 32 位进程:1.4GB
2) Machine Configuration: x64-Windows, 1GB physical memory, 2GB page file
-As 64-Bit process: 3GB
-As 32-Bit process: 1.4GB
3) 机器配置:x32-Windows，4GB物理内存，4GB页面文件
-作为 64 位进程:不会发生
- 作为 32 位进程:1.4GB
3) Machine Configuration: x32-Windows, 4GB physical memory, 4GB page file
-As 64-Bit process: Won't happen
-As 32-Bit process: 1.4GB
4) 机器配置:x32-Windows，512MB 物理内存，512MB 页面文件
-作为 64 位进程:不会发生
- 作为 32 位进程:1.0GB
4) Machine Configuration: x32-Windows, 512MB physical memory, 512MB page file
-As 64-Bit process: Won't happen
-As 32-Bit process: 1.0GB
推荐答案
Windows 可以配置为按需分配更多页面文件空间，或者 应要求提供.
作业对象 可以防止消耗超过一定的内存量.
堆的碎片化和它的分代性质(加上需要在大对象堆中放置大的东西)
Windows can be configured to allocate more page file space on demand, or on request.
Job objects can prevent the consumption of more than a certain amount of memory.
Fragmentation of the heap and the generational nature of it (plus the need to put large stuff in the Large Object Heap)
所有这些都意味着硬限制在现实中并没有多大用处，并且意味着回答理论上我可以分配多少内存"的问题比您想象的要复杂得多.
All these mean that the hard limit is not much use in reality and means answering the question "how much memory could I theoretically allocate" is rather more complex than you think.
因为它很复杂，任何人问这个问题都可能是在尝试做一些错误的并且应该将他们的问题重定向到更有用的东西.
Since it is complex anyone asking that question is probably trying to do something wrong and should redirect their question to something more useful.
你想做什么，似乎有必要提出这样的问题?
What are you trying to do that would appear to necessitate such a question?
"我只想知道进程的当前内存负载何时会出现问题这样我就可以采取一些措施，例如释放自定义缓存中的某些项目."
"I just want to know when the current memory load of the process could get problematic so I can take actions like freeing some items of a custom cache."
没错.这是一个更容易处理的问题.
Right. this is much more tractable a question.
按复杂程度排序的两种解决方案:
Two solutions in order of complexity:
- 让您的缓存使用 WeakReferences
- 这意味着系统几乎会神奇地为您释放内容，但您几乎无法控制更换政策等内容
- 这依赖于比键大得多的缓存数据和弱引用的开销
- 这让您可以控制释放内容.
- 您依赖于系统具有适当的 GC 代最大大小，这可能需要一段时间才能达到稳定状态.
注意事项.与重新计算/重新请求数据相比，维护这个庞大的缓存(根据它的声音进入磁盘)是否真的成本更低.
如果您的缓存在通常/连续请求的项目之间表现出较差的局部性，那么将花费大量精力将数据分页进出.具有有效调整的 relpacement 策略的较小缓存很有可能获得更好的性能(并且对其他正在运行的程序的影响要小得多)
Points to note.
Is it really less expensive to maintain this massive cache (going to disk by the sounds of it) than to recalculate/re-request the data.
If your cache exhibits poor locality between commonly/consecutively requested items then much effort will be spent paging data in and out. A smaller cache with an effective tuned relpacement policy stands a good chance of performing considerably better (and with much less impact on other running programs)
顺便说一句:在 .Net 中，由于用于内存管理的核心 CLR 结构的限制，任何大小可变的对象(字符串、数组)的大小都不能超过 2GB.(以上任一解决方案都将从中受益)
As an aside: In .Net, no variable sized object (strings, arrays) can be more than 2GB in size due to limitations of the core CLR structures for memory management. (and either solution above will benefit from this)
这篇关于.NET 进程可以分配的最大内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
