shmpages内核和内存术语的宏伟计划究竟是什么。如果我达到了shmpages极限，那意味着什么？
我也很好奇这是否不仅适用于 linux
我在 /dev/shm 中重复数以万计的类似操作，每个操作都会创建一个目录、写入文件，然后删除。我曾经的假设是我实际上是在创建目录并将它们删除到位，因此内存消耗必须非常低。然而事实证明使用率相当高，最终导致内存溢出。所以我的问题是：像这样的操作
mkdir /dev/shm/foo
touch /dev/shm/foo/bar
[edit] /dev/shm/foo/bar
....
rm -rf /dev/shm/foo
它最终会导致内存溢出吗？如果是这样，为什么会这样，因为它似乎正在就地删除它们。
注意：这是一个数以万计的类似操作。
我在 Linux 上运行 DB2，我必须将机器上的绝大多数内存分配给共享内存段。
这个页面是我发现的关于 shmall/shmmax 的典型信息：http ://www.pythian.com/news/245/the-mysterious-world-of-shmmax-and-shmall/
我的系统现在运行良好，但我想知道默认情况下共享内存如此之低是否存在历史或哲学原因。换句话说，为什么不让 shmall 默认为机器上的最大物理内存？
或者换句话说，如果一个应用程序碰巧使用了大量共享内存，并且必须进入并更改这些设置，那么为什么典型的管理员需要“保护自己”？我唯一能想到的是它确实让我设置了 DB2 可以使用多少内存的上限，但这是一个特例。
我有一个 linux 盒子，专门用来播放 Oracle 服务器安装的主机。它有 4Gb RAM，默认情况下，50% (2Gb) 已分配给 /dev/shm。我想将其更改为 3Gb，但我无法这样做。
我试过了：
将 /etc/fstab 的相关行更改为：
tmpfs /dev/shm tmpfs size=3g 0 0
尝试使用临时调整大小 mount
无论出于何种原因，它似乎都没有调整大小。即使在重新启动后（以影响 /etc/fstab 更改） df -h 仍将 /dev/shm 显示为 2Gb。
难道我做错了什么？
根据RHEL 文档，系统上可用的共享内存总量等于shmall*PAGE_SIZE。
我完成RHEL 6的安装后，shmall内核参数的值默认为4294967296\xef\xbc\x8c，这意味着系统范围内可以使用的共享内存页面总数为4294967296，页面大小为4096 B. 因此，根据公式，共享内存的大小为
4294967296*4096/1024/1024/1024/1024 = 16 TB\n...这远远大于操作系统的 RAM (8 GB) 大小。操作系统如何找到 16 TB 的共享内存来分配？
\n那么， 的大小是否/dev/shm等于共享内存的大小呢？如果不是，我怎样才能得到共享内存的实际大小？
我需要知道两个进程之间共享的内存量，即它们共享内存的交集。
有任何想法吗？
我需要/dev/shm在嵌入式 ARM 系统上创建。来自“已安装最新更改到当前和...... ”。
我看到它可以用 来创建mkdir /lib/udev/devices/shm，但我想知道那个位置应该是什么？我在那个位置唯一的目录是/lib/modules/，没有devices/或任何东西。
所以我继续创建它们，空目录。我接着补充说：
tmpfs /dev/shm tmpfs defaults 0 0
我/etc/fstab和我没有添加一个mtab条目，因为我没有一个/etc/mtab。然后我重新启动，现在，仍然没有/dev/shm设备。
任何想法我如何获得该设备？
哦，mount -a（重新启动后）导致：
# mount -a
mount: mounting tmpfs on /dev/shm failed: No such file or directory`
今天的文本分析编程。我的程序将向 /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 …如果文件描述符特定于每个进程（即两个进程可能使用相同的文件描述符 id 来引用不同的打开文件），那么如何通过套接字等共享传输文件描述符（例如共享 mmap）？
它是否依赖于内核被映射到每个进程下的相同数字地址范围？