☰

`ulimit -m` / RLIMIT_RSS 不起作用背後的歷史是什麼？

tag-icon • tag-icon linux memory virtual-memory ulimit
`ulimit -m` / RLIMIT_RSS 不起作用背後的歷史是什麼？

根據man setrlimit（這就是man ulimit我的指示），

RLIMIT_RSS

指定在進程駐留集（RAM 中駐留的虛擬頁數）的限制（以位元組為單位）。此限制僅在 Linux 2.4.x（x < 30）中有效，並且僅影響對指定 MADV_WILLNEED 的 madvise(2) 的呼叫。

所以看來ulimit(和setrlimit)只能限制行程使用的虛擬記憶體。另一方面，像這樣的答案這個斷言（看起來正確）虛擬記憶體是一個幾乎毫無意義的統計數據，尤其是在 Java 應用程式中，通常會要求比實際使用的虛擬記憶體多得多的虛擬記憶體。

因此，我想知道我可以對系統施加的限制與實際有意義的數字之間看似脫節的歷史。如果可以回答的話，為什麼會出現這樣的情況呢？

答案1

RSS 是實作細節。您的程式可以控制的唯一資源是 RLIMIT_AS 和 RLIMIT_DATA。 Unix 實作可以始終修復 RSS == VMA（提交所有請求的內存），並且只要電腦不夠強大，無法準備好浪費內存，所有 Java 虛擬機都會在加載時崩潰。

因此，對所引用線程的評論只是該人的意見，它們與 Unix 的體系結構不符。

要在 Linux 上嘗試此行為：

  1. 使用 mem=4G 參數啟動核心（或嘗試使用不同的值）
  2. sudo sysctl vm.overcommit_memory=2
  3. 執行 Chromium 或某些嘗試保留超過 4 GB 的程式（崩潰）

相關內容