你不能通过 Confluence UI 修改 Synchrony 的配置。配置的修改是通过系统属性进行修改的。在绝大部分情况下，你不需要对默认的配置进行修改。  修改 Synchrony 运行的端口... 在默认情况下 Synchrony 运行在 8091 端口。如果这个端口在你的系统中已经被其他应用占用了，你可使用 synchrony.port 系统属性来将端口修改到其他可用的端口上。 如果你使用的是 Confluence 6.0.3 及其早期的版本，你需要使用 reza.port 来替代 synchrony.port。 请可参考 Configuring System Properties 页面中的内容来获得如何进行修改的帮助。 针对 Confluence 数据库中，运行 Synchrony 的方式有些不同。请参考 Configuring Synchrony for Data Center 页面中的内容来获得更多信息。  修改 Synchrony 的最大 heap 值 在默认情况下 Synchrony 的最大 heap 大小被设置为 1 GB。 如果你遇到了与 Synchrony 有关的内存溢出的错误，你可以通过修改 synchrony.memory.max 属性来确定 Synchrony 使用的内存大小。 如果你使用的是 Confluence 6.0.3 及其早期的版本，你需要使用 reza.memory.max 来替代 synchrony.memory.max。 请可参考 Configuring System Properties 页面中的内容来获得如何进行修改的帮助。 针对 Confluence 数据库中，运行 Synchrony 的方式有些不同。请参考 Configuring Synchrony for Data Center 页面中的内容来获得更多信息。 请参考 Recognized System Properties 页面中的内容来获得所有有关 Synchrony 的系统属性。 如果你需要针对 Synchrony 虚拟机传递其他的参数，创建一个名为 synchrony-args.properties 的属性文件。这个文件位于 Confluence 的 home 目录中，然后在这个文件中输入你希望传递进去的参数，每行一个参数。 property1=value1 property2=value2 这个将会添加 -Dproperty1=value1 -Dproperty2=value2  到 Synchrony 命令行中。这个功能只能在 Confluence 6.0.2 及其后续版本中有效。 你不能使用这个方法传递在系统数据中已经有的值，例如端口， Xmx 或 Xss 等。请参考 Configuring System Properties 页面中的内容来获得所有的属性列表。   https://www.cwiki.us/display/CONF6ZH/Administering+Collaborative+Editing

我们知道一些客户对审计是主要考虑的方面。我们不能保证在协同编辑的时候具有审计，审查功能。所有页面的修改当前附加到用户发布页面的属性中而不是用户的特定修改。 如果这个对你来说是一个问题的话，我们建议你在你的站点中关闭协同编辑。 在未发布的草稿中没有版本历史 我们现在保存了在系统编辑中的所有时间的编辑，但是我们不会保存没有发布修改的的版本。当你恢复到早期页面的版本的时候，你仅仅可以恢复到一个已经存在的发布版本中。当你恢复到前一个版本的时候，所有未发布的的修改都会丢失。 匿名用修改的内容是否可见 当你为匿名用户赋予 添加（Add ）页面权限的时候有其他的一些事情你需要注意（和全局权限的 可以使用（Can use））。 当一个为发布页面是由匿名用户创建的时候，关闭一个编辑或者发布一个页面的时候你不会收到警告。这个可能会导致登录的用户的编辑会被中断和打扰。 他们自己的修改是可以在页面中可见，但是通常警告对话框将不会出现，如果是没有登录用户做的修改的话。 针对登录的用户和匿名用户都有未发布的修改，这个对话框将会显示，但是仅仅是登录的用户才能看到对话框。所有用户的修改（包括匿名用户）将会被包括进来，当你从对话框中查看修改的内容进行查看的话。 https://www.cwiki.us/display/CONF6ZH/Administering+Collaborative+Editing

