鬼吹灯全集mp3笔者团队发现现网服务负载即将达到瓶颈，但cpu利用率并未达到瓶颈，基于充分利用机器资源的考量，研发同学提出：“降低nginx worker数，腾出一部分内存，随后提高业务程序worker数，从而提升业务处理能力

　　为了确保方案的可靠实施，我们需要在充分理解free/ps/top等命令有关内存信息准确含义的前提下，分析机器当前的内存情况、以及各worker的内存占用情况，明确nginx和业务程序的worker数分别调低和调高多少，既不会出现内存紧张、又能充分利用机器资源，于是有了本文的几个demo实验。

　　虚拟内存——虚拟内存是计算机系统内存管理的一种技术。它使得应用程序认为它拥有连续可用的内存（一个连续完整的地址空间），而实际上，它通常是被分隔成多个物理内存碎片，还有部分暂时存储在外部磁盘存储器上，在需要时进行数据交换。与没有使用虚拟内存技术的系统相比，使用这种技术的系统使得大型程序的编写变得更容易，对真正的物理内存（例如RAM）的使用也更有效率。[1]

　　缺页中断——页缺失（英语：Page fault，又名硬错误、硬中断、分页错误、寻页缺失、缺页中断、页故障等）指的是当软件试图访问已映射在虚拟地址空间中，但是目前并未被加载在物理内存中的一个分页时，由中央处理器的内存管理单元所发出的中断。[3]

　　上面的概念大家或多或少都了解一些，下面我们从代码及进程启动后的内存占用情况来一一说明。

　　可以看出，进程的虚拟内存占用为994340KB，与入参申请分配的大小基本一致；而实际物理内存占用仅1MB，说明执行new分配内存只是操作系统内部做了一个标记，不会立刻实际分配。

　　既然new完不会立刻实际分配，那我们会想，最大能new多大的内存？现在我们继续用上节的代码实验一下：

　　3，free命令的输出无明显变化。“虚拟内存”的占用，在free命令无法展示出来。（这个结论很重要）

　　接上节，我们再来验证一下，如果分多次申请10GB的行为在同一个进程内，会出现什么结果？

　　说明上节的结论依然有效，单个进程new过的内存20GB，已经超出机器总内存。

　　目前我们已经涉及到overcommit和OOM killer的概念，操作系统允许特定条件下申请内存数大于系统内存，本质上它是系统为了充分利用资源而提供的一种特性。

　　commit(或overcommit)针对的是内存申请，内存申请不等于内存分配，内存只在实际用到的时候才分配。[5]关于更详细的解释，大家可以去看这篇参考文献，这里举一个关闭overcommit的例子：

　　overcommit_memory这个内核参数用于控制内核对overcommit的处理行为，最常用的是默认值0，上面我改成2（代表禁止overcommit）再去申请分配10GB内存会立刻报失败。这个值在多数场景下取默认值比较好。现在改回默认值继续下文实验。

　　1，ps的VSZ和RSS都是900多MB，与入参1GB相符，说明memset的内存写操作触发了真实物理内存的占用。

　　2，free命令展示的used、free、available值在程序执行前后分别变动了900多MB，与结论1相印证。

　　2，free变少900多MB，说明机器直接从free里面取的，而没有释放buff/cache，这可以理解，因为free还够用。

　　现在继续用上节的代码，我们来看一下用户进程占走buff/cache的情况，我new 5GB内存：

　　说明进程新占用的5GB内存，有3GB来自原来的空闲物理内存，有2GB来自内核从缓存中释放出来的内存。

　　内核的策略是优先用free里面的，用到剩差不多100MB的时候，开始从缓存中释放内存给用户进程使用。

　　我们看到前文的内存申请有时失败，有时成功。那么成功与否的条件到底是什么，是内核Heuristic overcommit算法在每次申请时计算出来的一个值[5]，不考虑swap的话这个值大致就是available列的值。

　　部分老版本系统的命令输出可能会有一些差异，这里再以CentOS 6, Linux 2.6.32.43上的输出为例进行一点补充说明。

　　现在你再看buff/cache那行开头的“-/+”符号，明白它的含义了吗？[7]分别代表Mem行的used减去、free加上（buff+cache）后的值。即公式：

　　看完demo，该回正题了，调整worker数时候到底该关注哪个内存指标？

　　我的观点是，不能只看available，它只代表当前瞬时的可用内存；还要关注你的代码行为预期。

　　如果你的程序是python等GC型编程语言，那你不能只关注瞬时情况，还需要对程序的内存占用情况进行一段时间观察，尤其是GC期间的内存波动情况，可能出现短时大量虚拟内存发生缺页占用物理内存的情况；

　　如果是c++等自主管理内存的程序，那你应该对自己程序的内存占用有一个清晰的预判：多个进程情况下总overcommit多少内存是ok的，超出多少会有多大概率发生OOM。