![Linux - 为什么 kernel.shmall 默认情况下如此低?](https://linux22.com/image/1037/Linux%20-%20%E4%B8%BA%E4%BB%80%E4%B9%88%20kernel.shmall%20%E9%BB%98%E8%AE%A4%E6%83%85%E5%86%B5%E4%B8%8B%E5%A6%82%E6%AD%A4%E4%BD%8E%EF%BC%9F.png)
我在 Linux 上运行 DB2,必须将机器上的绝大多数内存分配给共享内存段。
此页面是我发现的有关 shmall/shmmax 的典型信息: http://www.pythian.com/news/245/the-mysterious-world-of-shmmax-and-shmall/
我的系统现在运行良好,但我想知道默认情况下共享内存如此之低是否有历史或哲学原因。换句话说,为什么不让shmall默认为机器上的最大物理内存呢?
或者换句话说,如果应用程序碰巧使用了大量共享内存,并且必须进入并更改这些设置,为什么典型的管理员需要“保护自己免受自己的侵害”?我唯一能想到的是,它确实让我设置了 DB2 可以使用的内存量的上限,但这是一种特殊情况。
答案1
共享内存并不总是受保护的资源。因此许多用户可以分配共享内存。当分配它的进程终止时,它也不会自动返回到内存池。这可能会导致共享内存分配已分配但未使用。这会导致可能不明显的内存泄漏。
通过保持较低的共享内存限制,大多数使用共享内存(少量)的进程都可以运行。然而,潜在的损害是有限的。我使用的唯一需要大量共享内存的系统是数据库服务器。这些通常由了解要求的系统管理员进行管理。如果没有,DBA 通常会了解需求并可以要求进行适当的配置更改。数据库安装说明通常指定如何计算和设置适当的限制。
我曾经遇到过数据库死机并留下大量已分配但未使用的共享内存的情况。这给系统用户带来了问题,并阻止重新启动数据库。幸运的是,有一些工具可以定位和释放内存。