建立 Exchange 內容索引重建基準 – 第 3 部分

英文原文已於 2012 年 7 月 2 日星期一發佈

本系列的第 1 部分中，我說明了 E2K7_IndexRebuildAnalyzer.ps1 指令碼 (可能為英文網頁)，在第 2 部分中，我則探討了有關 Anatoly Girko 和我所開發的搜尋重建架構。在總結這一列之前，我想先展示一系列的圖表和一張「檢測平均值」列表，以說明我們自採用本架構以來所觀察到的重建特性。希望如此能傳達更清楚的概念，並協助您更準確地估算出自身的重建速率。

Microsoft 內部至今的檢測平均值

對於該如何呈現這些值的方式，Anatoly 和我反覆思索良久。大家可以想見，這呈現的可能方法有無限多種。我們決定將圖表聚焦在大多數 Exchange 儲存架構所設計因應的訊息大小： 一封郵件項目 150 KB。接著我們對 信箱數目 套用了第二道篩選，只有我們資料集內擁有 100 個以上作用中信箱的信箱資料庫，才列入下方平均值的計算。篩選後，再從資料集中去除重建作業效能最佳與最差的前 10%，最後得出用以建立圖表的平均結果。

注意 ：在下面的各項圖表中，您會注意到 平均信箱大小 少了一些增量範圍。缺少這些範圍內的統計資料並非出自遺漏或刻意省略，而是因為我們的歷史記錄集中並不存在有效的相關資料。換言之，我們從未針對下列使用者平均信箱大小範圍，進行過內容索引重建作業或是收集資料庫重建後的數據：

• 1700-1799 MB
• 1800-1899 MB
• 2000-2099 MB
• 2100-2199 MB

圖表

我們將展示四張 Excel 樞紐分析圖 ，呈現我們依上述篩選後的資料集之產出量特性。這些樞紐分析表旨在以圖解方式呈現和信箱儲存區相關所產生之各項不同屬性之間的關係 (例如信箱數目、項目數量及 EDB 檔案大小等)，再對照類似特性之信箱儲存區完成 完整編目 所需之產出時間的歷史記錄。

圖表 1

圖表-1 的觀點特別描繪出 每個資料庫的信箱數目 、信箱資料庫相對大小 (GB)，以及它們對於完成信箱儲存區內容索引重建總時間 (分鐘) 的影響，三者之間的關係。

此圖讓我們清楚看到，隨著 Exchange 信箱資料庫上的作用中信箱總數的增加，儲存子系統上 EDB 檔案大小也出現同步上升的趨勢。這樣的關係最後將對 完整編目 內容索引的總完成時間有所影響。簡單來說：作用中的信箱數愈多，通常郵件也就愈多；而郵件愈多，磁碟上的 EDB 檔案也就愈大；磁碟上的 EDB 檔案愈大，「通常」要重建內容索引的時間也就愈久。此假設唯一不成立的情況，只有在信箱資料庫的檔案中存在大量空白的情況下才會出現。在那樣的情況下，要完成內容索引重建的總時間，會比預期的時間快上許多。這種異常的情況也在我們支援的環境下出現過，但它們所產出的統計資料已在上述的篩選過程中被刪除了。

圖表 2

圖表-2 描繪出 平均信箱大小 (只計算資料庫上符合相同篩選條件的樣本集合信箱) 和信箱資料庫索引重建產出量 ( 秒/每信箱 ) 之間的關係。

本圖表基本上再次重申 圖表- 1 的論點，只不過換成以作用中信箱的觀點說明。當作用中的信箱平均大小增加時，該等信箱內的平均郵件數目也會隨之增加。平均而言，信箱內的郵件項目愈多，Search Indexer 完成個別信箱編目的時間就愈久，也因此會對資料庫中所有信箱完成 完整編目 的時間拉長。

圖表 3

圖表-3 說明 平均信箱大小 (只計算資料庫中符合相同篩選條件的信箱) 以及內容索引重建產出量 (MB/每信箱 ) 之間的關係。

