当我向 /dev/shm 写入过多内容时，交换文件会自动进行

Question

今天的文本分析编程。我的程序将向 /dev/shm 写入大约 4500 万个小临时文件，它们的大小估计为 177.0 GB。我将在处理的下一步后立即删除它们。所以问题是我的主机上有 128GB 的​​物理内存，我没有足够的物理内存。

好的，问题：当我写入 /dev/shm 时，我的交换是否会自动启动，因为我有 239GB 的总交换加上 128GB 的​​ RAM，所以如果是这样，那就足够了。

第二个问题：我目前有 100G 分配给 /dev/shm。我是否需要提前将我的 /dev/shm 过度分配（超出物理 RAM）到 177G（或者更确切地说是 190G 以确保安全）？或者我不需要提前将我的 /dev/shm 大小设置为 190G，因为交换会自动处理我当前分配的超过 100G 的使用量？

顺便说一下，我的 inode 已经是 6000 万，这足以满足我 4500 万的估计需求。这很好。另外顺便说一句，我发现 linux ext4 在磁盘上有大约 1050 万个文件时出现故障，可重复但不确定。这似乎是一个超时问题，因为设计的东西在 python 文件写入的预期中进行得非常缓慢，可能是用于文件系统 inode 表插入的线性时间复杂度算法，这对于 python 文件写入基础设施来说太长了创建更多文件，尽管名义上有 20 亿个文件计数限制。SSD 和旋转磁盘在这里的行为相同，没有区别。inode 很好，可用空间也很好，只是由于超时破坏系统，在真正的文件系统上总是出现 OSErrors（这就是我要去 /dev/shm 的原因）。

这位主持人：

$ uname -a
Linux ga-HP-Z820 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64
ga@ga-HP-Z820:/mnt/fastssd/bot_subreddit_recom/tmp$ df -i /dev/shm
Filesystem       Inodes IUsed    IFree IUse% Mounted on
tmpfs          60000000     1 59999999    1% /dev/shm
ga@ga-HP-Z820:/mnt/fastssd/bot_subreddit_recom/tmp$ df -BG /dev/shm
Filesystem     1G-blocks  Used Available Use% Mounted on
tmpfs               100G    0G      100G   0% /dev/shm
ga@ga-HP-Z820:/mnt/fastssd/bot_subreddit_recom/tmp$ 

附加信息：

它在这里说

如果您的 tmpfs 实例过大，机器将死锁，因为 OOM 处理程序将无法释放该内存

. 所以我想我不会那样做！！！https://www.cyberciti.biz/files/linux-kernel/Documentation/filesystems/tmpfs.txt

因此我的决定是进行一个实验来找出：让交换来处理事情。现在就按原样运行它。让我的文件超过 /devshm 的分配大小，让交换完成剩下的工作。

Answer 1

我只是继续看会发生什么，当你向 /dev/shm 写入太多文件时。

OSError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/fastssd/bot_subreddit_recom/write_user_docs.py", line 85, in <module>
    f.write(subreddits)
OSError: [Errno 28] No space left on device
inFile: RC_2018-01-02
outDir: tmp
outputToScreenOnly: 0
OSError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/fastssd/bot_subreddit_recom/write_user_docs.py", line 85, in <module>
    f.write(subreddits)
OSError: [Errno 28] No space left on device

输入文件 33 天后，它“空间不足”，如上所示。

>>> 36.*33/12
99.0

因此，估计 99GB（非常接近 100GB）的文件是“没有剩余空间”错误发生的地方。这正是我设置为 100G 的 /dev/shm 设备的大小。这意味着交换在需要时无法真正使用。这表明，不幸的是， /dev/shm 只是耗尽了，并且当出现短缺时，它不会让您开始使用交换作为虚拟内存来继续运行。所以现在我们知道多亏了这个实验。您只需要真正的物理 RAM 即可让 /dev/shm 工作，而虚拟 RAM aka swap 对 /dev/shm 根本没有帮助。

我已经发布了这个答案，与可能从所获得的信息中受益的其他人分享。