我们限制为最多 12 个用户可以同时对一个页面进行编辑。这个意味着当一个页面已经有 12 个用户正在编辑了，13 个用户是不能进入编辑界面的，直到 12 个用户中有一个用户已经离开了。 系统管理员可以使用 Configuring System Properties 页面中描述的配置来增加或者减少这个限制。当你觉得在多个用户进行协同编辑的时候遇到了性能问题，你应该考虑降低允许协同编辑的用户数量。   https://www.cwiki.us/display/CONF6ZH/Administering+Collaborative+Editing

编辑模式确定了你站点所有用户使用协同编辑的体验，这个是你对协同编辑进行启用和关闭的地方。 希望修改编辑模式： 进入  > 基本配置（General Configuration） > 协同编辑（Collaborative editing）。 选择 编辑模式（Change mode）。 选择一个模式，然后选择 修改（Change）。 修改编辑模式其实是不重要的，一些修改可能会导致你的用户丢失他们的草稿，因此针对某个模式，你最好需要知道修改将会导致那些问题。 有下面的模式可用： 模式（Mode） 提示（Implications） 启用（On） 这个模式允许你的小组可用同时进行编辑和分享操作，同时实时的能够看到其他用户的修改。 这是推荐的编辑模式。 限制（Limited） 如果你需要对 Synchrony 进行问题排除的话，这个模式将会包含你用户分享草稿。建议仅仅在当你觉得你的系统在编辑和发布的时候遇到问题了，选择这个模式。 你用户的编辑体验将会受限： 只有一个用户可以编辑一个共享的草稿，而且仅仅只有这个用户可以编辑。 你不可以在页面的历史中恢复到早期的版本。 你不可以移动页面。 你不可以在页面中进行行标注。 当 Synchrony 再次运行后，我们推荐你将协同编辑设置回启用模式。 关闭（Off） 这个模式意味着你的小组仅仅可以编辑自己的页面草稿。Confluence 将会尝试在保存的时候合并有冲突的编辑。这个模式与 Confluence 5 编辑使用的模式相同。 这个模式在你不能在你的系统中成功运行 Synchrony 的时候有用，或者你决定协同编辑模式并不适用你的环境（例如，你现在正在审计需求，你不希望页面被编辑，在这个情况下，协同编辑对你并不合适）。 在你将协同编辑模式修改为关闭的时候，你应该确保你的用户保存的所有草稿都已经被发布了。 https://www.cwiki.us/display/CONF6ZH/Administering+Collaborative+Editing  

协同编辑能够让项目小组中的协同合作达到下一个高度。这个页面对相关协同编辑中的问题进行了讨论，能够提供给你所有希望了解的内容。 进入 Collaborative editing 页面来获得项目小组是如何进行实时的协同工作的，这些协同工作包括在软件需求，会议记录，历史查看和任何你任务需要进行协同工作的地方。 关于 Synchrony 协同编辑是通过 Synchrony 进行的，这个能够实时的同步数据。Synchrony 是一个可执行的进程，这个进程是在 Confluence 之外运行的，但是又是由 Confluence 自动进行管理的。在一般的情况下，这个进程是不需要 Confluence 的管理员进行手动管理的。 希望检查 Synchrony 是否在运行，进入  > 基本配置（General Configuration） > 协同编辑（Collaborative editing）。 这里，你可以检查 Synchrony 的运行状态和当前的配置情况，包括当前的端口，数据库驱动和 Synchrony  使用的最大的 heap 大小。这些信息在你对 Synchrony 进行问题排除的时候非常有用。 Synchrony 在默认的情况下是运行在 8091 端口的，在一个内部的 Synchrony  代理意思是你不需要打开其他的端口。 https://www.cwiki.us/display/CONF6ZH/Administering+Collaborative+Editing