圖表-3 建立在 圖表-2 的初始前題之上。它顯示出 平均信箱大小 和 信箱資料庫 中 平均項目數 與 Search Indexer 產出呈反向關係。 圖表-3 以 MB/每秒為單位。

圖表 4

圖表-4 說明 平均信箱大小 (只計算資料庫中符合相同篩選條件的信箱) 以及它對內容索引重建產出量 ( 項目/每秒 - 依 150KB 的平均訊息大小計算) 的影響：

如同 圖表-3 一般， 圖表-4 在 項目/每秒 的效能影響層面也呈現出相反的趨勢。

檢測平均值表格

此表的呈現採用了上述圖表中所套用的相同篩選條件，並加以擷選以整理出以平均信箱大小為主的集中平均值。每一行都各自整理成獨立的單位，增量為 99 MB。每列的產出量特性代表在我們的資料集當中，所有已完成重建作業之相似大小之資料庫的彙總平均值。特別是 平均訊息大小 為 150KB，且資料庫上所有作用中信箱的 平均信箱大小 由 A 欄的範圍所定義。

在此表中所呈現出的歷史平均值，讓我們看到了三種估計內容索引重建時間的可能做法 (至少對我而言)：

• 我們可以依據信箱內 平均訊息大小 為 150KB 的 平均信箱大小 算出一個「歷史平均值」。鑑於我們的資料集中有大量的歷史重建資料，我們選擇運用這個平均值。我們利用「重建前」數據算出平均信箱大小值，再對比歷史平均而得出我們的估計值。接著再拿 Rebuild: Seconds per/Mailbox這欄的綜合平均值乘以資料庫上需要編目的信箱數量，最後得出完成作業所需的總時間。
• 我們也可以不考慮組織內項目數及信箱平均大小，而僅依據 平均訊息大小 算出一個「組織平均值」(此組織平均值即為上表中 Averages 這一欄的數據)。
• 由歷史平均值和組織平均值算出一個綜合平均值。

舉例來說，如果我有一個資料庫的內容索引必須重建，其中使用者的總 平均信箱大小 大約介於 500-599 MB 之間的範圍，且假設平均訊息大小為 150KB，若該資料庫共有 200 名使用者，我便可以藉由三種可能的方法算出估計值：

歷史平均表 ：

200 個信箱 * 63 秒 = 總共 12,600 秒。換算為 210 分鐘或約 3.5 小時，可完成 完整編目 。

組織平均：

200 個信箱 * 108 秒 = 總共 21,600 秒。換算為 360 分鐘或約 6.0 小時，可完成 完整編目 。

綜合平均 (「歷史」 + 「組織」的平均) ：

3.5 + 6.0 = 9.5 小時

9.5 / 2 = 4.75 小時

結論

重建內容索引的總時間一律是變動的，這是因為信箱和項目的數量會不斷改變。要重建內容索引時，最準確可靠的估計永遠是來自於歷史平均值。還有我必須提一下，雖然我們在 MSFT 內部排定內容索引重建時程時，都會盡量排在「對使用者影響最小」的時段，但因為我們的服務廣佈全球，要完全消除使用者的衝擊是不太可能的。您只能期望能將衝擊減輕到最表層。此外在我們的資料集中，我們並未計入 Search Indexer Throttling Delay 這個因子。任何的 Search Indexer Rebuild Throttle Delay 都會在個別單位遞交進行整體作業當下，加以認知並處理。藉由本文所介紹的篩選技巧，您可去除那些負值的平均數 (「產出量過高」的重建作業亦然)，使整體估計值更為準確。

若您偏好與平均值對賭，我必須說我完全站在我們表格的數據這一邊。如果您想要的是更科學的算法，建議您採用類似本文中討論的架構。

希望這個系列對您有所助益，也希望我們的解說有讓您學到些新東西！

祝一切順利！

Eric Norberg
Office 365 專屬服務工程師

這是翻譯後的部落格文章。英文原文請參閱 Establishing Exchange Content Index Rebuild Baselines – Part 3