我有一些脚本需要快速创建许多小的临时文件,并很快将其读取后解除链接。
我的测试显示,在Linux下,即使在中等负载下,将这些文件放在/tmp
(磁盘)或/dev/shm
(文件系统级共享内存)中,也几乎没有性能差异。我将其归因于文件系统缓存。
尽管最终磁盘将受到文件系统操作的影响,但对于多个小的写入-读取临时文件,您为什么(不)推荐使用基于共享内存的目录/dev/shm
而非基于磁盘的目录?您是否注意到共享内存目录相对于缓存的VFS存在大幅度的性能提升?
我有一些脚本需要快速创建许多小的临时文件,并很快将其读取后解除链接。
我的测试显示,在Linux下,即使在中等负载下,将这些文件放在/tmp
(磁盘)或/dev/shm
(文件系统级共享内存)中,也几乎没有性能差异。我将其归因于文件系统缓存。
尽管最终磁盘将受到文件系统操作的影响,但对于多个小的写入-读取临时文件,您为什么(不)推荐使用基于共享内存的目录/dev/shm
而非基于磁盘的目录?您是否注意到共享内存目录相对于缓存的VFS存在大幅度的性能提升?
/dev/shm
旨在用于非任意程序放置文件的特殊目的。
相比之下,/tmp
则正是为此而设计的。 在我的系统上,/tmp
也是一个tmpfs
,与/var/tmp
不同,后者是专门为放置较大文件并可能保留更长时间的文件。
本质上来说,它们是相同的(当你有swapfile时,shm也会被硬盘隐式支持)。
/tmp具有以下优点:它更难填满(因为你的硬盘很可能比swapfile大),而且它得到了更广泛的支持。
/dev/shm
是 Linux 的一个实现细节,而不是任何形式的保证(可用空间通常非常有限)。请使用/tmp
和/var/tmp
以其预期用途。根据使用情况和文件系统,如果您创建并取消链接文件,则可能仅在缓存中而永远不会命中磁盘。 - ephemienttmpfs
支持,而是由主要的sda1磁盘支持。否则,我同意保持标准,但这是我们当前的部署环境。 - Jé Queueshm_open(3)
,您可以请求创建一个特殊的“共享内存”对象。一些实现(或者说是Linux系统?)使用/dev/shm
来放置所创建的对象。 - glglgl