twb*_*mer 5 linux security memory limit shared-memory
我在 Linux 上运行 DB2，我必须将机器上的绝大多数内存分配给共享内存段。
这个页面是我发现的关于 shmall/shmmax 的典型信息：http ://www.pythian.com/news/245/the-mysterious-world-of-shmmax-and-shmall/
我的系统现在运行良好，但我想知道默认情况下共享内存如此之低是否存在历史或哲学原因。换句话说，为什么不让 shmall 默认为机器上的最大物理内存？
或者换句话说，如果一个应用程序碰巧使用了大量共享内存，并且必须进入并更改这些设置，那么为什么典型的管理员需要“保护自己”？我唯一能想到的是它确实让我设置了 DB2 可以使用多少内存的上限，但这是一个特例。
共享内存并不总是受保护的资源。因此许多用户可以分配共享内存。当分配它的进程终止时，它也不会自动返回到内存池。这可能会导致共享内存分配已分配但未使用。这会导致可能不明显的内存泄漏。
通过保持较低的共享内存限制，大多数使用共享内存（少量）的进程都可以运行。然而，潜在的损害是有限的。我使用的唯一需要大量共享内存的系统是数据库服务器。这些通常由了解要求的系统管理员进行管理。如果没有，DBA 通常会了解需求并可以要求进行适当的配置更改。数据库安装说明通常指定如何计算和设置适当的限制。
我曾经遇到过数据库死机并留下大量已分配但未使用的共享内存的情况。这给系统用户带来了问题，并阻止重新启动数据库。幸运的是，有一些工具可以定位和释放内存。