我想知道一个程序是否显示大量（或系统中最高的）页面错误，让我们说进入任务管理器或进程资源管理器，这是否表明内存碎片。有没有其他方法可以揭示这种问题？ （内存碎片）。因此，运行时出现大量页面错误的程序可能来自不在 RAM 中但操作系统经常中断从磁盘加载的数据。一个可能的原因可能是内存碎片？我想知道这两件事是否相关
【问题讨论】：
标签： c++ windows memory-management page-fault
来自维基百科：
当程序尝试访问当前未映射到物理内存 (RAM) 的页面时，会执行分页的主要功能。这种情况称为页面错误。然后操作系统必须以程序不可见的方式控制并处理页面错误。因此，操作系统必须：
确定数据在二级存储中的位置。获得一个 RAM 中的空页框用作数据的容器。加载 请求的数据到可用的页框。将页表更新为 参考新的页框。将控制权交还给程序， 透明地重试导致页面错误的指令。
因此，我会说碎片通常与页面错误无关。后者表明 RAM 内存已满，并且该特定程序比其他程序消耗更多内存，因此他在交换区域中有更多内存，因此每次他尝试访问已被操作系统换出的页面时发生故障，操作系统必须将此页面加载到 RAM。
如果您正在使用单个进程试验此错误。如果您在 ALL 过程中观察到相同的问题，则表明 Thrashing。在这种情况下，物理内存的数量不足以容纳所有正在运行的进程，因此虚拟内存子系统在分页上花费了更多时间。因此，进程不会继续进行，因为每次发生页面错误时，进程都会失去 CPU 并且必须等待页面在 RAM 中准备好。
当您的内存映射包含几个无法满足新预留的小块时，通常会发生碎片，因此进程开始要求更多内存以容纳它们。因此，这种情况下的症状是更高的内存使用率或内存没有释放到操作系统，即使程序完成了一些应该分配动态内存的特定任务，做一些事情然后释放它。
【讨论】：
大量页面错误往往是由对常驻内存的高需求引起的。内存碎片可能是对常驻内存的高需求的根本原因，但这不是我的第一个猜测。
也许问题只是需要那么多驻留内存。
也许问题需要那么多虚拟内存，但算法设计不佳（访问局部性差），因此对常驻内存的需求高于应有的水平。
也许程序编码不好，所以它使用的内存比它需要的多得多。
也许任务对常驻内存的需求是完全合理的（考虑到可用的物理内存），但微软的脑死内存管理算法无缘无故地产生了压倒性的页面错误。
大多数页面错误是“软”错误，这意味着实际上不需要磁盘活动。操作系统已将页面从任务中移除，但并未从物理内存中删除这些页面，以此作为测试任务真正需要哪些页面的手段，其长期目标是保持该任务的“工作集”不增长（微软滥用术语“工作集”）。这对于操作系统来说都是必要且正确的行为。
但是当任务需要快速返回这些页面时，您会遇到一个软故障，即操作系统将这些页面返回并带走其他页面，而不是意识到该任务需要更高的总驻留 RAM 并且有足够的物理 RAM 来执行容纳它。我见过很多情况，其中处理软故障的单线程内核 CPU 时间是长程序所用时间的 90% 或更多，而大多数机器的 ram 只是闲置。
【讨论】：
VirtualLock.，或通过SetProcessWorkingSetSize 进行软声明。同样，这些算法不是通灵的，因此您可以通过向它们提供有关将要发生的事情的信息来提供帮助。