如何調試：ravendb指數常是陳舊

Question

我使用RavenDB版本888

我的客戶端應用程序插入成千上萬的文件到RavenDB。它工作正常。插入後，我的應用程序將查詢預定義的靜態索引中的一些數據。我不希望陳舊的結果，所以我的應用程序將定期查詢，並等待索引是最新的。

不幸的是，今天我發現我的應用程序掛起（更準確地說，一直查詢RavenDB），因爲服務器總是告訴它索引仍舊陳舊。這有點奇怪，因爲最後一次插入是在很久以前完成的 - 理論上服務器應該已經完成​​索引。

我查看了管理工作室，並檢查了我的最簡單的索引，它對我的​​一個文檔集合進行了一些統計。有趣的是，索引給出的計數是最新的（與我在管理工作室的「集合」選項卡中看到的數字相同），但狀態爲「陳​​舊」。它的最新更新顯示'6小時前'。總的來說，我的一半索引是這樣陳舊的，但另一半是新鮮的根據工作室。

我不知道爲什麼RavenDB會讓它們變舊，RavenDB現在在做什麼。它沒有高CPU使用率。我如何調試場景？

UPDATE：

我想我發現了一兩件事，可能有助於找到問題的根源。在比較我的非陳舊索引和永遠陳舊的索引後，似乎減少結果很重要：陳舊索引在減少結果中具有較大的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中減少鍵值，493666結果索引SNRTotalByteSizeIndex， 2012-04-07 17：35：21.1888，Raven.Database.Indexing.WorkContext，調試，「找不到任何工作，workerWorkCounter：5，對於：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，調試，「找不到工作，workerWorkCounter：5，爲：ReducingExecuter，將等待額外的工作」， 2012-04-07 18： 35：39.4759，Raven.Database.Indexing.WorkContext，Debug，「找不到工作，workerWorkCounter：5，for：IndexingExecuter，將等待額外的工作」，Raven.Database 2012-04-07 19:35：56.5994 .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，調試，「沒有工作被發現，workerWorkCounter：5，爲：IndexingExecuter，將等待更多的工作」，

但是，當我查詢RavenDB，看看有多少陳舊指數也有通過管理工作室今晚，服務器開始做地圖/減少！是的，在下午和今晚之間沒有插入，但服務器發現工作室查詢後與索引有關...

2012-04-07 21：23：16.9357，Raven.Database.Tasks.ReduceTask ，調試，讀取1減少00：03：05.6481176中的鍵與505406索引的結果InternalPageCountIndex，

2012-04-07 21：23：19.5103，Raven.Database.Indexing.Index.Indexing，Debug，「Indexing批量/ 1結果索引PageCountMissingDescriptionIndex給出文件：__reduce_key I-：批次/ 1鍵IS：批次/ 1值IS：505406 Value_Range IS：505406「，

2012-04-07 21：23：1 9.6797，Raven.Database.Indexing.Index.Indexing，調試，減少導致1個條目InternalPageCountIndex用於減少鍵：批次/ 1， 2012-04-07 21：23：19.6797，Raven.Database.Tasks.ReduceTask，調試，索引1減少鍵在00：00：02.7426449有505406結果指數InternalPageCountIndex，

而且根據工作室的查詢，服務器還告訴我，我的指數的一半是陳舊:(

Answer 1

它看起來像你正在做的BatchID一個降低，並有與同批次ID的項目很多。 這意味着，每一個獨特的關鍵，我們必須加載所有映射的結果爲唯一鍵，而在你的情況，也有他們的505406，這樣就需要時間。 映射結果花費的時間相對較少。 由於我們需要減少大量數據，因此需要花費時間來減少它們。

Answer 2

這是一個錯誤。

感謝Ayende和RavenDB團隊，這已得到修復，因爲建造909見http://groups.google.com/group/ravendb/browse_thread/thread/13b16ce3f562472d更多。