为什么 Confluence 收集使用数据？ 针对 Confluence 我们很自豪 Confluence 是这个星球上最高效和强大的协作工具，我们也计划继续保持这个特性，尽我们最大的努力提供更新的 Confluence 版本。为了我们能够优先发布我们的新 Confluence 版本，我们需要了解我们的客户是如何使用 Confluence 的，这个对我们来说非常重要，如果我不了解用户是如何使用的，我们将不能确定哪些功能是用户需要的。我们收集的数据将有助于我们从成千上万的用户使用中确定哪些对用户而言是重要的，然后将会帮助我们在后续的版本中持续进行更新。 那些数据将会被收集？ 在我们的 Privacy Policy 中将会确定我们将会收集哪些数据，请阅读上面的策略——我们尝试避免使用法律上的套话，而尽可能使用简单的语言进行描述 。 如果你希望查看我们手机的数据的示例，你可以通过在你安装的实例中进行查看。进入  > 通用配置（General Configuration） > 分析（Analytics）。 在 Confluence 中，数据总是会被收集。 Confluence 如何收集数据？ 在老的 Confluence 版本中（Confluence 5.6 或 Confluence Questions 1.0.618 之前的版本）将会不对用户的数据进行收集。数据的分析使用的是  Atlassian Analytics  插件。这个插件将会收集分析日志 <confluence-home>/analytics-logs 中日志文件的事件。这些日志将会使用加密的会话上传后删除。如果 Confluence 不能连接到互联网上，这些数据将不会上传。 在 Confluence 中启用/禁用数据收集 你可以在你的 Confluence 安装实例中关闭和启用数据收集。进入  >通用配置（General Configuration） > 分析（Analytics）。 https://www.cwiki.us/display/CONF6ZH/Data+Collection+Policy

修改警告的阈值 一些警告的阈值是可以被配置的。如果你发现一些阈值很容易就触发警告了，你可以对这些阈值进行调整让你的系统警告不容易被触发。 访问 Recognized System Properties 页面中的内容来获得每一个警告的属性。同时这些信息你也可以在 knowledge base article 知识库页面中找到。 修改诊断表现 你可以可以对警告诊断自身的配置进行修改。例如，你系统诊断进行的频率和诊断信息保留的时间。 访问 Recognized System Properties 页面来获得完整的系统属性列表。   https://www.cwiki.us/display/CONF6ZH/Confluence+Diagnostics

有下面的一些类型的警告。 警告和知识库（Alert and KB） 级别（Level） 默认阈值（Default threshold） 可配置（Configurable） Low free disk space Critical 8192 MB 是（Yes） Low free memory Warn 256 MB 是（Yes） Node left or joined the cluster Info N/A 否（No） Long running task exceeded time limit Warn 300 秒 是（Yes） Garbage collection exceeded time limit Warn 10% （超过最后 20 秒） 是（Yes） 可用的 一些诊断警告在默认情况下是禁用的，这是因为这些警告可能会影响你系统的性能，或者这些警告不是持续诊断的。 我的支持小组可能会在针对特定的一些问题的时候，要求你启用下面的一些警告。支持小组将会提供给你如何启用这些警告的具体操作信息。 Alert and KB 级别（Level） 默认阈值（Default threshold） 可配置（Configurable） HTTP request exceeded time limit Warn 60 秒 是（Yes） Macro rendering exceeded time limit Warn 30 秒 是（Yes） Thread memory allocation rate exceeded limit Warn 5% （超过最后 20 秒） 是（Yes） Sandbox crashed or was terminated during document conversion Info N/A 否（No） 警告级别 有下面 3 个警告级别 信息（Info） - 这些信息可能对系统的诊断起到帮助作用，例如集群的一个节点加入 警告（Warning）  - 这个问题可能对系统的性能和未来的可用性产生影响，例如低内存 严重（Critical ）- 这是一个严重问题，这个问题会影响系统的问题和可用性，例如低磁盘存储空间 绝大部分的警告信息不需要你立即采取行动。   https://www.cwiki.us/display/CONF6ZH/Confluence+Diagnostics

