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