服务器到服务器复制和CPU和32k \损坏的文档

简介：如果数据库包含32K问题或损坏的文档，则在服务器到服务器复制时，会导致nserver.exe任务中的CPU显着增加，这有效地导致我们的服务器减慢速度。

我们有一个5个服务器集群（1个“集线器”和4个HTTP服务器，通过反向代理和SSO访问负载平衡和冗余）。 所有的物理位置在networking上彼此相邻，它们没有用于集群或复制的专用networking\端口。 我意识到IBM的build议是集群的专用端口。 集群队列处于容忍和繁重的应用程序用户负载下，即正在创build，编辑，删除的文档的最大数量，服务器之间的复制时间可以忽略不计。 一般来说，一切都很好。

在集群中的服务器中，1被认为是“集线器”，并且每60分钟模仿一次PUSH-PULL复制与集群配合，所以复制负载由集线器而不是集群配对。

我们遇到这样的问题：我们每时每刻都会从集线器到集群队列获得缓慢的复制时间，有时达到30分钟。 这最大化了“群集配合”上的nserver.exe任务，导致它非常缓慢地响应http请求。

过去我们发现如果一个损坏的文档在数据库中，可能会有这种影响，但是在这种情况下，服务器日志会显示损坏的文档noteId，我们运行fixup，一切正常。 但是我们现在还没有看到任何腐败文件的logging。 我们注意到，如果有一个32K的文档出现，同样的事情可能会发生。 我们唯一的解决scheme就是运行：fixup mydb.nsf -V，它显示它正在清除32K文档。 幸运的是，我们运行了一个反向代理，所以我们可以closuresHTTP服务器而不用用户注意，但是当服务器出现问题时用户会注意到！

有没有其他人看到这发生？

我为许多复制事件设置了DDM事件处理程序。 我已将复制超时限制设置为5分钟（我们通常在完全用户负载下看到的最大值为0.1分钟），以防止像以前那样重新复制30分钟。 这是一个临时的工作。

有没有人知道DDM事件来捕捉32K的问题？ 我们至less可以发送警报。

关于32K的问题：这个概念需要另外一个线索，但是我们发现这个问题的来源比较难，因为32K事件相当less见。 我们的应用程序相当复杂，通过双向数据传输与其他各种外部Web服务进行交互。 但是如果我们遇到一个32K的文档，我们就不能看字段属性，所以我们不能确定哪个字段有问题，哪个字段会给我们提供哪个进程是罪魁祸首的线索。 如上所述，我们运行fixup -V。

对此的任何帮助\意见将感激地收到。