2014-06-29 28 views
2

我正在運行內存密集型應用程序。關於環境的一些信息:JVM將不會使用盡可能多的內存,因爲我告訴它

  • 64位的debian
  • 13的RAM
  • GB
  • 64位JVM(I輸出System.getProperty( 「sun.arch.data.model」)我的程序運行時,它說, 「64」)

這裏是我發出的確切命令:

的java -Xmx9000m -jar 「ale.jar」 testconfig

我已經在其他幾個系統上使用相同的確切數據,配置等來運行該程序,並且我知道JVM在這些系統上使用(在其最高處)6 GB的內存。但是,我收到OutOfMemory錯誤。此外,在程序執行過程中,系統永遠不會低於8.5 GB的可用內存。

當我在執行期間輸出調用Runtime.getRuntime()。maxMemory()時,得到的值3044540416,即〜3 GB。

我不知道它是否是相關的,但是這是一個谷歌Compute Engine的實例。

我能想到的唯一解釋是,有可能是某種制度約束的對單個進程可以使用的最大內存量。

+0

嘗試的Java -Xms9g -Xmx9g -jar [...],這爲我工作。 – kaetzacoatl

+1

你正在收到什麼完整的異常消息?什麼是堆棧跟蹤? –

+0

使用'-XX:+ PrintGCDetails'來查找實際的堆佈局。 – apangin

回答

1

-Xmx將只設置最大分配的內存。使用-Xms指定最小值。將它們設置爲相同的值將使內存佔用爲靜態。

1

我能想到的唯一解釋是可能會對某個進程可能使用的最大內存量存在某種系統限制。

這就是一個可能的解釋。

另一個是你正試圖分配一個非常大的數組。最大的可能陣列2^31 - 1元素,但實際大小取決於元件尺寸:

  • byte[]boolean[] ... 2G字節
  • char[]short[] ... 4G字節
  • int[] ... 8個千兆字節
  • long[]Object[] ... 16個千兆字節

如果您分配一個非常大的陣列,則GC需要找到所需大小的連續空閒內存區域。根據數組大小以及堆空間如何分割爲空格,它可能會找到比您想象的連續空間少得多的連續空間。

第三種可能性是,你得到OOMEs因爲GC是打時間的GC限制開銷花費運行GC。


一些理論可以證實或駁回,如果你向我們展示了堆棧跟蹤...

相關問題