我有 16G RAM 的機器。我運行帶有參數(shù)的 java 應(yīng)用程序-Xms9G -Xmx9G。當我運行top命令時，我看到我的 Java 進程占用了13.8g VIRT，但只有4.6g RES。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5019 root 20 0 13.8g 4.7g 18m S 0.7 30.7 3:28.39 java 在運行pmap命令時，我看到只有~3.9g的堆作為RES存在，其余5.7g 在 virtual 中。Address Kbytes RSS Dirty Mode Mapping0000000580000000 9452384 4074228 4074228 rw--- [ anon ]在使用 監(jiān)視HPCUR時，我觀察到當HPCUR 達到約 3gjvmtop時觸發(fā)了 GC 。PID MAIN-CLASS HPCUR HPMAX NHCUR NHMAX CPU GC VM USERNAME #T DL 5019 .1-SNAPSHOT.jar 408m 9216m 192m n/a 0.25% 0.00% O8U20 webapp 823我觀察到進程的 RES 逐漸增加，RES 中的堆內(nèi)存（通過 pmap）也逐漸增加。結(jié)果 GC 閾值增加。我對這種行為有幾個問題。是否只使用了 RES 中存在的堆，而不使用 VIRT？如果我分配了 9G min heap ( -Xms)，那么最初為什么只分配了 3.9g RES。這與保持低 -Xms 不一樣嗎？那么保留 -Xms=-Xmx 有什么意義呢？在什么基礎(chǔ)上決定RES中應(yīng)該有多少堆？在某處讀到它由操作系統(tǒng)管理，但有任何粗略的邏輯嗎？有什么方法可以確保實際使用分配的堆？
2 回答
函數(shù)式編程
TA貢獻1807條經(jīng)驗 獲得超9個贊
VIRT表示虛擬內(nèi)存 - 這是進程的整個保留地址空間。RSS是常駐集大小——在物理 RAM 中分配的虛擬地址空間部分。對于任何地址范圍（不僅是堆）RSS是 的子集VIRT，可能是完整的或空的。似乎您已經(jīng)探索過pmap- 對于每個虛擬地址范圍，它顯示了物理分配內(nèi)存 (RSS) 的確切數(shù)量。操作系統(tǒng)在第一次訪問時延遲分配物理頁面。這就是為什么在相應(yīng)的頁面被讀取或?qū)懭胫?，即使已提交的?nèi)存也不是 RSS 的一部分。堆的大部分不在 RSS 中這一事實意味著堆的這一部分從未被觸及過。另請參閱此問題。
有一個 JVM 選項
-XX:+AlwaysPreTouch可以強制接觸堆的每一頁，從而使其成為 RSS 的一部分。嘗試java -Xms9G -Xmx9G -XX:+AlwaysPreTouch。
桃花長相依
TA貢獻1860條經(jīng)驗 獲得超8個贊
是的 HEAP 是 RES（只要它適合主內(nèi)存）
This answer表明這
-Xms是對GC的提示，在什么時候需要進行完整的垃圾收集。使用我的本地 JVM 進行測試，我可以確認它不會立即保留內(nèi)存。您獲得的是您的 JVM 不會阻塞大量未使用的內(nèi)存，但會更快地達到您的下限，因為 GC 運行較少。1 的回答：RES 總是包含所有的 HEAP
我的理解是您的選擇將實現(xiàn)您的意圖。您的應(yīng)用程序?qū)⒄加?9GB 內(nèi)存，然后更頻繁地啟動垃圾收集。如果您需要更多優(yōu)化，還有其他選項，例如
MinHeapFreeRatio和 取決于所使用的垃圾收集器的選項。
您是否打印了 GC 日志并驗證是否有問題？如果您看到在達到 9G 之前應(yīng)用程序啟動時運行了很多 GC，我會進一步查看。如果在達到 9G 之前幾乎沒有運行任何 GC，我會說一切都很好。
添加回答
舉報
0/150
提交
取消