系統備份和恢復
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