系统备份和恢复 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 平台上有严重的内存问题。

如果你在使用的时候遇到了比较严重的内存泄漏问题，请登录 。我们的内存属性空间选择的是 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 的垃圾清理消耗最小的时间呢？请参考 页面中的内容来确定 JVM 垃圾清理对正在运行的系统产生最小的影响。