Confluence 6 記憶體使用和需求和一些問題

系統備份和恢複

Confluence  的備份和恢複是與資料庫中資料量的大小有關。這個操作可能會對 Confluence 的性能産生很多關鍵性的影響并且大量消耗記憶體。如果你在 Confluence 的系統備份和恢複過程中遇到了 

OutOfMemoryError

 錯誤，我們強烈推薦你使用 

Production Backup Strategy

 進行系統的備份和恢複。

當你在 Confluence 系統備份和恢複的時候遇到了  

OutOfMemoryError

 錯誤，你希望通過增加記憶體的大小來修複這個錯誤的話。我們應該增加多少記憶體呢？一個指導方針是，檢視你備份中的 

entities.xml

 檔案的大小。這個檔案的大小是 Confluence 需要載入的所有資料的大小，同時這個大小也是最小的需求值。針對這個大小，添加 64 - 128MB 到 Confluence 的記憶體來保證 Confluence 在系統備份的時候有足夠可用的記憶體。有關增加可用記憶體的方法，請參考頁面 

increasing available memory

 中的内容。

我們不能控制的已知問題

下面的一些記憶體的問題，我們可能沒有辦法進行控制：

• 針對 Oracle 10g JDBC 驅動的記憶體洩漏。我們沒有太多可以做的地方。
• 一個使用者發現了在 Tomcat 5 的版本上，如果使用 IBM JDK，在 PowerPC 平台上有嚴重的記憶體問題。

如果你在使用的時候遇到了比較嚴重的記憶體洩漏問題，請登入 

http://support.atlassian.com

。我們的記憶體屬性空間選擇的是 

YourKit

。這個工具能夠幫助你向我們提供你機器上存在有記憶體洩漏的地方。

Confluence 對一些操作的響應時間過長

一個導緻 Confluence 突然不響應的問題可能是 Confluence 正在運作 JVM 垃圾清理。為了确定這個是不是正在發生的情況，請詳細檢視垃圾清理程式然後檢查 Java 花了多長時間才清空記憶體。如果臨時停止響應的時候與 Java 運作垃圾清理的世界相同的話，那麼就可以證明是 Java 的垃圾清理導緻了這個問題。

詳細的垃圾清理日志将會告訴你 Java 的垃圾清理程式是什麼時候開始的，在這次垃圾清理中花了多長時間，和多少垃圾被清理。

為了确定垃圾清理 gc 被争取的日志，在啟動 Confluence 的時候，添加下面的選項 

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc -Xloggc:gc.log。替換

gc.log

 為你 

gc.log

 檔案的絕對路徑。

例如，如果你下 Windows 服務下的話，運作：

tomcat5 //US//Confluence ++JvmOptions="-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc -Xloggc:c:\confluence\logs\gc.log"      

或者在  

bin/setenv.sh

, 中設定：

export CATALINA_OPTS="$CATALINA_OPTS -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc -Xloggc:${CATALINA_BASE}/logs/gc.log"      

如果你修改了 

bin/setenv.sh 檔案，

你需要重新開機 Confluence 來使配置生效。

有什麼辦法可以讓 Java 的垃圾清理消耗最小的時間呢？請參考  

http://java.sun.com/docs/hotspot/gc1.4.2/

 頁面中的内容來确定 JVM 垃圾清理對正在運作的系統産生最小的影響。

https://www.cwiki.us/display/CONF6ZH/Memory+Usage+and+Requirements