Linux
Linux - 為什麼預設情況下 kernel.shmall 這麼低？
我在 Linux 上執行 DB2，我必須將機器上的絕大多數記憶體分配給共享記憶體段。
此頁面是我發現的有關 shmall/shmmax 的典型資訊：http: //www.pythian.com/news/245/the-mysterious-world-of-shmmax-and-shmall/
我的系統現在執行良好，但我想知道預設情況下共享記憶體如此低是否有歷史或哲學原因。換句話說，為什麼不讓 shmall 預設為機器上的最大物理記憶體呢？
或者換句話說，如果一個應用碰巧使用了大量共享記憶體，並且必須進入並更改這些設置，為什麼典型的管理員需要“保護自己”？我唯一能想到的是，它確實讓我設置了 DB2 可以使用多少記憶體的上限，但這是一種特殊情況。
共享記憶體並不總是受保護的資源。因此，許多使用者可以分配共享記憶體。當分配它的程序死亡時，它也不會自動返回到記憶體池。這可能導致已分配但未使用的共享記憶體分配。這會導致可能不明顯的記憶體洩漏。
通過保持較低的共享記憶體限制，大多數使用共享記憶體（少量）的程序都可以執行。但是，潛在的損害是有限的。我使用的唯一需要大量共享記憶體的系統是數據庫伺服器。這些通常由了解要求的系統管理員管理。如果沒有，DBA 通常會知道需求並可以要求進行適當的配置更改。數據庫安裝說明通常指定如何計算和設置適當的限制。
我已經讓數據庫死掉並留下大量分配的共享記憶體，但未使用。這給系統使用者帶來了問題，並阻止了重新啟動數據庫。幸運的是，那裡有允許定位和釋放記憶體的工具。