升級到2.2.x後的一天內OutofMemory

Question

我們使用2.1.7，並偶爾在我們的客戶端應用程序和OrientDB服務器中獲得OutOfMemory（類型爲每兩個月一次）。所以我們 最近將OrientDB從2.1.7升級到2.2.11。升級之後，Im在查詢OrientDB數據的客戶端應用程序中在一天內獲得OutOfMemory。

在堆轉儲，還有OSBTreeCollectionManagerRemote和OStorageRemoteAsynchEventListener 實例和它對應於總存儲器的95％。

Memory problem suspects screenshot

作爲升級的一部分，Java是也升級爲8

客戶端（Tomcat）的JVM PARAMS：

-Xmx2048m -XX:MaxPermSize=512m -XX:MaxDirectMemorySize=2048m -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:+CMSClassUnloadingEnabled 

我試圖與不圖連接池，結果是相同的。

任何人都可以提供有關如何解決此問題的更多信息。如果有人感興趣，我可以分享heapdump。

Answer 1

您使用吞吐收集器（ParallelGC），你還使ParallelOld，所以-XX:+CMSClassUnloadingEnabled未使用（因爲這是與ConcurrentMarkSweep集熱器所使用的標誌，從永久/元空間中運行時，卸載類一個簡單的CMS階段，而不是等待一個不需要的FullGC）

請描述你的客戶端機器，哪個OS，多少免費ram，多少個cpu/core，多少個java進程在客戶機上運行？記住java不應該被換出。

而不是收集巨大和靜態堆轉儲的列表，請使用PrintGC選項跟蹤收集器的動態行爲，如果懷疑存在泄漏，請檢查使用jmap打印ascii直方圖的實例的數量增加 - histo：live（在收集直方圖之前執行FullGC）

ParallelGC在Full Generation中使用Full GC，因此這是預期的行爲。

你會得到哪個OutOfMemory？它是在堆中還是永久的還是直接的？由於你的旗幟，我想堆在一起。

嘗試瞭解哪個段已滿並將其增加至您的清潔機器的極限;爲了生成過程號和時間戳的gc.log，使用方法：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:$CATALINA_HOME/logs/gclog_%p_%t.log

您還可以添加-XX:+PrintTenuringDistribution, to see if promotion is done too early, when age of objects is too low. It could be that new size is too small, so should use a bigger new generation with -Xmn

您可以瞭解使用也-XX:+PrintFlagsFinal每個XX標誌的當前值。另請參見http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html

啓動Java 8u102與當前一代的大小，並且提高它們在需要的地方：

-Xms2048m -Xmn768m -Xmx2048m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=2048m -XX:+UseParallelOldGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -Xloggc:$CATALINA_HOME/logs/gclog_%p_%t.log <br><br> 
<br> 
For java 7, instead of Metaspace use Permanent: -XX:PermSize=512m -XX:MaxPermSize=512m 

提供所有有關客戶機和gclog的信息，如果你需要一個反饋。

如果你自己做，從gclog一些調整，並且增加幾十倍的內存段這似乎是太小了，但你繼續得到同樣的內存不足，則有可能是您的應用程序內存泄漏，因爲ParallelGC適用於FullGC（所以應該清除所有發佈的對象/類/字符串）