当你对性能进行诊断或者希望知道是什么原因导致 Confluence 崩溃，你希望知道在 Confluence 内部是什么导致这些问题发生的。这个时候系统的诊断信息能够帮助你获得更多的有关的这些信息。 通常情况下不是偶然发生的，诊断警告将会帮助你构建有关你 Confluence 站点表现的详细快照，然后帮助你来识别导致你这些问题的的症状。 这个特性将会在 Confluence 6.11 及其后续版本中退出。我们将会提供为诊断信息提供 UI，请关注我们的站点来获得有关的更新。 有关诊断警告 系统诊断工具的作用是能够对系统的症状和表现进行持续的监控。这些监控的数据，我们认为能够对系统的性能产生比较重要的影响。当阈值达到的时候系统将会触发一个警告。 例如，针对你本地 home（或分享的 home 目录）中的空间低于 256 MB 的时候，警告将会被触发。这个针对你将系统存储空间用尽的情况就比较有用，当你系统空间用尽的时候，你的用户将不能上传文件，导出空间，或者进行一些需要写入磁盘的操作。 请注意，这些阈值只被用来触发警告，这个与超时时间或者其他限制是不同。例如一个长时间运行的任务可能会在 5 分钟后触发一个警告，但是这个任务可能会在 8 分钟后完成。 当一个个警告被触发后，警告信息将会写入到 atlassian-confluence.log 文件中（你的应用程序日志），或者更多的细节信息将会写入到 atlassian-diagnostics.log 文件中。同时将会包含在服务支持的 zip 文件中。 一些表现将会触发一个单一警告，一些其他的操作可能触发多个警告。诊断信息将会存储在数据库中，这些数据每  30 天后会删除。老的警告信息将会在 30 天后被自动清理。   https://www.cwiki.us/display/CONF6ZH/Confluence+Diagnostics

这个文章与 Oracle 的 Hotspot JVM 虚拟机的内存管理为参照的。这些建议是我们在对大的 Confluence 安装实例用户进行咨询服务的时候得到的最佳配置方案。 请不要在 Confluence 中使用 Concurrent Mark Sweep (CMS) ，除非你得到了 Atlassian 支持小组的明确说明。这个需要额外的手工调整和测试，通常这个会降低系统的性能。 使用一个小的 heap 在不出现 OutOfMemory 错误的情况下，保持你的 heap 尽可能的小。当你遇到了 OutOfMemory 错误，需要增加 heap 的时候，我们推荐你按照 512MB 到 1 GB 的顺序进行增加。如果你还持续的获得 OutOfMemory 错误，那么你可以考虑再继续增加 512 MB 或者 1GB。你可以持续进行增加，直到你不再出现 OutOfMemory 错误。不要尝试一次增加到位，这样可能会导致垃圾收集时间的增长。 删除所有老的收集参数 只有在完全的 GC 后，JVM 将会重新定义 Eden, Survivor 等参数的大小，这个大小是基于 GC 处理来确定的。这个将会保证 GC 处理程序能够处理真实的垃圾情况和垃圾对象。在绝大部分情况下，能够保证 JVM 为你提供更好的性能。 如果你的 JVM 中添加了参数，当在垃圾收集的时候遇到了困难。那么我们建议你删除掉你在 GC 前添加的参数，除非你添加的这些参数是为了解决一些特定的问题。你现在应该考虑如何避免在 GC 中出现的问题，而不是导致其他的问题。 检查你的虚拟机（VM）资源 如果你运行 Confluence 在一个 VM 上的话，检查这个 VM 没有使用 swap 文件。 如果这个 VM 了使用了 swap 文件，那么当 JVM 进行垃圾收集的时候，将会把这些 swap 文件载入到内存后清理他们，这个将会导致垃圾清理进程的长时间暂停。为了避免使用 swapping, ballooning 和 bursting，将这些信息载入到 VM 的内存中。 手动清理 如果你按照上面的说明进行了操作后还遇到了一些困难，但是你还是希望能够提高系统的性能，我们推荐你使用Garbage Collection (GC) Tuning Guide 页面提供的方法。这个页面将会知道你如何达到你自己期望的性能指标（throughput/footprint/latency）和如何进行调整。 查看你的垃圾收集日志 How to Enable Garbage Collection (GC) Logging 和使用类似  Chewiebug's GCViewer 工具来查看结果的日志。 https://www.cwiki.us/display/CONF6ZH/Garbage+Collector+Performance+Issuese