摘要：如果数据库包含有 32K 问题或损坏的文档，则在服务器到服务器的复制过程中，它会导致 nserver.exe 任务中的 CPU 显著增加，从而导致我们的服务器速度变慢。
我们有一个 5 台服务器的集群（1 个“集线器”和 4 台 HTTP 服务器，通过反向代理和 SSO 访问以实现负载平衡和冗余）。所有服务器在网络上的物理位置都相邻，它们没有用于集群或复制的专用网络端口。我意识到 IBM 建议集群使用专用端口。集群队列处于容差状态，并且承受着繁重的应用程序用户负载，即正在创建、编辑、删除的最大文档数量，服务器之间的复制时间可以忽略不计。通常，一切都很好。
在集群中的服务器中，1 被视为“中心”，每 60 分钟与其集群成员模拟一次 PUSH-PULL 复制，这样复制负载就由中心而不是集群成员承担。
我们遇到的问题是：从集线器到集群伙伴的复制时间时常很慢，有时长达 30 分钟。这会使“集群伙伴”上的 nserver.exe 任务达到极限，从而导致其对 http 请求的响应非常缓慢。
过去，我们发现如果数据库中有损坏的文档，就会产生这种影响，但在这些情况下，服务器日志将显示损坏的文档 noteId，我们运行 fixup，一切正常。但现在我们没有看到任何损坏文档的记录。我们注意到，如果存在存在 32K 问题的文档，则会发生同样的事情。在这种情况下，我们唯一的解决方案是运行：fixup mydb.nsf -V，它显示正在清除 32K 文档。幸运的是，我们运行了反向代理，因此我们可以在用户不注意的情况下关闭 HTTP 服务器，但当服务器出现问题时，用户确实会注意到！
还有谁见过这种情况吗？
我已经为许多复制事件设置了 DDM 事件处理程序。我已将复制超时限制设置为 5 分钟（在满用户负载下我们通常看到的最大值是 0.1 分钟），以防止它像以前一样重复 30 分钟。这是一个临时解决办法。
是否有人知道 DDM 事件可以捕获 32K 问题？我们至少可以发送警报。
关于 32K 问题：此问题需要另一个线程，但我们发现很难找到问题的根源，因为 32K 事件相当罕见。我们的应用程序相当复杂，与其他各种外部 Web 服务交互，并进行双向数据传输。但如果我们遇到 32K 文档，我们无法查看字段属性，因此我们无法确定哪个字段有问题，这将为我们提供哪个进程是罪魁祸首的线索。如上所述，我们运行 fixup -V。
任何对此的帮助\评论都将受到感激。
答案1
答案2
也许你可以使用复制探针
我过去遇到过一些复制问题，IBM 建议我使用它。
答案3
您没有提到 Domino 版本，但根据您编写的设置，您似乎比“基本”Domino 管理员拥有更多的知识。因此，为了进行故障排除，您可以尝试禁用/启用 Domino Streaming 复制功能：
也许这能解决问题。