☰

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

tag-icon • tag-icon linux swap shared-memory
当我向 /dev/shm 写入过多内容时，交换文件会自动参与

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

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

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

顺便说一句，我的索引节点已经有 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$

附加信息：

IT 在这里说

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

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

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

答案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 又名交换对 /dev/shm 根本没有帮助。

我发布此答案是为了与可能从所获得的信息中受益的其他人分享。

相关内容