遷移到64位JVM的經驗

我們公司正計劃遷移到64位JVM，以擺脫2 GB最大堆大小限制。谷歌給了我很多有關64位JVM性能的結果。有沒有人嘗試遷移到64位Java和分享您的經驗遷移到64位JVM的經驗

2010-03-31 Fazal

x64或非x64？大多數情況下，它只會增加內存使用量並因此增加內存帶寬。對於x86來說，AMD創造的指令集比x86要少。 – 2010-03-31 14:55:55

@安德斯，不是每個人都像你一樣癡迷於這些數字！：P有些人（你能想象嗎？）答案只是爲了幫助。 – 2010-03-31 14:58:29

@Vladimir Dyuzhev：癡迷不是問題。這是社區工作的方式。回答和接受是如何確定誰有良好答案的歷史。沒有接受意味着沒有好的答案的歷史。沒有良好答案的歷史，很難知道有多少信任投入答案。 – 2010-03-31 15:05:19

如果您需要更大的堆，那麼性能的問題是相當實際意義，不是嗎？或者你有計劃進行水平縮放嗎？

，我已經與64位應用程序聽到的主要問題是，一個完整的垃圾收集可能需要很長的時間（因爲它是基於活動對象的數量）。所以你要仔細調整GC參數以避免完整的收集（我聽說過一個有64 Gb堆的公司的軼事，並調整了他們的GC，以便他們永遠不會完整的GC;他們只會關閉每週下降一次）。

除此之外，認識到Java是32位設計，所以你可能不會看到在同一時間將數據移動64位的任何巨大的性能提升。而你仍然只限於32位數組索引。

來源

2010-03-31 14:56:01 Anon

我們有一個JVM，其中並行運行的gc運行良好，但如果在下一個gc要啓動時未完成gc，則JVM會暫停，直到完成第二個gc。壞！由於操作系統非常積極地將內存交換出去，因此會稍微有些變化。 – 2010-03-31 18:42:08

你能解釋一下你的意思是Java是32位的設計嗎？據我所知，Java是獨立於設計平臺的平臺？ – Pacerier 2011-11-24 04:49:03

關於32位設計的評論很奇怪。當我們討論32/64/128位時，它通常與指針的大小有關，這會影響工作內存的大小。 Java使用數組ints來限制單個數組的大小，但像nio緩衝區這樣的抽象可以用來有效解決這個問題。由於這並不完美，因此有計劃允許指數多頭。但是，這不是像4Gb的最大堆那樣的技術方面的限制。 – 2012-10-15 07:38:16

我們直接寫入64位，我看不出有任何的不良行爲......

來源

2010-03-31 14:40:58 Yaneeve

工作正常的我們。你爲什麼不簡單地嘗試設置它，並在像jvisualvm這樣的profiler下運行你的負載測試套件？

來源

2010-03-31 14:44:53

一言以蔽之： 64位JVM會消耗對象引用和一些其他類型的內存（一般不顯著），消耗每個線程（通常在高容量網站顯著）更多的內存，使您能夠有較大的堆（一般只如果你有很多長壽的對象很重要）

更長的答案/評論：

的評論說，Java是32位乘設計是一種誤導。 Java 存儲器尋址是64位的32或者，但VM規範確保大多數字段（例如int，long，double，等）都是相同的，無論如何。
而且 - GC的調整意見，同時相關的對象的數量，可能是不相關的，GC可以快速上 JVM上有大堆（我工作與堆高達15GB，非常快速GC） - 它更多地取決於你如何與代收集計劃玩的，你的對象使用模式。雖然在過去人已經花了很多精力調整參數，這是非常工作量依賴，而現代（在Java 5+）的JVM 是在自我調整非常好 - 除非你有大量的數據你更可能會損害你自己，而不是幫助進行攻擊性JVM調優。
由於在x86架構上提到， 64位EMT64或x64處理器還包括像原子寫入做的事情，或者其他選項也可能影響高性能應用的新指令。

來源

2010-03-31 23:32:05 jayshao

你能解釋一下「字段（例如int，long，double等）是什麼意思嗎？ – Pacerier 2011-11-24 04:50:24

天真地採取32位JVM工作負載並把它們放在64位產生一個性能和空間打擊我的經驗。但是，大多數主要的JVM供應商現在已經實現了一種基本上壓縮一些堆的良好技術 - 它被稱爲壓縮引用或壓縮oops，用於不是「大」的64位JVM（即：在4 -30gb範圍）。

這產生了很大的差異，應該使32-> 64的轉換影響更小。

參考IBM JVM：link text

來源

2010-04-14 21:45:17

我認爲這是-XX：+ UseCompressedOops for oracle jvm – Karussell 2011-02-21 19:46:18

遷移到64位JVM的經驗

回答

相關問題