在我们的Sitecore（6.6）实现中，我们使用Lucene索引。在我们的PROD服务器中，索引构建过程非常缓慢。目前，在索引队列中等待有5000多个条目。
我使用的查询（在master数据库中），
select * from Properties (check the index last run time)
select * from History where created > 'last index updated time'
由于此延迟，创建的数据不会反映其在网站中的更改。此队列也在不断增加。当网站脱机时，索引构建会在一段时间后赶上。
它是一个沉重的阅读密集型网站。
我们遇到了CPU问题，但现在它们已经排序了。由于CPU问题，我们认为指数建设滞后。但现在CPU的运行率约为30-40％。 lucene索引队列增长率仍然很高。
我该如何解决这个问题？请帮忙。
答案 0 :(得分：2)
您需要设置数据库维护任务，以便定期刷新历史记录表。如果您的站点索引很重，则此表可能会变得过大。我认为默认工作会清除这个表格超过30天的所有内容 - 您可以将其设置得低得多。比如1天或者几天。
SDN上的这篇文章涵盖了大多数标准维护任务：http://sdn.sitecore.net/Articles/Administration/Database%20Maintenance.aspx
有关搜索，索引和效果的更多常规信息，请访问：http://sdn.sitecore.net/upload/sitecore6/65/sitecore_search_and_indexing_sc60-65-a4.pdf#search=%22clean%22
答案 1 :(得分：0)
我认为您需要退后一步并询问为什么在查看可以对Sitecore进行哪些配置更改之前，为什么会有大量条目添加到历史记录表中。 / p>
您应该根据实现的每个用例在开发环境中跟踪代码，以查找对项目所在的Sitecore API的所有调用：
正如您所经历的那样，确保对项目的所有编辑操作都在一个Sitecore.Data.Items.Item.Editing.BeginEdit（）和Sitecore.Data.Items.Item.Editing.EndEdit中执行（尽可能调用，以便更改作为单个编辑操作而不是多个执行。每次调用Sitecore.Data.Items.Item.Editing.EndEdit（）时，都会在历史表中插入一条新记录，因此不必要的编辑只会导致历史表大小增加。
如果您使用Sitecore.Data.Items.Item.CopyTo（）方法复制项目，请记住该项目的所有版本以及项目的后代都将重复。这意味着历史记录表将为其中包含已复制项目的每个版本的记录。如果您只需要最新版本，因此在创建新项目后从旧项目中删除旧版本，您应该再次注意，从项目中删除版本将导致在每个已删除版本的历史记录表中插入记录。
如果您已将上述所有操作最小化到使系统正常运行所需的最低限度，您应该会发现Lucene Indexing将保持最新状态，而无需更改Sitecore＆＃39; s默认索引配置。