防止在控制台应用程序中最小化内存工作集? [英] Prevent memory working set minimize in Console application?
问题描述
我想防止在控制台应用程序中最小化内存工作集.在 Windows 应用程序中，我可以通过覆盖 SC_MINIMIZE 消息来完成.但是，如何在控制台应用程序中拦截 SC_MINIMIZE?或者，我可以通过其他方式阻止内存工作集最小化吗?
我使用 Visual Studio 2005 C++.有人遇到了一些问题，而解决方案并不令人满意.:(http://www.eggheadcafe.com/软件/aspnet/30953826/working-set-and-console-a.aspx
谢谢，提前.
只能通过锁定内存中的页面来防止工作集修剪，或者通过使用 VirtualLock 或通过将内存映射到 敬畏.但是这两个操作都具有极高的特权，并且要求应用程序在被授予内存中的锁定页面"的帐户下运行特权，请参阅如何:启用内存中的锁定页面选项.默认情况下，没有人，不是 vene 管理员，拥有此特权.
从技术上讲，这就是您正在寻找的答案(省略有关如何识别要锁定的区域的次要"细节).但你的问题表明你走在一条完全错误的道路上.
工作集修整是经常发生的事情，没有严重的不利影响.您很可能会将修整与内存分页混淆，但它们是内存页生命周期的不同阶段.当操作系统从进程中取出页面的映射并将页面放入备用列表时，就会发生修剪.这是一个非常快速和简单的操作:页面被添加到备用列表中，pte 是作相应标记.不发生IO操作，物理RAM内容不变.当该进程再次访问修剪过的页面时，将发生软故障.TLB 未命中将触发进入内核区域，内核将在备用列表中定位页面并将其重新分配给进程.快速，快速，简单，再次，没有发生IO操作，也没有页面的任何RAM内容更改.因此，如果一个进程一直引用页面，那么它的所有工作集都被修剪了，它将很快(微秒)重新获得整个活动集.
仅当操作系统需要新页面作为其空闲列表时，它才会查看备用列表，获取最旧的页面并将其实际交换到磁盘.在这种情况下确实会发生 IO 并且 RAM 内容被清零.当进程再次访问页面时，会发生硬故障.TLB 未命中将唤醒内核，这将检查 pte 的列表，现在将发生真正的"页面错误:分配一个新的空闲页面，从磁盘读取内容，然后将页面分配给进程和执行从 TLB 未命中位置恢复.
如您所见，工作集修整和内存压力页面交换之间存在巨大差异.如果您的控制台应用程序被修剪过，请不要担心.通过在内存中锁定页面，您将对系统健康造成无法估量的更多损害.顺便说一句，你也做了类似的糟糕的用户体验，因为你误解了页面生命周期，拒绝最小化.
确实有一些进程有合理的要求，使它们的工作集尽可能保持热状态.所有这些过程总是作为服务来实现的.服务受益于操作系统更宽松的修整策略，而且该策略实际上是可配置的.
如果您真的关心系统内存并希望帮助操作系统，您应该使用 CreateMemoryResourceNotification 并通过释放缓存来应对内存压力，并在收到可用内存的通知时增加缓存.>
I want to prevent memory working set minimize in Console application. In windows application, I can do by overriding SC_MINIMIZE messages. But, how can I intercept SC_MINIMIZE in console application? Or, can I prevent memory working set minimize by other ways?
I use Visual Studio 2005 C++. Somebody has some problem, and the solution is not pleasing. :( http://www.eggheadcafe.com/software/aspnet/30953826/working-set-and-console-a.aspx
Thanks, in advance.
Working set trimming can only be prevented by locking pages in memory, either by locking them explictly with VirtualLock or by mapping memory into AWE. But both operations are extreamly high priviledged and require the application to run under an account that is granted the 'Lock Pages in Memory' priviledge, see How to: Enable the Lock Pages in Memory Option. By default nobody, not vene administrators, have this priviledge.
Technically, that is the answer you are looking for (ommitting the 'minor' details of how to identify the regions to lock). But your question indicates that you are on a totaly wrong path.
Wroking set trimming is something that occurs frequently and has no serious adverse effects. You are most likely confusing the trimming with paging out the memory, but they are distinct phases of the memory page lifetime. Trimming occurs when the OS takes away the mapping of the page from the process and places the page into a standby list. This is a very fast and simple operation: the page is added into the standby list and the pte is marked accordingly. No IO operation occurs, the physical RAM content is not changed. When, and if, the process accesses the trimmed page again a soft fault will occur. The TLB miss will trigger a walk into the kernel land, the kernel will locate the page in the standby list and it will re-allocate it to the process. Fast, quick, easy, again, no IO operation occurs, nor any RAM content changes for the page. So a process that has all its working set trimmed will regain the entire active set fairly quickly (microseconds) if it keeps referencing the pages.
Only when the OS needs new pages for its free list will it look into the standby list, take the oldest page and actually swap it to disk. In this situation indeed IO occurs and the RAM content is zero-ed out. When the process accesses again the page a hard fault will occur. The TLB miss will wake the kernel, this will inspect the pte's list and now a 'real' page fault will occur: a new free page is allocate, the content is read from the disk, and then the page is allocated to the process and the execution resumes from the TLB miss location.
As you can see, there is a huge difference between the working set trimming and a memory pressure page swap. If your console application is trimmed, don't sweat over it. You will do incalculable more damage to the system health by locking pages in memory. And btw, you also do a similar bad user experience by refusing to minimize when asked to, just because you misunderstand the page life cycle.
It is true that there are processes that have a legitimate demand to keep their working set as hot as possible. All those processes, always, are implemented as services. Services benefit from a more lenient trimming policy from the OS, and this policy is actually configurable.
If you are really concerned about the system memory and want to help the OS you should register for memory notifications using CreateMemoryResourceNotification and react to memory pressure by freeing your caches, and grow your caches back when your notified that free memory is available.
这篇关于防止在控制台应用程序中最小化内存工作集?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
