系统备份和恢复
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
