linux系统编程-内存管理day05

linux实现了 请求页面调度 （在需要时将页面从硬盘交换进来，当不再需要时再交换出去），这使得系统中进程的虚拟地址空间与实际的物理内存大小没有直接的关系。

交换对进程来说是透明的，应用程序一般都不需要关心内核页面调度的行为。然而在下面 两种 情况下，应用程序可能希望影响系统的页面调度：

POSIX1003.1b-1993定义两个接口将一个或多个页面“锁定”在物理内存，来保证它们不会被交换到磁盘。

调用mlock( )将锁定addr开始长度为len个字节的虚拟内存。成功时函数返回0,失败返回-1,并适当设置errno。

mlockall( )函数锁定一个进程现有的地址空间在物理内存中的所有页面。

flags参数，是下面两个值的 按位或 *** 作，用以控制函数行为：（大部分应用程序会同时设定这两个值）

POSIX标准提供了两个接口用来将页从内存中解锁，允许内核根据需要将页换出至硬盘中。

内存锁定并不会重叠，所以不管mlock( )或mlockall( )了几次，仅一个munlock( )或munlockall( )会解除一个页面的锁定。

linux对于一个进程能锁定的页面数进行了限制：拥有 CAP_IPC_LOCK 权限的进程能锁定 任意多 的页面。没有这个权限的进程只能锁定 RLIMIT_MEMLOCK 个字节，默认情况下，该限制是 32KB 。

mincore( )函数，用来确定一个给定范围的内存是在物理内存中还是被交换到了硬盘中：

函数通过vec来返回向量，这个向量描述start（必须页面对齐）开始长为length（不需要对齐）字节的内存中的页面的情况。

Linux使用 投机性分配策略 ：当一个进程向内核请求额外的内存-如扩大它的数据段，或者创建一个新的存储器映射-内核作出了分配承诺但 实际上并没有分给进程任何的物理存储 。

这样处理有如下几个 优点 ：

超量使用的好处：和在应用请求页面就分配物理存储相比， 在使用时刻才分配物理存储的过量使用机制允许系统运行更多，更大的应用程序 。

但是，如果系统中的进程为满足超量使用而申请的内存大于物理内存和交换空间之和，内核只能杀死另一个进程并释放它的内存，以此来满足下一次的分配需求。

内核允许通过文件/proc/sys/vm/overcommit_memory关闭超量使用，和此功能相似的还有sysctl的vm.overcommit_memory参数。

在严格审计模式中，承诺的内存大小被严格限制在交换空间的大小加上 可调比例 的物理内存大小。

使用严格审计策略时要非常小心！许多系统设计者认为严格审计策略才是解决之道，然而， 应用程序常常进行一些不必要的、且只有使用超量使用才能满足的分配请求，而允许这种行为也是设计虚拟内存的主要动机之一。

“内存并不一定总是快”

Linux 中内存主要有匿名内存和 Page Cache 两种。

Linux *** 作系统内存管理策略是会尽可能的利用内存来做各种缓存，所以一般来说服务器所谓的free内存都会较少，当应用alloc申请内存的时候，如果free内存不足就会引发内存回收，这就是所谓的PageFault缺页，这时候系统会先使用异步方式的后台回收来提高应用申请内存这个 *** 作的响应速度。但是如果应用申请内存的速度大于系统后台回收的速度的话，就会进入所谓直接回收（Direct Reclaim）模式，这是一个同步的过程，应用会自旋等待内存回收完毕，产生比较大的延迟。见下图：

另一方面，内核会回收匿名内存页，并将其置换到磁盘里（这是Linux所谓虚拟内存的管理方式，磁盘上的这部分用来跟内存做交换的空间称为swap空间），匿名内存页一旦被换出然后再次被访问的时候，就会产生文件IO了（要从swap空间里把页加载回内存里），这也会导致比较大的延迟。见下图：

vm.extra_free_kbytes 和 vm.swappiness 两个内核参数可以针对PageFault和SwapOut两种内存访问延迟做调优。mlock 系统调用可以让应用程序“锁定”一块内存空间而不被内核swap出去。

万亿级数据洪峰下的分布式消息引擎-InfoQ

后记：

这篇小文来自于学习RocketMQ开发团队的技术分享文章（见参考），里边的“内存没那么快”观点笔者认为更确切说法应该是“内存并不总是那么快”，里边的Linux内存管理的一小段说明加深了笔者对之前了解的概念的理解，这些东西可能平时工作未必有什么用，但了解底层的东西总是会让人产生求知求所得的愉悦感受。看了阿里褚霸的个人背景简介，“14年c开发经验, 12年网络开发经验, 3年Linux内核开发”，他也遇到过“底层 IO(Input/Output) 技术。IO 技术涉及面非常广，驱动，块设备，文件系统，内存关系等等” ，做专家终归是要走入底层，到最后考验的是对系统、对计算机的理解。本文很水，而脚下这条路不知能走多远，但是想想不为什么就算只为求知的喜悦我也是愿意走下去的啊。这也是我为什么要建“系统底层”这个专题

---