Question

我正在使用RavenDB版本888。

我的客户端应用程序将数十万个文档插入到RavenDB中。它工作正常。插入后，我的应用程序将查询我预定义的静态索引中的一些数据。我不想要过时的结果，所以我的应用程序会定期查询并等到索引是最新的。

不幸的是，今天我发现我的应用程序挂起（更准确地说，一次又一次地查询RavenDB）因为服务器总是告诉它索引仍然是陈旧的。这有点奇怪，因为很久以前完成了最后一次插入 - 理论上服务器应该完成索引。

我查看了管理工作室并检查了我最简单的索引，它对某种类型的doc集合进行了一些计算。有趣的是，索引给出的计数是最新的（与我在管理工作室的“集合”选项卡中看到的数字相同），但状态是“陈旧的”。它的最后更新显示'6小时前'。总的来说，我的一半索引是这样的陈旧，但另一半是新鲜的根据工作室。

我不知道为什么RavenDB让它们变得陈旧以及RavenDB现在正在做什么。它没有很高的CPU使用率。我该如何调试方案？

更新：

我想我发现了一件可能有助于找到根本原因的事情。将我的非陈旧索引与始终陈旧的索引进行比较后，似乎减少结果很重要：过时索引在reduce结果中具有较大的Value属性，而最新索引具有较小的Value属性。

public class ReduceResult
{
    public string ID { get; set; }
    public string Key { get; set; }
    public long Value { get; set; } //This field seems to matter
}

这是我的索引定义之一：

public class InternalPageCountIndex : AbstractIndexCreationTask<InternalPage, ReduceResult>
{
    public InternalPageCountIndex()
    {
        Map = posts => from post in posts
                       select new
                       {
                           Key = post.BatchID,
                           Value = 1
                       };

        Reduce = results => from result in results
                            group result by result.Key
                                into g
                                select new
                                {
                                    Key = g.Key,
                                    Value = g.Sum(c => c.Value)
                                };
    }
}

顺便说一下，服务器日志看起来也很有趣。今天下午，服务器认为没有工作要做：

2012-04-07 16：36：44.6725，Raven.Database.Tasks.ReduceTask，Debug，Indexed 65在00：00：03.5535907中减少键，索引SNRTotalByteSizeIndex的结果为493666， 2012-04-07 17：35：21.1888，Raven.Database.Indexing.WorkContext，Debug，“找不到工作，workerWorkCounter：5，for：ReducingExecuter，将等待额外的工作”， 2012-04-07 17：35：21.1888，Raven.Database.Indexing.WorkContext，Debug，“找不到工作，workerWorkCounter：5，for：IndexingExecuter，将等待额外的工作”， 2012-04-07 18：35：39.4759，Raven.Database.Indexing.WorkContext，Debug，“找不到工作，workerWorkCounter：5，for：ReducingExecuter，将等待额外的工作”， 2012-04-07 18：35：39.4759，Raven.Database.Indexing.WorkContext，Debug，“找不到工作，workerWorkCounter：5，for：IndexingExecuter，将等待额外的工作”， 2012-04-07 19：35：56.5994，Raven.Database.Indexing.WorkContext，Debug，“找不到工作，workerWorkCounter：5，for：ReducingExecuter，将等待额外的工作”， 2012-04-07 19：35：56.5994，Raven.Database.Indexing.WorkContext，Debug，“找不到工作，workerWorkCounter：5，for：IndexingExecuter，将等待额外的工作”， 2012-04-07 20：36：12.3345，Raven.Database.Indexing.WorkContext，Debug，“找不到工作，workerWorkCounter：5，for：ReducingExecuter，将等待额外的工作”， 2012-04-07 20：36：12.3345，Raven.Database.Indexing.WorkContext，Debug，“找不到工作，workerWorkCounter：5，for：IndexingExecuter，将等待其他工作”，

但是当我今晚通过Management Studio查询RavenDB以查看有多少陈旧索引时，服务器开始执行map / reduce！是的，下午和今晚之间没有插入，但服务器在工作室查询后发现与索引有关...

2012-04-07 21：23：16.9357，Raven.Database.Tasks.ReduceTask，Debug，Read 1 reduce键在00：03：05.6481176中使用505406结果索引InternalPageCountIndex，

2012-04-07 21：23：19.5103，Raven.Database.Indexing.Index.Indexing，Debug，“索引批量/索引结果索引PageCountMissingDescriptionIndex给出了文档：__ reduce_key I-：批次/ 1键IS：批次/ 1值IS：505406 Value_Range IS：505406“，

2012-04-07 21：23：19.6797，Raven.Database.Indexing.Index.Indexing，Debug，Reduce为减少键产生了1个InternalPageCountIndex条目：批次/ 1， 2012-04-07 21：23：19.6797，Raven.Database.Tasks.ReduceTask，Debug，Indexed 1减少00：00：02.7426449中的键，其中505406结果为索引InternalPageCountIndex，

根据工作室查询，服务器仍然告诉我我的索引的一半是陈旧的:(

stale indexes

Answer 1

这是一个错误。

感谢Ayende和RavenDB团队，自909年开始修复此问题。有关详情，请参阅http://groups.google.com/group/ravendb/browse_thread/thread/13b16ce3f562472d。

Answer 2

看起来你正在减少BatchID，并且有很多具有相同批处理ID的项目。这意味着对于每个唯一键，我们必须加载该唯一键的所有映射结果，在您的情况下，它们有505,406，因此需要时间。映射结果花费的时间相对较少。减少它们需要花费时间，因为我们需要减少大量数据。

如何调试：ravendb索引总是陈旧的

2 个答案: