通用线程: 高级文件系统实现者指南，第 3 部分

　　避免低 VM 情况

　　tmpfs 根据需要动态增大或减小的事实让人疑惑：如果您的 tmpfs 文件系统增大到它耗尽了 所有虚拟内存的程度，而您没有剩余的 RAM 或交换分区，这时会发生什么？一般来说，这种情况是有点讨厌。如果是 2.4.4 内核，内核会立即锁定。如果是 2.4.6 内核，VM 子系统已经以很多种方式得到了修正，虽然耗尽 VM 并不是一个美好的经历，事情也不会完全地失败。如果 2.4.6 内核到了无法分配更多 VM 的程度，您显然不愿意不能向 tmpfs 文件系统写任何新数据。另外，可能会发生其他一些事情。首先，系统的其他一些进程会无法分配更多的内存；通常，这意味着系统多半会变得 极度缓慢而且几乎没有响应。这样，超级用户要采取必要的步骤来缓解这种低 VM 的情况就会很困难，或异常地耗时。

　　另外，内核有一个内建的最终防线系统，用来在没有可用内存的时候释放内存，它会找到占用 VM 资源的进程并终止该进程。不幸的是，这种“终止进程”的解决方案在 tmpfs 的使用增加引起 VM 耗尽的情况下通常会导致不良后果。以下是原因。tmpfs 本身不能（也不应该）被终止，因为它是内核的一部分而非一个用户进程，而且也没有容易的方法可以让内核找出是那个进程占满了 tmpfs 文件系统。所以，内核会错误地攻击它能找到的最大的占用 VM 的进程，通常会是 X 服务器（X server），如果您碰巧在使用它。所以，您的 X 服务器会被终止，而引起低 VM 情况的根本原因（tmpfs）却没有被解决。Ick.

　　低 VM：解决方案

　　幸运的是，tmpfs 允许您在安装或重新安装文件系统的时候指定文件系统容量的最大值上限。实际上，从 2.4.6 内核到 2.11g 内核，这些参数只能在 安装时设置，而不是重新安装时，但我们可以期望在不久的将来可以在重新安装时设置这些参数。tmpfs 容量最大值的最佳设置依赖于资源和您特定的 Linux 主机的使用模式；这个想法是要防止一个完全使用资源的 tmpfs 文件系统耗尽所有虚拟内存结果导致我们前面谈到的糟糕的低 VM 情况。寻找好的 tmpfs 上限值的一个好方法是使用 top 来监控您系统的交换分区在高峰使用阶段的使用情况。然后，确保指定的 tmpfs 上限稍小于所有这些高峰使用时间内空闲交换分区和空闲 RAM 的总和。