【问题标题】:Sitecore index rebuild "job ended unexpectedly"Sitecore 索引重建“作业意外结束”
【发布时间】:2013-07-31 05:34:05
【问题描述】:

在我们的 sitecore 项目(6.6.0 rev. 130404)中,我们在尝试使用 sitecore 控制面板重建大型索引时遇到了问题。有一个包含超过 650,000 个项目的索引。在索引重建操作进行到一半时,进程停止,并在索引重建对话框中显示错误“作业意外结束”。在分析站点核心日志时,我们找不到任何与此相关的记录异常。因为我们不知道索引重建何时真正停止,所以我在所有站点核心日志中搜索“异常”一词,但找不到与此相关的任何内容。

QuickSearch 索引(甚至比我们自己的索引更大)也面临同样的问题。

在日志中,我们看到“索引重建作业已启动”消息,但没有任何与该消息结束或中断相关的信息。

这可能是什么原因?以及如何使用 sitecore 日志找到证据?

(ps。我之前曾在这篇文章中寻求关于良好索引实践的帮助,但没有实施这些建议):Sitecore index rebuilding practices)

【问题讨论】:

    标签: sitecore sitecore6 lucene


    【解决方案1】:

    如果您有权这样做:尝试查看您托管解决方案的服务器上的事件日志。此外,您是否看到诸如“主机环境启动关闭”之类的日志或类似的内容? Sitecore 关闭并显示此错误的原因可能有很多。根据我自己的经验,这可以是:

    • 内存限制超出限制并导致关闭的应用程序池;
    • 关闭池的应用程序池快速故障保护;
    • 网站/数据文件夹中的更改; (数据文件夹最好放在网站文件夹之外);
    • 应用程序池回收时间 -> 可以安排并导致应用程序池回收;

    这些只是我发现有时会导致回收的一些因素。您现在最好检查您的事件日志,并从那里尝试关闭上述原因。

    编辑:确保数据和索引文件夹位于 Web 根目录之外,并更新 web.config 以指向数据文件夹。

    希望对你有所帮助。

    【讨论】:

    • 谢谢你。我发现“站点核心关闭”日志以及“超出内存使用量”消息。所以问题可能就在那里。 (我们的数据文件夹已经在网站文件夹之外)
    • 好吧,我发现当涉及到 lucene 时,具有多个索引读取器的大型索引确实会占用大量内存。您可以(如果您还没有)通过缓存阅读器在不同的布局/子布局之间共享您的索引阅读器。我们发现对于我们的一个拥有大型索引(不是数百万个项目,而是大约 200.000 个项目)的客户来说,这是一个非常方便的解决方案。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-06-23
    • 1970-01-01
    • 1970-01-01
    • 2015-10-12
    • 1970-01-01
    • 2018-07-17
    • 1970-01-01
    相关资源
    最近更新 更多