产品服务器中的Sitecore Lucene索引队列落后

在我们的Sitecore（6.6）实现中，我们使用Lucene索引。在我们的PROD服务器中，索引膨胀过程非常缓慢。目前，它有5000多个条目在索引队列中等待

我使用的查询（在主数据库中）

由于此延迟，创建的数据不能反映其在网站中的更改。这个队列也在不断增加。当网站离线时，索引构建会在一段时间后赶上

这是一个阅读密集型网站

我们遇到了CPU过高的问题，但现在已经解决了。我们认为索引的建立是滞后的，因为CPU的高问题。但是现在CPU运行在30-40%左右。lucene索引队列的增长率仍然很高

---

我如何解决这个问题？请提供帮助。

您需要设置数据库维护任务，以便定期刷新历史记录表。如果您有大量索引的站点，此表可能会变得过大。我认为默认作业会清除这个表中所有超过30天的内容-您可以将其设置得更低。比如一天，或者几天

这篇关于SDN的文章涵盖了大多数标准维护任务：

---

有关搜索、索引和性能的更多一般信息，请参见此处：

我认为您需要退后一步，先问一下为什么要向历史记录表中添加如此多的条目，然后再查看可以对Sitecore进行哪些配置更改

您应该根据实现的每个用例跟踪开发环境中的代码，以查找对Sitecore API的所有调用，其中一个项是：

添加到Sitecore树中

已编辑-更改任何字段项，包括安全性、演示文稿、工作流、发布限制等

复制

已从Sitecore树中删除

已移动到新位置

添加了一个新版本

是否删除了一个版本

在执行过程中，请确保在单个Sitecore.Data.Items.item.Editing.BeginEdit（）和Sitecore.Data.Items.Items.Editing.EndEdit（）调用中执行对项目的所有编辑操作，以便尽可能将更改作为单个编辑操作而不是多个编辑操作执行。每次调用Sitecore.Data.Items.Item.Editing.EndEdit（）时，都会在历史记录表中插入一条新记录，因此不必要的编辑只会导致历史记录表的大小增加

如果使用Sitecore.Data.Items.item.CopyTo（）方法复制项目，请记住，项目的所有版本以及项目的子代都将被复制。这意味着历史记录表中将包含所复制项目的每个版本的记录。如果您只需要最新版本，因此在创建新项目后从中删除旧版本，那么您应该再次注意，从项目中删除版本将导致在历史记录表中插入每个已删除版本的记录

---

如果您已将上述所有操作降至使系统正常运行所需的最低限度，您应该会发现，Lucene索引可以很好地保持最新，而无需更改Sitecore的默认索引配置。

自从上次索引以来，队列中有5000多个项目，您在做什么？您是否在短时间内更改了那么多项？哦，最后您可以减少index.UpdateInterval设置-但我通常不建议这样做。如果你的历史表运行得太大，如果你的历史表运行得太大了，这将不能真正解决这个问题，相反，它会使它变得更坏，阅读Alex Shyba关于索引竞态条件的文章——你可能需要考虑这一点。

select * from Properties (check the index last run time)

select * from History where created > 'last index updated time'