使用tmpfs +一个非常大的/ tmp交换分区而不是常规文件系统？

我有Linux服务器，并且有一个备用500GB磁盘分区。我想格式化它并将其用于/ tmp。服务器偶尔会执行一些大型数据处理任务，因此/ tmp可能会保留GB的临时数据。

然后我有了一个主意，可以改为将其添加为交换分区，然后将/ tmp挂载到tmpfs。这个想法合理吗？

服务器具有6GB的RAM，因此在大多数情况下，/ tmp上的数据仅在RAM中，具有明显的速度优势。问题是，如果说/ tmp上有10-20GB的数据，系统将如何执行？与仅将/ tmp挂载到ext4分区相比，性能如何？感谢帮助。

编辑：很明显，当tmpfs的使用达到RAM限制时，系统将开始换出内存。但是Linux是否足够聪明，可以交换tmpfs数据并将“常规”数据保留在RAM中？如果是，那么我认为它的行为可能合理。否则，整个系统将受到严重影响。

这不是一个好主意^TM。

您可以使用这样大的/tmp分区安装好（从您的/etc/fstab）

tmpfs  /dev/tmp  tmpfs  defaults,nosuid,nodev,noexec,noatime,nodiratime,size=6000M 0 0

您可以将外部驱动器添加为巨型交换分区

/dev/sdb1  swap  swap  defaults  0 0

当达到极限时，您的计算机将开始将页面从RAM交换到磁盘-此时，平均负载将通过屋顶，并且计算机将停止运行。

无论如何都要依靠SWAP是一个坏主意，最好出售500GB的驱动器，而只是购买更多的RAM- 价格便宜。

综上所述

如果您确实要使用500GB磁盘，则可以将500GB磁盘安装在/tmp禁用了atime和diratime的非日志文件系统上（例如ext2）。这将是显着快于处理的是一台SWAP荷兰国际集团

这可能是一个合理的想法。

将实际的文件系统放在/ tmp上确实会产生开销，因为文件系统会花费很长的时间来确保在系统故障的情况下不会损坏磁盘上的数据。对于在启动时清除的/ tmp来说，这显然只是开销。使用tmpfs可以避免这种开销。

另一方面，文件系统还确保以优化访问时间的方式在磁盘上组织文件-即，它们将避免碎片。典型的顺序文件访问将（大部分）导致顺序磁盘访问，这比随机访问更有效。在旋转的硬盘上，这种效果比在SSD上更为明显。swap + tmpfs组合不能轻易做到这一点，因为swap不知道哪个内存属于哪个文件，tmpfs不知道页面如何映射到物理内存或磁盘。但是，对于大文件，它应该运行良好，因为在这种情况下，tmpfs和swap都尝试保持连续。至少，只要交换时有很多可用空间（否则碎片就会涌入），并且写入发生的速度很慢，以至于有机会被交换出去。

因此，底线是：这取决于您应该尝试两种选择，以查看哪种方法最有效。

挂载tmpfs时，切记要明确设置大小。默认值为物理RAM的一半，因此只有3GB。

如果您通常没有太多数据/tmp，但偶尔会在有限的时间段内消耗无穷的千兆字节，这实际上是一个好主意。问题是Linux交换系统对用例的了解不足，无法正确执行。通常，它会优先于程序页面优先转储或交换缓存，但这并没有真正的帮助。也许可以使用cgroups实现目标，这是在暂存数据保存在程序存储器中时，但是我不确定在这种情况下如何配置cgroups（我想您可以使用FUSE tmpfs ...） 。幸运的是，这不是必需的。您可以使用zram和后备设备获得所需的行为。

zram-init是自动设置zram（压缩的ram块设备）的程序。在zram-init配置中通常有一个示例以/tmpzram 挂载。就像下面这样

type0=/tmp
flag0= 
size0=524288 # 500G of logical space
mlim0=2G # 2G of memory
back0=/dev/loop0 # (or /dev/sdxN, your large slow drive)
notr0= 
maxs0=4 # maximum number of parallel processes for this device
algo0=zstd 
labl0=tmp # the label name
uuid0= 
args0= 

这将压缩任何写入/ tmp的内容并将其存储在内存中。通常压缩约为50％。它将最多消耗2G的物理内存。如果它的物理内存不足，它将获取最早的文件并将其推入仍处于压缩状态的后备设备中。请注意，压缩和解压缩确实会导致一些CPU开销，但这通常会因IO减少而抵消。

可以将类似的设置与cgroup结合使用，以使某些进程交换而不会对整体系统性能产生不利影响。