我們的生產環境在每臺Windows 2003服務器上運行3個32位Java 6 JVM。每個堆都處於最大設置(〜1.25GB)。我們正在考慮遷移到新服務器並使用64位JVM。據推測,我們可以在每臺服務器上安裝一個64位JVM,以替代每臺服務器上的3個32位JVM,因爲在使用64位JVM時允許有更大的堆大小。32位與64位JVM性能考慮事項?
任何人都這樣做,並有任何經驗教訓?
我特別關注任何性能方面的考慮以及如何應對。
我們的生產環境在每臺Windows 2003服務器上運行3個32位Java 6 JVM。每個堆都處於最大設置(〜1.25GB)。我們正在考慮遷移到新服務器並使用64位JVM。據推測,我們可以在每臺服務器上安裝一個64位JVM,以替代每臺服務器上的3個32位JVM,因爲在使用64位JVM時允許有更大的堆大小。32位與64位JVM性能考慮事項?
任何人都這樣做,並有任何經驗教訓?
我特別關注任何性能方面的考慮以及如何應對。
由於在64位體系結構上尋址對象的代價更高,因此內存需求將會增加。實際上取決於您的應用程序有多少。假設你沒有散列4GB的整數,猜測結果爲10%-20%...
你也可能在鎖定記錄器,線程池,連接池,單例等的鎖爭用時遇到問題。如果您的應用程序是以數據庫爲中心的,那麼這可能不是問題,但是如果您的應用程序在地圖中存儲了很多會話,並且訪問了很多地圖,則可能會出現問題。根據我的經驗,「牆」的爭論可能會很快。
但是,只有一種方法可以知道:...測試它。
我沒有這樣做,但只要您不依賴任何沒有64位版本的32位JNI代碼,這應該是完全正常的。如果你所使用的只是純Java,那應該沒有問題。
+1,試試看看。此外,從Java 6 update 14開始,可以使用「-XX:+ UseCompressedOops」爲堆大小<32GB啓用壓縮對象指針,該指針應該消除由於64位對象指針造成的輕微內存增加,同時爲您提供了64位JVM。 – 2010-03-20 17:31:49