linux下如何测试缺页率?

用ps命令可以查看进程 page fault信息

ps -eo min_flt,maj_flt,pid,%cpu,%mem,pagein,args --sort=min_flt

min_flt 是页分配是的缺页

maj_flt, 是磁盘读写时的缺页

pagein 是 从磁盘加载页面回物理内存。

一个理想的程序，稳定运行的时候这几项数值应该不会再变化。如果发现程序每秒的数值增加的比较多，那就是有问题了。

不知道你从哪里看到的一个 缺页率的概念。

微软的文档 只说page fault per second

http://technet.microsoft.com/en-us/library/cc768048.aspx。

SAP的文档 http://help.sap.com/saphelp_nw04/helpdata/en/84/7ed390d81f11d188be0000e83539c3/content.htm

这里有个缺页率的说法？ 指的其实就是 Pages Input/sec 。

如果是这个话，linux你可以用ps 命令，top 命令， perf命令之类查看这几个值，然后算一下每秒个数吧。我在另外一个帖子已经回复你了。

-----------------------------------------------

至于你这里说的 主存的总次数，这个东西几本不可能统计的出来。你知道内存都是分为一个page 一page，比如说4k的大小。 但程序内存访问肯定不是每次都是4k大小的。

cpu是有写内存访问相关的硬件计数信息，这个可以通过一些性能测试工具，可以算出cpu上的内存带宽。但这个其实和你那恶主存总访问次数关系不大，因为我看你这个是想用来计算所谓的“缺页率”的。内存访问其实很多时候都不是在一个page上面连续的。有可能地址是离散的，没法统计什么的主存访问计数。

另外cpu的cache有很多级，L1 cache ， L2 L3 cache扽。真正的到达 主存的其实已经很少了，最求程序性能其实很多 时候关注的是 L1 L2 这些级别缓存的命中率。这些都可以通过性能测试工具读取得到。

------------------------------------

至于为什么有page fault可以有很准确的计数，是因为发生page fault的时候，硬件会通过中断通知系统内核。 然后其实微软的文档说的 page input ， page output等都是说的swap交换内存到磁盘的磁盘 *** 作。这个信息前面的帖子我前面也给你列出来了。还有vmstat这些命令应该也是可以看到 swap分区的使用情况的。

这东西其实没必要那么死扣字眼，理解原理就可以了。想page fault这个，就知道为什么会影响性能，怎么判断page fault是不是对程序影响很大就行了。

看你老来提问，写了好多。。。。。。。

以32位的Linux系统为例，每个进程独立拥有4GB的虚拟地址空间，根据局部性原理没有必要也不可能为每个进程分配4GB的物理地址空间。

64位系统也是一样的道理，只不过空间寻址范围大了很多很多倍，进程的虚拟地址空间会分为几个部分：

实际上只有程序运行时用到了才去内存中寻找虚拟地址对应的页帧，找不到才可能进行分配，这就是内存的惰性(延时)分配机制。

对于一个运行中的进程来说，不是所有的虚拟地址在物理内存中都有对应的页，如图展示了部分虚拟地址存在对应物理页的情况：

虚拟地址空间根据固定大小一般是4KB进行划分，物理内存可以设置不同的页面大小，通常物理页大小和虚拟页大小是一样的，本文按照物理页4KB大小展开。

经过前面的分析，我们将面临一个问题： 如何将虚拟地址准确快速地映射到物理页呢？

CPU并不直接和物理内存打交道，而是把地址转换的活外包给了MMU，MMU是一种硬件电路，其速度很快，主要工作是进行内存管理，地址转换只是它承接的业务之一。

一起看看MMU是如何搞定地址转换的。

每个进程都会有自己的页表Page Table，页表存储了进程中虚拟地址到物理地址的映射关系，所以就相当于一张地图，MMU收到CPU的虚拟地址之后开始查询页表，确定是否存在映射以及读写权限是否正常，如图：

对于4GB的虚拟地址且大小为4KB页，一级页表将有2^20个表项，页表占有连续内存并且存储空间大，多级页表可以有效降低页表的存储空间以及内存连续性要求，但是多级页表同时也带来了查询效率问题。

我们以2级页表为例，MMU要先进行两次页表查询确定物理地址，在确认了权限等问题后，MMU再将这个物理地址发送到总线，内存收到之后开始读取对应地址的数据并返回。

MMU在2级页表的情况下进行了2次检索和1次读写，那么当页表变为N级时，就变成了N次检索+1次读写。

可见，页表级数越多查询的步骤越多，对于CPU来说等待时间越长，效率越低，这个问题还需要优化才行。

MMU和TLB的故事就这样开始了...

CPU觉得MMU干活虽然卖力气，但是效率有点低，不太想继续外包给它了，这一下子把MMU急坏了。

MMU于是找来了一些精通统计的朋友，经过一番研究之后发现CPU用的数据经常是一小搓，但是每次MMU都还要重复之前的步骤来检索，害，就知道埋头干活了，也得讲究方式方法呀！

找到瓶颈之后，MMU引入了新武器，江湖人称快表的TLB，别看TLB容量小，但是正式上岗之后干活还真是不含糊。

当CPU给MMU传新虚拟地址之后，MMU先去问TLB那边有没有，如果有就直接拿到物理地址发到总线给内存，齐活。

TLB容量比较小，难免发生Cache Miss，这时候MMU还有保底的老武器页表 Page Table，在页表中找到之后MMU除了把地址发到总线传给内存，还把这条映射关系给到TLB，让它记录一下刷新缓存。

TLB容量不满的时候就直接把新记录存储了，当满了的时候就开启了淘汰大法把旧记录清除掉，来保存新记录，彷佛完美解决了问题。

在TLB和Page Table加持之下，CPU感觉最近MMU比较给力了，就问MMU怎么做到的？MMU就一五一十告诉了CPU。

CPU说是个不错的路子，随后说出了自己的建议：TLB还是有点小，缓存不命中也是经常发生的，要不要搞个大的，这样存储更多访问更快？

MMU一脸苦笑说道大哥TLB很贵的，要不你给涨点外包费？话音未落，CPU就说涨工资是不可能了，这辈子都不可能了。

设想 CPU给MMU的虚拟地址在TLB和Page Table都没有找到对应的物理页帧或者权限不对，该怎么办呢？

没错，这就是缺页异常Page Fault， 它是一个由硬件中断触发的可以由软件逻辑纠正的错误 。

假如目标内存页在物理内存中 没有对应的页帧或者存在但无对应权限 ， CPU 就无法获取数据 ，这种情况下 CPU就会报告一个缺页错误 。

由于CPU没有数据就无法进行计算，CPU罢工了 用户进程也就出现了缺页中断 ，进程会从用户态切换到内核态，并将缺页中断交给内核的 Page Fault Handler 处理。

缺页异常并不可怕，只要CPU要的虚拟地址经过MMU的一番寻址之后没有找到或者找到后无权限，就会出现缺页异常，因此触发异常后的处理流程将是重点内容。

缺页中断会交给PageFaultHandler处理，其根据缺页中断的不同类型会进行不同的处理：

不同类型的Page Fault出现的原因也不一样，常见的几种原因包括：

本文粗浅地和大家一起学习了Page Fault的相关知识点，包括Linux虚拟地址和物理地址的关系、CPU获取内存数据的过程、MMU和TLB&页表的协同配合、缺页异常产生的原因和分类处理。

本文并没有对MMU的内部机制、内核态&用户态缺页异常、缺页异常处理函数等内容进行展开，主要是因为这部分内容相对晦涩，还得靠自己深入研究。

---