![基于小型 RAM 的 /tmp](https://linux22.com/image/50681/%E5%9F%BA%E4%BA%8E%E5%B0%8F%E5%9E%8B%20RAM%20%E7%9A%84%20%2Ftmp.png)
我的 VPS 主机的配置 Web 界面为我提供了一个下拉框来设置我的/tmp
.
默认为“16MB RAM”,替代选项为“硬盘”。
只有 16MB 的/tmp
可用空间是否可能会给某些软件带来麻烦?或不?
答案1
只有 16MB 可用的 /tmp 是否可能会给某些软件带来麻烦?
是的,如果某个软件想要写入/tmp
并且它或其他软件已经填充了分区。一般来说,这可能表明系统配置不佳、对可用资源的合法限制,或者其他软件的行为不当——无论如何,想要编写的软件不太可能尝试自行找到解决方案并会抛出错误。
有些软件会假设它可以将大文件写入/tmp
,公平地说,这是一个公平的假设。这个问题属于“配置不当”的错误范畴。
您应该问自己的第一个问题是:“使用 RAM 对我来说有什么好处/tmp
?”最明显的是潜在的好处是访问 RAM 比访问磁盘快得多。然而,这种明显的潜在好处在现实中不太可能有那么大的好处,因为:
无论如何,系统都会将经常访问的文件缓存在 RAM 中。减少可用于此缓存的 RAM 量以便将
/tmp
其放入其中有点愚蠢,因为这意味着不常用的文件/tmp
将取代缓存中的常用文件。应用程序已经可以自由地将内容存储在 RAM 中,这通常比将它们存储在文件中更容易,因此如果它们将某些内容放入 tmp 文件中,则不太可能会从 RAM 中受益。如果您查看 中的实际内容
/tmp
,可能主要是套接字和 fifo 或少量 IPC 数据。通过基于 RAM 的文件系统访问它们在概念上更简洁,但我怀疑这会产生任何真正的区别。
既然如此,为什么还要/tmp
在RAM中实现呢?
它简化了 的首选属性的实现
/tmp
,即它在关闭时被擦除。它可能会稍微减少硬件的磨损。这在仅具有廉价的、有限寿命的闪存用于存储或根本没有可写存储(例如嵌入式系统)的环境中更为重要。
假设
/tmp
没有被滥用,使用 RAM 会利用现代硬件通常巨大的内存容量——也就是说,这些东西也可能在 RAM 中,假设它是它应该是的那种东西。
16MB可以已经足够了,但如果某个进程失控,也还不算什么——而且/tmp
必须是任何人都可写的。然而,如果某个进程在向 写入内容时出现混乱/tmp
,如果它最终填满硬盘,或者因为耗尽了 RAM 分区而更快地发出红旗,会更好吗?
如果你对你正在使用的软件有信心,后者更有意义,所以你可以选择 RAM 分区。您应该首先检查一下您的实际/tmp
使用情况,以防发生任何异常情况(例如du -h /tmp
)。您可以提出一个“正常阈值”,并使用 cron 作业检查该阈值,以在超出阈值时向某人发出警报和/或进行一些紧急清理。
不幸的是,某些应用程序可能偶尔会转储一些内容,/tmp
如果突然失败,这些内容不会被删除,而在服务器上(不会经常关闭),这些内容可能会无限期地留在那里。我认为,这种情况的发生可能是非常无害的,例如,当有人登录并使用某些东西时,连接就会被任意关闭或放弃。
所以非RAM/tmp
更安全。滥用行为可能会在更长时间内不被注意到,但这只是因为它不像 RAM 那样严重。此外,如果某些事情确实引起了问题,磁盘上就会留下确凿的证据,指出问题的根源。