/tmp 的 Linux/UNIX 服务器设置实践

Question

根据你们所看到的，在服务器系统上推荐的 /tmp 配置是什么以及为什么。多年来，我曾就这些观点进行过讨论，但有时存在基本分歧。

以下是我看到的基本问题。有些人可能会建议用几个问题来询问这些问题，但是，我认为如果将这些信息放在一个标题下，管理员可能会更容易些。我相信这将是有益的。

专门用于/tmp：

1. 应该 ln -s /var/tmp /tmp 吗？

2. 是否应该在重新启动之间保留 /tmp？

3. /tmp 应该在真正的磁盘区域上还是允许基本上在 SWAP 区域（或 tmpfs）上实现？

4. /tmp 应该与 /（根）磁盘位于不同的磁盘上吗？

5. 您会将 /tmp 放在与 /（根）磁盘不同的磁盘控制器上吗？

6. /tmp 的大小有什么经验法则吗？

7. 当系统启动时，您将如何管理 /tmp 空间？删除所有文件 > 特定年龄？不理会区域，直到达到最大值的百分比？

8. 是否应实施任何程序项目来管理该领域？

Answer 1

专门用于/tmp：

• 应该 ln -s /var/tmp /tmp 吗？

如果是完整的内存磁盘映像（想想“实时启动 CD”），这可能是可以接受的，因为 RAM 的每个字节都需要压缩。否则，除非您对磁盘空间感到紧张，否则不会。/var 有其自身的特点，在执行系统维护时，将 /tmp 与 /var/tmp 混合可能会产生意想不到的后果。它还添加了一个额外的依赖项，因为 /var/tmp 必须挂载 /var/tmp 才能正常运行；并非所有东西都需要 /tmp，您可能会遇到想要将其迁移到不同分区或驱动器的情况，但不能，因为您不想卸载 /var。

• 是否应该在重新启动之间保留 /tmp？

不。如果您依赖此作为一致的行为，那么您迟早会遇到问题。

• /tmp 应该在真正的磁盘区域上还是允许基本上在 SWAP 区域（或 tmpfs）上实现？

当它被大量使用时，这是一种诱惑——“我们将 /tmp 放入 RAM 磁盘，它会加快访问速度，当系统重新启动/关闭时，没有什么可以清理的”。但是，如果您正在考虑将临时空间实现为将被交换的 RAM 磁盘，那么我会考虑其他程序使用系统交换空间的后果。如果交换是一种“紧急溢出”的形式，当系统陷入困境并需要它时，您最不需要的就是让失控的进程填充 /tmp 消耗交换空间，消耗内存，造成压力要交换到磁盘的 VM 子系统。在交换活动和额外的 I/O 流入 RAM 磁盘（这反过来可能会导致额外的页面输入以满足 seek() ）之间，您的系统将很快成为 I/O 绑定。

• /tmp 应该与 /（根）磁盘位于不同的磁盘上吗？

最好，是的，虽然它不是必需的。如果您大量使用它，或者有需要它的持续工作量，那么绝对可以。假设示例：将临时文件转储到 /tmp 的数据库将通过将 /tmp 引入单独的主轴（即驱动器）来获得轻微的加速。

• 您会将 /tmp 放在与 /（根）磁盘不同的磁盘控制器上吗？

如果您对可恢复性或速度有要求，则应予以考虑。

• /tmp 的大小有什么经验法则吗？

它应该可以容纳 2 倍的预期工作量。我的意思是，如果你有本地用户经常使用这个空间，迟早有人会做一些愚蠢的事情并试图填满它。稍微超额将允许您避免程序停止的奇怪“问题”，因为它们的临时文件已经填满了剩余的空间。

如果这是一个“公共服务”安装，其中服务器提供一个或多个网络服务，但不托管用户，那么这可能会偏低。如果这是一个多用户安装，这将是偏高的（是的，仍然有一些地方托管实际用户，而不仅仅是他们的网络服务）。

• 当系统启动时，您将如何管理 /tmp 空间？删除所有文件 > 特定年龄？不理会区域，直到达到最大值的百分比？

查看tmpwatch命令，我想您会发现它非常适合您问题的这一部分。该命令只是删除超过特定时间（以小时为单位）的任何文件。根据它填满的速度，你可以做 30 天、45 天、90 天等。

• 是否应实施任何程序项目来管理该领域？

我会推荐以下内容：

1. 所有文件都是暂时的，不能保证在重新启动后仍然有效。
2. 超过 %age 的陈旧文件将在当地时间每晚午夜通过运行 tmpwatch 命令的 cron 作业删除。

剩下的就看你的具体需求了。