估算 SharePoint Server 2010 Search 的效能與容量需求

 

適用版本： SharePoint Server 2010

上次修改主題的時間： 2016-11-30

摘要：本文提供 Microsoft SharePoint Server 2010 搜尋之不同部署的容量規劃資訊，包括小型、中型及大型 SharePoint Server 2010 伺服器陣列。

本文提供 SharePoint Server 2010 搜尋之共同作業環境部署的容量規劃資訊，包括下列三種範例搜尋伺服器陣列設定的資訊：

• 測試環境規格，如硬體、伺服器陣列拓撲及設定

• 資料產生的工作量，包括使用者的數目與類別，以及伺服器陣列使用特性

• 測試伺服器陣列資料集，包括資料庫內容和大小

• 專屬於測試環境的狀況與效能資料

本文也包含如何決定部署類似環境所需的硬體、拓撲及設定，以及如何最佳化環境以取得適當的容量與效能特性之一般測試資料和建議。

SharePoint Server 2010 搜尋包含比舊版更豐富的功能集及更靈活的拓撲模型。在您採用這個架構來提供使用者更強大的特性和功能之前，您必須仔細考量其會對伺服器陣列容量及效能產生的影響。

閱讀本文件之後，您將會了解如何執行下列作業：

• 定義環境的效能和容量目標。

• 規劃支援使用者數目和類型所需的硬體，以及您要部署的功能。

• 設計實體和邏輯拓撲，以取得最佳可靠性和效率。

• 測試、驗證及調整環境，以達成效能和容量目標。

• 監視環境的重要指標。

閱讀本文之前，您應該先熟悉下列內容：

• Capacity management and sizing for SharePoint Server 2010

• SharePoint Server 2010 容量管理：軟體界限和限制

• 可用性

• 備援

• 資料庫特定內容

規劃概觀

本文中的案例說明小型、中型及大型測試伺服器陣列，假設其可以協助您開始規劃伺服器陣列的正確容量。這些伺服器陣列大小是基於以下假設的近似值：

• 編目的存放庫主要是 SharePoint Server 內容。

• 33% 的相同索引中可以找到絕大多數的使用者查詢。這表示大多數使用者查詢相同的字詞。

• 使用預設中繼資料設定，以確保屬性資料庫的成長率不會太大。

• 在中大型伺服器陣列中，存在可提供內容給這些搜尋伺服器陣列的編目元件之專用編目目標 (前端網頁伺服器)。

• 對這些伺服器陣列的評量值會隨網路和環境狀況而異，最多可有 10% 的錯誤限度。

選擇案例

若要選擇適當的案例，請考量下列問題：

• 主體大小   必須有多少內容可供搜尋？項目總數應包含所有物件，包括文件、網頁、清單項目及人員。

• 可用性   可用性需求為何？客戶需要可倖免於特定伺服器故障的搜尋解決方案嗎？

• 內容新鮮度   您希望搜尋結果多新鮮？您希望在使用者變更內容之後多久，搜尋可在結果中提供更新的內容？您希望內容變更的頻率為何？

• 輸送量   同時會有多少人搜尋整個內容？這包括使用者輸入查詢方塊、網頁組件自動搜尋資料等隱藏的查詢，或是 Microsoft Outlook 2010 Social Connector 要求的活動摘要，包含需要從搜尋系統進行安全性調整的 URL。

根據這些問題的答案，選擇下列其中一個案例：

• 小型伺服器陣列   包含共用單一 SharePoint Server 伺服器陣列上之一些資源的單一 Search Service 應用程式。一般適用於小型部署，可提供搜尋的內容量有限 (小於 1 千萬筆項目)。根據所需的新鮮度目標，上班時間可能會發生累加編目。

• 中型伺服器陣列   在專用伺服器陣列中包含一或多個 Search Service 應用程式，提供搜尋服務給其他伺服器陣列。可提供搜尋的內容量為中等 (最多 4 千萬筆項目)，因此為了達到採用最新資料的目標，上班時間可能會發生累加編目。

• 大型伺服器陣列   在專用伺服器陣列中包含一或多個 Search Service 應用程式，提供搜尋服務給其他伺服器陣列。可提供搜尋的內容量為大型 (最多 1 億筆項目)，因此為了達到採用最新資料的目標，上班時間可能會發生累加編目。

搜尋生命週期

這三種案例可讓您在伺服器陣列的初期階段評估容量。伺服器陣列會在內容編目時，進入搜尋生命週期的下列階段：

• 索引擷取   這是資料填入的第一個階段。此階段持續的時間取決於內容來源的大小。其特點如下：

  • 內容的完整編目 (可能為並行)。

  • 密切監視編目系統，以確保編目的主機不會成為編目的瓶頸。

  • 每個查詢元件會在變更特定數量的索引之後，觸發經常性主要合併。

• 索引維護   這是伺服器陣列的最常用階段。其特點如下：

  • 對所有內容進行累加編目。

  • 針對 SharePoint Server 內容部署，編目期間所發生的大多數變更為安全性變更。

  • 每個查詢元件會在變更特定數量的索引之後，觸發非經常性主要合併。

• 索引清理   當內容變更將伺服器陣列移出索引維護階段時，即會發生此階段；例如，當內容資料庫或網站從某個 Search Service 應用程式移至另一個 Search Service 應用程式時。此階段會在發生下列其中一個情形時觸發：

  • 搜尋編目程式有很長的一段時間找不到提供內容的主機。

  • 內容來源或起始位址已從 Search Service 應用程式中刪除。

案例

本節說明小型、中型及大型伺服器陣列案例所使用的設定，也包含每個環境的工作量、資料集、效能資料及測試資料。

小型伺服器陣列

由於伺服器陣列很小，因此部分伺服器必須執行多個角色。建議合併查詢元件與前端網頁伺服器，以避免將編目元件和查詢元件置於相同的伺服器上。此設定使用三部應用程式伺服器及一部資料庫伺服器，其說明如下：

• 由於一般建議企業搜尋使用備援查詢伺服器，因此查詢元件會使用兩部應用程式伺服器，並指定下列設定：

  • 其中一部應用程式伺服器會另外主控搜尋中心。如果小型伺服器陣列用做服務伺服器陣列，並在子項內容伺服器陣列上建立使用此父項服務伺服器陣列中之 Search Service 應用程式的搜尋中心，即可省略此設定。

  • 小於 1 千萬筆項目的偏好查詢設定是包含一個索引分割區。每部伺服器接著可以包含來自此索引分割區的主要查詢元件。此主動/主動查詢元件設定可在其中一個查詢元件失敗時，仍然能夠從其餘查詢元件服務查詢。如果查詢元件失敗，搜尋會將查詢 (循環配置資源) 傳送至下一個可用的查詢元件。

• 用於編目及管理的一部應用程式伺服器。這表示會在此伺服器上建立管理中心、搜尋管理元件及編目元件。

• 支援伺服器陣列的一部資料庫伺服器。此資料庫伺服器應該針對編目、屬性及管理資料庫具有專用的每秒輸入/輸出作業 (IOPS) 數目 (例如，使用不同的存放裝置陣列)。

規格

本節提供測試環境之硬體、軟體、拓撲及設定的詳細資訊。

拓撲

硬體

注意

由於測試伺服器陣列執行 SharePoint Server 2010 測試版且小組希望避免潛在問題，因此伺服器所使用的硬體會具有比一般預期更多的容量。

網頁伺服器

網頁伺服器	前端網頁伺服器/查詢 (1)
處理器	1px4c@3 GHz
RAM	16 GB
作業系統	Windows Server 2008 R2 64 位元
儲存裝置	2x450GB 15K SAS：RAID1：OS 2x450GB 15K SAS：RAID1：DATA1 2x450GB 15K SAS：RAID1：DATA2
網路介面卡 (NIC) 數目	2
NIC 速度	1 GB
驗證	NTLM
負載平衡器類型	無
軟體版本	SharePoint Server 2010 (測試版)
在本機執行的服務	所有服務 (包括搜尋查詢和網站設定服務)

應用程式伺服器

伺服器	查詢 (1)	編目/管理 (1)
處理器	1px4c@3 GHz	1px4c@3 GHz
RAM	16 GB	16 GB
作業系統	Windows Server 2008 R2 64 位元	Windows Server 2008 R2 64 位元
儲存裝置	2x450GB 15K SAS：RAID1：OS 2x450GB 15K SAS：RAID1：DATA1 2x450GB 15K SAS：RAID1：DATA2	2x450GB 15K SAS：RAID1：OS 2x450GB 15K SAS：RAID1：TEMP 2x450GB 15K SAS：RAID0：DATA
NIC 數目	1	1
NIC 速度	1 GB	1 GB
驗證	NTLM	NTLM
負載平衡器類型	無	無
軟體版本	SharePoint Server 2010 (測試版)	SharePoint Server 2010 (測試版)
在本機執行的服務	SharePoint Server 搜尋；搜尋查詢和網站設定服務	SharePoint Server 搜尋

資料庫伺服器

資料庫	共用 (1)
處理器	2px4c@3 GHz
RAM	16 GB
作業系統	Windows Server 2008 R2 64 位元
儲存裝置	2x450GB 15K SAS：RAID1：OS 2x450GB 15K SAS：RAID0：DATA 2x450GB 15K SAS：RAID0：LOGS 注意 由於磁碟機數目減少，因此在不同的 IO 通道上隔離資料庫的最佳作法並不適用。
NIC 數目	2
NIC 速度	1 GB
驗證	NTLM
軟體版本	Microsoft SQL Server 2008 Enterprise

工作量

本節說明資料產生的工作量，包括使用者數目及伺服器陣列使用特性。

工作量特性	值
工作量的概略說明	搜尋伺服器陣列
每分鐘的平均查詢數目	6
並行使用者的平均人數	1
每日查詢總數	8,640

資料集

本節說明測試伺服器陣列資料集，包括資料庫內容和大小、搜尋索引及外部資料來源。

物件	值
搜尋索引大小 (項目數)	9 百萬
編目資料庫的大小	52 GB
編目資料庫記錄檔的大小	11 GB
屬性資料庫的大小	68 GB
屬性資料庫記錄檔的大小	1 GB
搜尋管理資料庫的大小	2 GB
使用中索引分割區的大小	38.4 GB (總計 76.8 GB，因為索引為鏡像)
搜尋資料庫總數	3
其他資料庫	SharePoint_Config；SharePoint_AdminContent；State_Service; Bdc_Service_db；WSS_UsageApplication；WSS_Content

狀況與效能資料

本節提供測試環境專屬的狀況與效能資料。

查詢效能資料

以下是使用索引中 9 百萬筆項目所擷取的評量值。不同欄提供特定測試期間所擷取的評量值，並在下列表格底部列出結果。以下說明不同的評量值：

• 查詢延遲   此評量值擷取自查詢延遲測試期間，在此測試中，測試工具會送出一組標準查詢，使用者人數為一名，然後再測量產生的延遲。在測試過程中不會進行任何編目。

• 查詢輸送量   此評量值擷取自查詢輸送量測試期間，在此測試中，測試工具會送出一組針對伺服器陣列的標準查詢，逐漸增加並行使用者的人數 (最多 80)，然後再測量產生的延遲和輸送量。在測試過程中不會進行任何編目。

	計分卡評量值	查詢延遲	查詢輸送量
CPU 評量值	平均 SQL Server CPU	3.4%	12%
	平均前端網頁伺服器 CPU	8%	51%
	平均查詢伺服器 CPU	13.3%	95%
可靠性	失敗率	0	0
	前端網頁伺服器當機次數	0	0
	應用程式伺服器當機次數	0	0
SQL Server	快取命中率 (SQL Server)	99.97%	100%
	SQL Server 鎖定次數：平均等候時間 (毫秒)	0.071	0.038
	SQL Server 鎖定次數：鎖定等候時間 (毫秒)	0.035	0.019
	SQL Server 鎖定次數：死結數目/秒	0	0
	SQL Server Latch 次數：平均等候時間 (毫秒)	31	0.017
	SQL Server 編譯次數/秒	14.9	10.2
	SQL Server 統計資料：SQL Server 重新編譯次數/秒	0.087	0.05
	平均磁碟佇列長度 (SQL Server)	0.011	0.01
	磁碟佇列長度：寫入次數 (SQL Server)	0.01	0.008
	磁碟讀取次數/秒 (SQL Server)	0.894	0.05
	磁碟寫入次數/秒 (SQL Server)	45	106
應用程式伺服器	平均磁碟佇列長度 (查詢伺服器)	0.013	0.001
	磁碟佇列長度：寫入次數 (查詢伺服器)	0	0.001
	磁碟讀取次數/秒 (查詢伺服器)	11.75	0.06
	磁碟寫入次數/秒 (查詢伺服器)	4	5.714
	使用的平均記憶體 (查詢伺服器)	8.73%	9%
	使用的最大記憶體 (查詢伺服器)	8.75%	9%
前端網頁伺服器	佇列的 ASP.NET 要求數 (所有前端網頁伺服器的平均值)	0	0
	使用的平均記憶體 (前端網頁伺服器)	9.67%	95%
	使用的最大記憶體 (前端網頁伺服器)	9.74%	100%
測試結果	成功次數	1,757	13,608
	錯誤數目	0	0
	查詢 UI 延遲 (第 75 個百分位數)	0.331 秒	3.68 秒
	查詢 UI 延遲 (第 95 個百分位數)	0.424 秒	3.93 秒
	查詢輸送量	3.29 要求數/秒	22.4 要求數/秒

編目效能資料

下列評量值擷取自指定內容來源的初始循序完整編目。內容來源大小指定為數百萬筆項目。不同欄提供特定編目期間所擷取的評量值，並在表格底部列出結果。

	計分卡評量值	SharePoint 內容 (4 百萬)	檔案共用 (1 百萬)	HTTP (非 SharePoint) (1 百萬)
CPU 評量值	平均 SQL Server CPU	5.4%	11.7%	23%
	平均索引器 CPU	41.6%	69%	71%
可靠性	失敗率	0	0	0
	前端網頁伺服器當機次數	0	0	0
	應用程式伺服器當機次數	0	0	0
SQL Server	快取命中率 (SQL Server)	無	無	無
	SQL Server 鎖定次數：平均等候時間 (毫秒)	436	51.76	84.73
	SQL Server 鎖定次數：鎖定等候時間 (毫秒)	無	無	無
	SQL Server 鎖定次數：死結數目/秒	無	無	無
	SQL Server Latch 次數：平均等候時間 (毫秒)	1.05	1.64	3.53
	SQL Server 編譯次數/秒	無	無	無
	SQL Server 統計資料：SQL Server 重新編譯次數/秒	無	無	無
	平均磁碟佇列長度 (SQL Server)	27.124	6.85	45
	磁碟佇列長度：寫入次數 (SQL Server)	17.6	6.7	21.57
應用程式伺服器	平均磁碟佇列長度 (編目伺服器)	0.008	0.032	0.02
	磁碟佇列長度：寫入次數 (編目伺服器)	0.006	0.025	0.012
	使用的平均記憶體 (編目伺服器)	14.16%	10.4%	11.5%
	使用的最大記憶體 (編目伺服器)	19.2%	11.13%	12.78%
前端網頁伺服器	佇列的 ASP.NET 要求數 (所有前端網頁伺服器的平均值)	0	0	0
	使用的平均記憶體 (前端網頁伺服器)	無	無	無
	使用的最大記憶體 (前端網頁伺服器)	無	無	無
測試結果	成功次數	3,934,881	1,247,838	996,982
	錯誤數目	9,645	302	2
	入口網站編目速度 (項目數/秒)	46.32	120.436	138.316
	錨點編目速度 (項目數/秒)	5,197	3,466.219	2,192.982
	總編目速度 (項目數/秒)	45.91	116.392	130.086

測試資料

本節提供說明如何執行伺服器陣列的測試資料。請參閱本文稍後的＜最佳化＞一節，以了解如何提升伺服器陣列效能。

查詢延遲

下圖顯示此伺服器陣列的查詢延遲百分位數，以作為使用者負載增量 (在查詢輸出量測試期間收集)。查詢百分位數 95% 表示測量到的查詢延遲有 95% 小於該值。

如圖所示，使用更小的索引時，此伺服器陣列可維持小於一秒的查詢延遲，即使有更多並行使用者 (20) 在此伺服器陣列上執行查詢亦然。

查詢輸送量

下圖顯示此伺服器陣列的查詢輸出量，以作為使用者負載增量 (在查詢輸出量測試期間收集)。

將以上兩圖列入考量，您會發現將使用者負載增加至約 20 位並行使用者時，此伺服器陣列不會產生額外的查詢輸送量，且延遲會增加。

編目率

下圖顯示此伺服器陣列在搜尋生命週期之索引擷取階段期間的編目率。此值表示完整編目，單位為每秒編目的項目數。

對 SharePoint 網站內容來源結果有效執行完整編目所需的額外負荷，會導致此伺服器陣列中的整體編目率降低。

整體提示

此伺服器陣列在查詢伺服器的 RAM 上幾乎滿載。由於前端網頁伺服器處理序 (也會使用 RAM) 也位在其中一部查詢伺服器上，因此會影響在該伺服器上執行的查詢延遲。

提升此伺服器陣列之效能的下一步是執行下列作業：

• 將前端網頁伺服器處理序移至其本身的前端網頁伺服器 (亦即新增其他前端網頁伺服器以供備援使用)。

• 為兩部查詢伺服器增加更多 RAM。建議的查詢伺服器 RAM 為使用中查詢元件之索引分割區的 33%，加上用於作業系統及其他處理序的 3 GB。

• 新增存放裝置陣列，以隔離資料庫伺服器上的資料庫。

中型伺服器陣列

中型伺服器設定使用一部網頁伺服器、六部應用程式伺服器及兩部資料庫伺服器，其說明如下：

• 在此測試設定中使用一部網頁伺服器來主控搜尋中心。如果一律使用 Search Service 應用程式 Proxy (安裝在子項伺服器陣列上) 從子項伺服器陣列執行搜尋，則可以省略此網頁伺服器。否則，您可能需要將其他網頁伺服器加入此伺服器陣列以供備援使用。

• 兩部應用程式伺服器用於編目及管理。這表示：

  • 管理中心與搜尋管理元件會在其中一部應用程式伺服器上建立。

  • 每部伺服器具有兩個編目元件。每個編目元件會附加至不同的編目資料庫以供備援使用。

• 其餘四部應用程式伺服器用於查詢。最多可查詢 4 千萬筆項目，標準設定使用四個索引分割區。透過安排查詢元件，讓每部伺服器具有來自其中一個索引分割區的使用中查詢元件，以及來自另一個索引分割區的容錯移轉查詢元件，即可達成備援查詢功能。但是，此範例伺服器陣列顯示在規劃使用 4 千萬筆以上的項目時，所應執行的作業。您一開始會在四部應用程式伺服器上使用八個索引分割區 (各有其使用中及容錯移轉查詢元件)，以將索引重新分割的情況降至最低。假設每部伺服器滿足下列準則，以在相同的應用程式伺服器上使用四個元件：

  • 提供足夠的 RAM 和 IOPS。

  • 每部伺服器具有六個以上的 CPU 核心，以支援下列處理：

    • 四個 CPU 核心用於兩個使用中查詢元件。

    • 兩個 CPU 核心用於兩個容錯移轉查詢元件。

• 兩部資料庫伺服器支援伺服器陣列。其中一部資料庫伺服器用於兩個編目資料庫。另一部伺服器用於屬性和搜尋管理資料庫，以及其他 SharePoint 資料庫。這些資料庫伺服器應該針對每個編目、屬性及搜尋管理資料庫具有專用的 IOPS 數目 (例如，使用不同的存放裝置陣列)。

規格

本節提供測試環境之硬體、軟體、拓撲及設定的詳細資訊。

拓撲

硬體

注意

由於測試伺服器陣列執行 SharePoint Server 2010 測試版且小組希望避免潛在問題，因此伺服器所使用的硬體會具有比一般預期更多的容量。

網頁伺服器

網頁伺服器	前端網頁伺服器 (1)
處理器	2px4c@2.33 GHz
RAM	8 GB
作業系統	Windows Server 2008 R2 64 位元
儲存裝置	2x148GB 15K SAS：RAID1：OS
NIC 數目	2
NIC 速度	1 GB
驗證	NTLM
負載平衡器類型	無
軟體版本	Microsoft SharePoint Server (測試版)
在本機執行的服務	所有服務

應用程式伺服器

伺服器陣列中共有六部應用程式伺服器。其中四部伺服器用於服務查詢，而另外兩部伺服器則用於編目。

伺服器 (計數)	查詢 (4)	編目 (1)、編目/管理 (1)
處理器	2px4c@2.33 GHz	2px4c@2.33 GHz
RAM	32 GB	8 GB
作業系統	Windows Server 2008 R2 64 位元	Windows Server 2008 R2 64 位元
儲存裝置	2x148 GB 15K SAS：RAID1：OS 4x300GB 15K SAS：RAID10：資料	2x148 GB 15K SAS：RAID1：OS/資料
NIC 數目	2	2
NIC 速度	1 GB	1 GB
驗證	NTLM	NTLM
負載平衡器類型	無	無
軟體版本	SharePoint Server 2010 (測試版)	SharePoint Server 2010 (測試版)
在本機執行的服務	SharePoint Server 搜尋；搜尋查詢和網站設定服務	SharePoint Server 搜尋

資料庫伺服器

共有兩部資料庫伺服器。第一部伺服器包含搜尋管理、屬性及其他 SharePoint Server 資料庫。第二部伺服器包含兩個編目資料庫。請注意，建立的存放磁碟區已最佳化測試所使用的現有硬體。

資料庫伺服器	搜尋管理；屬性；SharePoint 資料庫	編目資料庫
處理器	2px4c@3.2 GHz	4px2c@2.19 GHz
RAM	32 GB	16 GB
作業系統	Windows Server 2008 R2 64 位元	Windows Server 2008 R2 64 位元
儲存裝置	2x148GB 15K SAS：RAID1：OS 2x148GB 15K SAS：RAID1：TEMP 記錄檔 2x450GB 15K SAS：RAID1：TEMP DB 6x450GB 15K SAS：RAID10：屬性 DB 2x450GB 15K SAS：RAID1：搜尋管理 DB、SharePoint DB 2x450GB 15K SAS：RAID1：記錄檔	2x148GB 15K SAS：RAID1：OS 2x148GB 15K SAS：RAID1：TEMP 記錄檔 2x300GB 15K SAS：RAID1：TEMP DB 6x146GB 15K SAS：RAID10：編目 DB1 6x146GB 15K SAS：RAID10：編目 DB2 2x300GB 15K SAS：RAID1：編目 DB 記錄檔 1 2x300GB 15K SAS：RAID1：編目 DB 記錄檔 2
NIC 數目	2	2
NIC 速度	1 GB	1 GB
驗證	NTLM	NTLM
軟體版本	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

工作量

本節說明資料產生的工作量，包括使用者數目及伺服器陣列使用特性。

工作量特性	值
工作量的概略說明	搜尋伺服器陣列
每分鐘的平均查詢數目	12
並行使用者的平均人數	1
每日查詢總數	17,280
計時器工作	搜尋狀況監視 - 追蹤事件；編目記錄報告；狀況分析工作；搜尋與處理

資料集

本節說明測試伺服器陣列資料集，包括資料庫內容和大小、搜尋索引及外部資料來源。

物件	值
搜尋索引大小 (項目數)	4 千 6 百萬
編目資料庫的大小	356 GB
編目資料庫記錄檔的大小	85 GB
屬性資料庫的大小	304 GB
屬性資料庫記錄檔的大小	9 GB
搜尋管理資料庫的大小	5 GB
使用中索引分割區的大小	316 GB (每個使用中元件 79 GB)。
資料庫總數	4
其他資料庫	SharePoint_Config；SharePoint_AdminContent；State_Service; Bdc_Service_db；WSS_UsageApplication；WSS_Content

狀況與效能資料

本節提供測試環境專屬的狀況與效能資料。

查詢效能資料

以下是使用搜尋索引中 4 千 6 百萬筆項目所擷取的評量值。不同欄提供特定測試期間所擷取的評量值，並在表格底部列出結果。以下說明不同的評量值：

• 查詢延遲   此評量值擷取自查詢延遲測試期間，在此測試中，測試工具會送出一組標準的查詢集，使用者人數為一名，然後再測量產生的延遲。在測試過程中不會進行任何編目。

• 查詢輸送量   此評量值擷取自查詢輸送量測試期間，在此測試中，測試工具會送出一組針對伺服器陣列的標準查詢，逐漸增加並行使用者的人數 (最多 80)，然後再測量產生的延遲和輸送量。在測試過程中不會進行任何編目。

	計分卡評量值	查詢延遲	查詢輸送量
CPU 評量值	平均 SQL Server CPU (屬性資料庫伺服器)	5%	98%
	平均前端網頁伺服器 CPU	3%	33%
	平均查詢伺服器 CPU	3%	47%
可靠性	失敗率	0.07%	0%
	前端網頁伺服器當機次數	0	0
	應用程式伺服器當機次數	0	0
SQL Server (屬性資料庫伺服器)	快取命中率 (SQL Server)	100%	99.9%
	SQL Server 鎖定次數：平均等候時間 (毫秒)	0.000	0.159
	SQL Server 鎖定次數：鎖定等候時間 (毫秒)	0.000	0.080
	SQL Server 鎖定次數：死結數目/秒	0	0
	SQL Server Latch 次數：平均等候時間 (毫秒)	0.041	1.626
	SQL Server 編譯次數/秒	9.776	93.361
	SQL Server 統計資料：SQL Server 重新編譯次數/秒	0.059	0.071
	讀寫比例 (每資料庫 IO)	0.01	0.81
	平均磁碟佇列長度 (SQL Server)	0.001	0.037
	磁碟佇列長度：寫入次數 (SQL Server)	0.000	0.003
	磁碟讀取次數/秒 (SQL Server)	0.057	14.139
	磁碟寫入次數/秒 (SQL Server)	4.554	17.515
應用程式伺服器	平均磁碟佇列長度 (查詢伺服器)	0.000	0.001
	磁碟佇列長度：寫入次數 (查詢伺服器)	0.000	0.001
	磁碟讀取次數/秒 (查詢伺服器)	0.043	0.266
	磁碟寫入次數/秒 (查詢伺服器)	4.132	5.564
	使用的平均記憶體 (查詢伺服器)	9%	10%
	使用的最大記憶體 (查詢伺服器)	9%	10%
前端網頁伺服器	佇列的 ASP.NET 要求數 (所有前端網頁伺服器的平均值)	0	0
	使用的平均記憶體 (前端網頁伺服器)	47%	48%
	使用的最大記憶體 (前端網頁伺服器)	47%	49%
測試結果	成功次數	1,398	14,406
	錯誤數目	1	0
	查詢 UI 延遲 (第 75 個百分位數)	0.47 秒	2.57 秒
	查詢 UI 延遲 (第 95 個百分位數)	0.65 秒	3.85 秒
	查詢輸送量	2.38 要求數/秒	27.05 要求數/秒

編目效能資料

下列評量值擷取自指定內容來源的初始完整編目。內容來源大小指定為數百萬筆項目。不同欄提供特定編目期間所擷取的評量值，並在表格底部列出結果。

	計分卡評量值	SharePoint 內容 (3.5 百萬)	檔案共用 (1 百萬)	HTTP (非 SharePoint) (1 百萬)
CPU 評量值	平均 SQL Server CPU (編目資料庫伺服器、屬性資料庫伺服器)	11%、19%	22%、7%	23%、5%
	最大 SQL Server CPU (編目資料庫伺服器、屬性資料庫伺服器)	96%、100%	86%、45%	79%、28%
	平均索引器 CPU	41.6%	69%	71%
可靠性	失敗率	0.2%	0.02%	0%
	前端網頁伺服器當機次數	0	0	0
	應用程式伺服器當機次數	0	0	0
SQL Server (編目資料庫伺服器、屬性資料庫伺服器)	快取命中率 (SQL Server)	99.5%、99.8%	未收集	99.9%、99.3%
	SQL Server 鎖定次數：平均等候時間 [毫秒]	1,881.749、1,106.314	1,617.980、2.882	983.137、0.904
	SQL Server 鎖定次數：最長等候時間 [毫秒]	69,919.500、1,081,703	55,412.000、304.500	24,000.500、47
	SQL Server 鎖定次數：平均鎖定等候時間 [毫秒]	339.658、10,147.012	未收集	739.232、0.136
	SQL Server 鎖定次數：最長鎖定等候時間 [毫秒]	598,106.544、234,708,784	未收集	52,711.592、23.511
	SQL Server 鎖定次數：死結數目/秒	0.001、0	未收集	0.008、0
	SQL Server Latch 次數：平均等候時間 [毫秒]	2.288、13.684	3.042、13.516	2.469、20.093
	SQL Server Latch 次數：最長等候時間 [毫秒]	2,636、1,809	928、858.5	242.929、938.706
	SQL Server 編譯次數/秒：平均值	20.384、5.449	未收集	76.157、6.510
	SQL Server 編譯次數/秒：最大值	332.975、88.992	未收集	295.076、42.999
	SQL Server 統計資料：SQL Server 重新編譯次數/秒：平均值	0.560、0.081	未收集	0.229、0.125
	SQL Server 統計資料：SQL Server 重新編譯次數/秒：最大值	22.999、88.492	未收集	17.999、15.5
	讀寫比例 (每資料庫 IO)：最大值	2.15、1.25	未收集	1.45、0.364
	平均磁碟佇列長度 (SQL Server)	66.765、27.314	129.032、20.665	182.110、11.816
	最大磁碟佇列長度 (SQL Server)	4,201.185、5,497.980	3,050.015、762.542	1,833.765、775.7
	磁碟佇列長度：寫入次數 (SQL Server)：平均值	58.023、13.532	114.197、19.9	175.621、10.417
	磁碟佇列長度：寫入次數 (SQL Server)：最大值	1,005.691、881.892	1,551.437、761.891	1,018.642、768.289
	磁碟讀取次數/秒 (SQL Server)：平均值	245.945、94.131	未收集	137.435、154.103
	磁碟讀取次數/秒 (SQL Server)：最大值	6,420.412、6,450.870	未收集	3,863.283、1,494.805
	磁碟寫入次數/秒 (SQL Server)：平均值	458.144、286.884	未收集	984.668、278.175
	磁碟寫入次數/秒 (SQL Server)：最大值	2,990.779、5,164.949	未收集	2,666.285、4,105.897
應用程式伺服器	平均磁碟佇列長度 (編目伺服器)	0.052	0.043	0.030
	磁碟佇列長度：寫入次數 (編目伺服器)	0.029	0.031	0.026
	磁碟讀取次數/秒 (編目伺服器)	5.405	未收集	0.798
	磁碟寫入次數/秒 (編目伺服器)	48.052	未收集	102.235
	使用的平均記憶體 (編目伺服器)	68%	45%	52%
	使用的最大記憶體 (編目伺服器)	76%	47%	59%
前端網頁伺服器	佇列的 ASP.NET 要求數 (所有前端網頁伺服器的平均值)	0	0	0
	使用的平均記憶體 (前端網頁伺服器)	無	無	無
	使用的最大記憶體 (前端網頁伺服器)	無	無	無
測試結果	成功次數	3,631,080	1,247,838	200,000
	錯誤數目	7,930	304	0
	入口網站編目速度 (項目數/秒)	82	148	81
	錨點編目速度 (項目數/秒)	1,573	1,580	1,149
	總編目速度 (項目數/秒)	79	136	76

測試資料

本節提供說明如何在低負載下執行伺服器陣列的測試資料。

查詢延遲

下圖顯示此伺服器陣列的查詢延遲百分位數，以作為使用者負載增量 (在查詢輸出量測試期間收集)。查詢百分位數 95% 表示測量到的查詢延遲有 95% 小於該值。

如圖所示，使用更小的索引時，此伺服器陣列可在第 95 個百分位數維持小於一秒的查詢延遲，即使有更多並行使用者 (22) 在此伺服器陣列上執行查詢亦然。

查詢輸送量

下圖顯示此伺服器陣列的查詢輸出量，以作為使用者負載增量 (在查詢輸出量測試期間收集)。

將此圖與上圖列入考量，如您所示，如果索引包含 3 千 3 百萬筆項目，伺服器陣列可在第 75 個百分位數約 30 位並行使用者的情況下，維持小於一秒的延遲。仍可容納更多並行使用者負載，但是查詢延遲會增加到超過小於一秒的標記。

然而，如果索引包含 4 千 6 百萬筆項目，則無法容納更多並行使用者負載，且查詢延遲會增加。

編目率

下圖顯示此伺服器陣列在搜尋生命週期的索引擷取階段期間的編目率。此值表示完整編目，單位為每秒編目的項目數。

對 SharePoint 網站內容來源結果有效執行編目所需的額外負荷，會導致此伺服器陣列中的整體編目率降低。

整體表現

此伺服器陣列在查詢伺服器的 RAM 上幾乎滿載。

提升此伺服器陣列之效能的下一步是執行下列作業：

• 為兩部查詢伺服器增加更多 RAM。建議的查詢伺服器 RAM 為使用中查詢元件之索引分割區的 33%，加上用於作業系統及其他處理序的 3 GB。

• 在主控屬性資料庫的資料庫伺服器中增加更多 RAM。在此設定中，索引資料表大小約 92 GB (包括索引)，建議 30 GB RAM 需求。然而，資料庫伺服器僅具有 32 GB RAM 提供服務給屬性資料庫、搜尋管理資料庫及其他 SharePoint Server 資料庫。

• 新增存放裝置陣列，以隔離資料庫伺服器上的資料庫。

• 擴充以增加輸送量及 (或) 減少查詢延遲。

雖然在包含兩個編目資料庫及四個編目元件之伺服器陣列上的編目速度很高，但是伺服器陣列的重要目標可能在於讓索引的特定部分新鮮度更高 (亦即必須很頻繁地編目特定內容)。新增專用於所需內容來源 (使用主機分配規則) 之主機的其他編目資料庫，並建立其他兩個編目元件與資料庫的關聯，即可支援索引新鮮度目標。

大型伺服器陣列

預期的設定使用 1 部網頁伺服器、13 部應用程式伺服器及 3 部資料庫伺服器，其說明如下：

• 一部網頁伺服器用來主控搜尋中心。如果一律使用 Search Service 應用程式 Proxy (安裝在內容伺服器陣列上) 從內容伺服器陣列執行搜尋，則可以省略此網頁伺服器。

• 三部應用程式伺服器用於編目及管理。這表示：

  • 管理中心與搜尋管理元件會在其中一部應用程式伺服器上建立。

  • 每部伺服器具有兩個編目元件。每個編目元件會附加至不同的編目資料庫。

• 其餘十部應用程式伺服器用於查詢。偏好的設定為包含十個索引分割區。每部伺服器接著可以包含來自其中一個索引分割區的主要查詢元件，以及來自另一個索引分割區的容錯移轉查詢元件。

• 四部資料庫伺服器支援伺服器陣列。其中一部伺服器用於屬性及搜尋管理資料庫。第二部伺服器用於屬性資料庫。第三部伺服器用於兩個編目資料庫。第四部伺服器用於一個編目資料庫及其他 SharePoint 資料庫。這些資料庫伺服器應該針對每個編目、屬性及搜尋管理資料庫具有專用的 IOPS 數目 (例如，使用不同的存放裝置陣列)。

規格

本節提供測試環境之硬體、軟體、拓撲及設定的詳細資訊。

拓撲

本節說明測試環境的拓撲。

硬體

本節說明用於測試的硬體。

注意

由於測試伺服器陣列執行 SharePoint Server 2010 測試版且小組希望避免潛在問題，因此伺服器所使用的硬體會具有比一般預期更多的容量。

網頁伺服器

網頁伺服器	前端網頁伺服器 (1)
處理器	2px4c@2.33 GHz
RAM	8 GB
作業系統	Windows Server 2008 R2 64 位元
儲存裝置	2x148GB 15K SAS：RAID1：OS
NIC 數目	2
NIC 速度	1 GB
驗證	NTLM
負載平衡器類型	無
軟體版本	SharePoint Server 2010 (測試版)
在本機執行的服務	所有服務

應用程式伺服器

伺服器陣列中共有 13 部應用程式伺服器。其中 10 部伺服器用於服務查詢，而另外 3 部伺服器則用於編目。

伺服器 (計數)	查詢 (10)	編目 (2)、編目/管理 (1)
處理器	2px4c@2.5 GHz	2px4c@2.5 GHz
RAM	32 GB	32 GB
作業系統	Windows Server 2008 R2 64 位元	Windows Server 2008 R2 64 位元
儲存裝置	2x148GB 15K SAS：RAID1：OS 4x300GB 15K SAS：RAID10：資料	2x148GB 15K SAS：RAID1：OS/資料
NIC 數目	2	2
NIC 速度	1 GB	1 GB
驗證	NTLM	NTLM
負載平衡器類型	無	無
軟體版本	SharePoint Server 2010 (測試版)	SharePoint Server 2010 (測試版)
在本機執行的服務	SharePoint Server 搜尋；搜尋查詢和網站設定服務	SharePoint Server 搜尋

資料庫伺服器

共有四部資料庫伺服器。第一部伺服器包含搜尋管理及屬性資料庫；第二部伺服器包含屬性資料庫；第三部伺服器包含兩個編目資料庫；第四部伺服器包含編目資料庫及 SharePoint 資料庫。請注意，建立的存放磁碟區已最佳化測試所使用的現有硬體。

資料庫伺服器	搜尋管理、屬性及 SharePoint 資料庫	編目資料庫
處理器	2px4c@3.2 GHz	4px2c@2.19 GHz
RAM	32 GB	16 GB
作業系統	Windows Server 2008 R2 64 位元	Windows Server 2008 R2 64 位元
儲存裝置	2x148GB 15K SAS：RAID1：OS 2x148GB 15K SAS：RAID1：TEMP 記錄檔 2x450GB 15K SAS：RAID1：TEMP DB 6x450GB 15K SAS：RAID10：屬性 DB 2x450GB 15K SAS：RAID1：搜尋管理 DB、SharePoint DB 2x450GB 15K SAS：RAID1：記錄檔	2x148GB 15K SAS：RAID1：OS 2x148GB 15K SAS：RAID1：TEMP 記錄檔 2x300GB 15K SAS：RAID1：TEMP DB 6x146GB 15K SAS：RAID10：編目 DB1 6x146GB 15K SAS：RAID10：編目 DB2 2x300GB 15K SAS：RAID1：編目 DB 記錄檔 1 2x300GB 15K SAS：RAID1：編目 DB 記錄檔 2
NIC 數目	2	2
NIC 速度	1 GB	1 GB
驗證	NTLM	NTLM
軟體版本	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

查詢效能資料

以下是使用索引中 1 億 3 百萬筆項目所擷取的評量值。不同欄提供特定測試期間所擷取的評量值，並在表格底部列出結果。以下說明擷取的不同評量值：

• 查詢延遲   此評量值擷取自查詢延遲測試期間，在此測試中，測試工具會送出一組標準的查詢集，使用者人數為一名，然後再測量產生的延遲。在測試過程中不會進行任何編目。

• 查詢輸送量   此評量值擷取自查詢輸送量測試期間，在此測試中，測試工具會送出一組針對伺服器陣列的標準查詢，逐漸增加並行使用者的人數 (最多 120)，然後再測量產生的延遲和輸送量。在測試過程中不會進行任何編目。

	計分卡評量值	查詢輸送量
CPU 評量值	平均 SQL Server CPU (屬性資料庫伺服器)	34%
	平均前端網頁伺服器 CPU	45%
	平均查詢伺服器 CPU	20%
可靠性	失敗率	0%
	前端網頁伺服器當機次數	0
	應用程式伺服器當機次數	0
SQL Server (屬性資料庫伺服器)	快取命中率 (SQL Server)	100%
	SQL Server 鎖定次數：平均等候時間 (毫秒)	0
	SQL Server 鎖定次數：鎖定等候時間 (毫秒)	0
	SQL Server 鎖定次數：死結數目/秒	0
	SQL Server Latch 次數：平均等候時間 (毫秒)	1.401
	SQL Server 編譯次數/秒	73.349
	SQL Server 統計資料：SQL Server 重新編譯次數/秒	0.006
	讀寫比例 (每資料庫 IO)	0.81
	平均磁碟佇列長度 (SQL Server)	0.037
	磁碟佇列長度：寫入次數 (SQL Server)	0.003
	磁碟讀取次數/秒 (SQL Server)	9.88
	磁碟寫入次數/秒 (SQL Server)	354.1
應用程式伺服器	平均磁碟佇列長度 (查詢伺服器)	0.002
	磁碟佇列長度：寫入次數 (查詢伺服器)	0.002
	磁碟讀取次數/秒 (查詢伺服器)	0.035
	磁碟寫入次數/秒 (查詢伺服器)	6.575
	使用的平均記憶體 (查詢伺服器)	6.548%
	使用的最大記憶體 (查詢伺服器)	6.601%
前端網頁伺服器	佇列的 ASP.NET 要求數 (所有前端網頁伺服器的平均值)	0
	使用的平均記憶體 (前端網頁伺服器)	18.081%
	使用的最大記憶體 (前端網頁伺服器)	19.983%
測試結果	成功次數	10,925
	錯誤數目	0
	查詢 UI 延遲 (第 75 個百分位數)	3.431 秒
	查詢 UI 延遲 (第 95 個百分位數)	3.512 秒
	查詢輸送量	36.42 要求數/秒

編目效能資料

下列評量值擷取自指定內容來源的初始循序完整編目。內容大小指定為數百萬筆項目。不同欄提供特定編目期間所擷取的評量值，並在表格底部列出結果。

	計分卡評量值	SharePoint 內容 (3 百 50 萬)	檔案共用 (1 百萬)
CPU 評量值	平均 SQL Server CPU (編目資料庫伺服器、屬性資料庫伺服器)	15.74%、無	24%、6.6%
	最大 SQL Server CPU (編目資料庫伺服器、屬性資料庫伺服器)	100%、無	100%、45%
	平均索引器 CPU	44%	49%
可靠性	失敗率	0.0%	0.00%
	前端網頁伺服器當機次數	0	0
	應用程式伺服器當機次數	0	0
SQL Server (編目資料庫伺服器、屬性資料庫伺服器)	快取命中率 (SQL Server)	99.8%、無	99.797%、99.49%
	SQL Server 鎖定次數：平均等候時間 [毫秒]	734.916、無	1,165、5.866
	SQL Server 鎖定次數：最長等候時間 [毫秒]	15,335、無	28,683、210.5
	SQL Server 鎖定次數：平均鎖定等候時間 [毫秒]	108.98、無	847.72、5.325
	SQL Server 鎖定次數：最長鎖定等候時間 [毫秒]	17,236.96、無	124,353、12,920
	SQL Server 鎖定次數：死結數目/秒	0、無	0.012、0
	SQL Server Latch 次數：平均等候時間 [毫秒]	1.4、無	2.233、40.6
	SQL Server Latch 次數：最長等候時間 [毫秒]	1,606、無	917.8、1,895
	SQL Server 編譯次數/秒：平均值	24.28、無	72.7、11.39
	SQL Server 編譯次數/秒：最大值	416、無	460、76.62
	SQL Server 統計資料：SQL Server 重新編譯次數/秒：平均值	0.560、無	0.295、0.099
	SQL Server 統計資料：SQL Server 重新編譯次數/秒：最大值	0.24、無	17.50、17.393
	讀寫比例 (每資料庫 IO)：最大值	20.3、無	1.18/.214
	平均磁碟佇列長度 (SQL Server)	90.113、無	138.64、27.478
	最大磁碟佇列長度 (SQL Server)	3,179、無	2,783.543、847.574
	磁碟佇列長度：寫入次數 (SQL Server)：平均值	86.93、無	130,853、26.086
	磁碟佇列長度：寫入次數 (SQL Server)：最大值	1,882、無	2,781.197、884.801
	磁碟讀取次數/秒 (SQL Server)：平均值	99、無	147.462、159.159
	磁碟讀取次數/秒 (SQL Server)：最大值	3,772、無	2,403.336、896.462
	磁碟寫入次數/秒 (SQL Server)：平均值	373、無	475.886、539.497
	磁碟寫入次數/秒 (SQL Server)：最大值	18,522、無	2,031.888、4,174.271
應用程式伺服器	平均磁碟佇列長度 (編目伺服器)	0.075	.063
	磁碟佇列長度：寫入次數 (編目伺服器)	0.046	0.053
	磁碟讀取次數/秒 (編目伺服器)	1.958	1.693
	磁碟寫入次數/秒 (編目伺服器)	62.33	101.093
	使用的平均記憶體 (編目伺服器)	59%	56.38%
	使用的最大記憶體 (編目伺服器)	70%	58.93%
前端網頁伺服器	佇列的 ASP.NET 要求數 (所有前端網頁伺服器的平均值)	無	無
	使用的平均記憶體 (前端網頁伺服器)	無	無
	使用的最大記憶體 (前端網頁伺服器)	無	無
測試結果	成功次數	1,909,739	1,247,838
	錯誤數目	9,361	331
	入口網站編目速度 (項目數/秒)	70.3	131.44
	錨點編目速度 (項目數/秒)	764	525.84
	總編目速度 (項目數/秒)	64	105

建議及疑難排解

下列各節提供如何決定部署類似這些案例之環境所需的硬體、拓撲及設定，以及如何最佳化環境以取得適當的容量與效能特性之建議。

建議

本節說明將環境最佳化以取得適當的容量與效能特性，所能採取的特定動作。

硬體建議

如需整體最低需求及建議的系統需求的特定資訊，請參閱＜硬體及軟體需求 (SharePoint Server 2010)＞。請注意，用於搜尋的伺服器需求會取代整體系統需求。請使用下列 RAM、處理器及 IOPS 的建議準則，以達成效能目標。

調整搜尋大小

本節說明搜尋系統，包括每個元件的大小需求和準則。

有各種方式可以部署與設定 SharePoint Server 2010；並沒有簡單的方法可以預估指定的伺服器數量能夠支援多少位使用者或項目。因此，請務必先在您自己的環境中進行測試，再於實際執行環境中部署 SharePoint Server 2010。

搜尋查詢系統

本節顯示指定 Search Service 應用程式之搜尋查詢系統的元件。每個元件的大小需求會列在下圖底下的「縮放詳細資料」表格中。

物件描述

下列清單定義上圖中的搜尋查詢系統物件：

• 搜尋 Proxy   這是安裝在任何使用此 Search Service 應用程式中的搜尋之任何伺服器陣列上的 Search Service 應用程式 Proxy。該 Proxy 在與 Search Service 應用程式 Proxy 相關聯的 Web 應用程式內容中執行。

• 搜尋查詢和網站設定服務   又稱為查詢處理器。查詢處理器從 Search Service 應用程式 Proxy 連線接收查詢，然後執行下列作業：

  • 根據查詢，將查詢傳送至每個索引分割區的其中一個使用中查詢元件及 (或) 屬性資料庫

  • 擷取「首選」並移除重複項，以取得結果集

  • 根據搜尋管理資料庫中的安全性描述元，對結果進行安全性調整

  • 從屬性資料庫擷取最終結果集的中繼資料

  • 將查詢結果傳回 Proxy

• 索引分割區   這是查詢元件的邏輯群組，表示全文檢索索引的子集。所有索引分割區共同組成全文檢索索引。但是請注意，查詢元件包含索引的實際子集。一個索引分割區會與一個屬性資料庫相關聯。

• 搜尋查詢元件   查詢元件包含所有或部分全文檢索索引。查詢處理器查詢時，查詢元件會從其索引中決定最佳結果，並傳回這些項目。您可以建立下列查詢元件：

  • 使用中，表示預設會回應查詢。新增相同索引分割區的多個使用中查詢元件會增加輸送量。

  • 容錯移轉，表示僅在相同索引分割區的所有使用中元件均失敗時，才回應查詢。

• 搜尋管理資料庫   與 Search Service 應用程式同時建立，搜尋管理資料庫包含用於查詢的整個 Search Service 應用程式資料 (例如「首選」和安全性描述元)，以及用於管理的應用程式設定。

• 屬性資料庫   屬性資料庫包含索引中項目的中繼資料 (標題、作者、相關欄位)。屬性資料庫可用於屬性式查詢，以及擷取顯示最終結果所需的中繼資料。如果存在多個索引分割區，索引分割區可對應至不同的屬性資料庫。

縮放詳細資料

物件	縮放考量	RAM	IOPS (讀取/寫入)
搜尋 Proxy	隨相關聯的前端網頁伺服器縮放。	無	無
搜尋查詢和網站設定服務	每部使用查詢元件的伺服器上，都應該啟動此服務 (在管理中心的 [伺服器上的服務] 頁面中安裝)。可移至個別的伺服器 (或成對的伺服器以取得高可用性)，以避免使用包含查詢元件之伺服器上的 RAM。此外，如果使用自訂安全性修剪器 (可能為英文網頁)，則會影響 CPU 和 RAM 資源。	使用 RAM (處理序快取) 快取索引的安全性描述元。	無
索引分割區	增加索引分割區的數目會減少索引分割區的項目數，從而減少主控指派給索引分割區之查詢元件的查詢伺服器所需的 RAM 與磁碟空間。	無	無
查詢元件	伺服器上的每個使用中查詢元件在服務查詢時，會使用記憶體。每個使用中查詢元件會當做 Search Service 應用程式拓撲的一部分予以建立或修改。使用中及容錯移轉元件在編目時，都會使用 IO。假設符合 RAM 和 IO 需求，伺服器可以是查詢元件的專用伺服器 (例如在相同伺服器上包含兩個使用中元件與兩個容錯移轉元件)。 請儘可能針對每部伺服器的每個使用中元件，至少設定兩個專用 CPU 核心，以及針對每部伺服器的每個容錯移轉元件，至少設定一個專用 CPU 核心。	針對應用程式伺服器上的每個使用中查詢元件，此索引的 33% 應該位於 RAM (作業系統快取) 中。	指定伺服器上的查詢元件每對 (使用中/容錯移轉) 需要 2 K。 查詢元件需要 IO 來執行下列作業： 將索引載入 RAM 中以供查詢使用 寫入從每個編目元件接收的索引片段 將索引片段併入其索引，例如在主要合併期間
搜尋管理資料庫	每次查詢都會從搜尋管理資料庫載入「首選」和安全性描述元。確定資料庫伺服器具有足夠的 RAM，可從快取提供服務。請儘可能避免將此置於包含編目資料庫的伺服器上，因為編目資料庫傾向重設其資料庫伺服器的快取。	確定資料庫伺服器具有足夠的 RAM，可在 RAM 中保留重要表格 (MSSSecurityDescriptors)。	700
屬性資料庫	每次查詢都會從屬性資料庫擷取文件結果的中繼資料，如此可增加資料庫伺服器的 RAM 以提升效能。如果存在多個索引分割區，即可分割屬性資料庫，並移至其他資料庫伺服器以減少 RAM 和 IO 需求。	確定資料庫伺服器具有足夠的 RAM，可在快取中保留 33% 的重要表格 (MSSDocSDIDs + MSSDocProps + MSSDocresults)。	2 K 30% 讀取，70% 寫入

搜尋編目系統

本節顯示搜尋編目系統的元件。每個元件的大小需求會顯示在下圖底下的表格中。

物件描述

本節定義上圖中的搜尋編目系統物件：

• 管理元件   除了在編目系統上執行管理工作之外，啟動編目時也會使用管理元件。

• 編目元件   編目元件可處理編目、將結果索引片段檔案傳播至查詢元件，以及將內容來源之位置及編目排程的資訊新增至其相關聯的編目資料庫。

• 搜尋管理資料庫   搜尋管理資料庫與 Search Service 應用程式同時建立，可儲存編目期間探索到的安全性描述元，以及用於管理的應用程式設定。

• 編目資料庫   編目資料庫包含與內容來源位置相關的資料、編目排程，以及編目作業的其他特定資訊。透過建立主機分配規則，即可專屬於特定主機。編目資料庫僅可儲存資料。與指定編目資料庫相關聯的編目元件會進行編目。

• 搜尋查詢系統

縮放詳細資料

物件	縮放考量	RAM	IOPS (選擇性，% 讀取/寫入)
管理元件	您無法擴充單一管理元件。管理元件預設會位於主控編目元件 (及小型伺服器陣列上的管理中心) 的伺服器上。	最小	最小
編目元件	編目元件會使用大量的 CPU 頻寬。在理想的狀況下，指定編目元件可以使用四個 CPU 核心。在較大型的伺服器陣列中，RAM 較不重要，設定主控編目元件的專用伺服器可以將編目程式對其他元件的影響降至最低 (特別是在需要備援時，使用與不同編目資料庫相關聯的編目元件)。	一般。請注意，編目東亞文件時，RAM 需求會由於斷詞工具而增加。	300-400
搜尋管理資料庫	請參閱以上的搜尋查詢系統。請儘可能避免將此置於包含編目資料庫的伺服器上，因為編目資料庫傾向重設其資料庫伺服器的快取。	請參閱以上的搜尋查詢系統。	700
編目資料庫	編目資料庫會使用大量的 IO 頻寬。RAM 較不重要。編目資料庫需要 3.5 K IOPS 以用於編目活動，根據可用頻寬，最多會使用 6 K IOPS。	一般	3.5 – 7 K 73% 讀取，27% 寫入

計算儲存大小

計算下列因素有助於評估儲存需求。大小因素是根據內部預先部署的系統，該系統具有包含主要 SharePoint 內容的索引 (內容資料庫的大小為 13.3 TB)。整體而言，SharePoint 搜尋需要約 20% 的內容資料庫磁碟空間。如前所述，請務必先在您自己的環境中進行測試，再於實際執行環境中部署 SharePoint Server 2010。

警告：

• 用於衍生這些數字的主體主要是 (英文) SharePoint 內容，因此如果您的內容不同 (例如，大部分包含檔案共用或非 SharePoint HTTP 網站)，您需要允許更多變化。

• 即使內容主要是 SharePoint 內容，您仍會在下列情況中改變係數：

  • 如果您具有大型文件存放庫，係數會大幅變大。

  • 如果內容主要是圖像，您可以降低係數。

  • 不同語言的內容可能會影響係數。

1. 計算內容資料庫大小因素 (ContentDBSum)

決定要編目的 SharePoint 內容資料庫總和。這是 ContentDBSum 值，會當作下一個儲存計算的相互關聯。

2. 計算索引相關大小 (TotalIndexSize 和 QueryComponentIndexSize)

決定索引大小總計 (該索引位於查詢元件並可用於全文查詢)：

將 ContentDBSum 乘以 .035，即得到分割及保留空間以供合併及重新分割之前的 TotalIndexSize。

接著根據您的案例，決定要使用的索引分割區數目。索引分割區一般應包含 5 百萬到 1 千萬筆項目。決定索引分割區數目之後，即可計算查詢元件存放區的大小。

• 將 TotalIndexSize 除以 (索引分割區數目)，即得到 QueryComponentIndexSize。此值可用於計算下列大小：

  • 若是 RAM，請將 QueryComponentIndexSize 乘以 0.33，即得到使用中查詢元件所需的最小 RAM。

    • 如果元件是容錯移轉元件，在啟用前將不需要 RAM。

    • 針對指定伺服器，如果相同伺服器上具有多個使用中查詢元件，即表示您必須加總每個使用中查詢元件的 RAM，才能得到該伺服器的 RAM 需求。

  • 若是磁碟儲存空間，請根據是否需要重新分割索引 (亦即您預期索引會成長超過每個磁碟分割 1 千萬筆項目的界限)，透過下列方式使用 QueryComponentIndexSize 評估磁碟需求：

    • 將 QueryComponentIndexSize 乘以 3，可計算讓單一查詢元件有空間合併索引的磁碟儲存空間。

    • 將 QueryComponentIndexSize 乘以 4，可計算讓單一查詢元件有空間重新分割索引的磁碟儲存空間。

針對指定的伺服器，在相同的伺服器上具有多個查詢元件，表示您必須根據本文稍早＜搜尋查詢系統＞一節之＜縮放詳細資料＞一節的 IOPS 需求，來安排每個查詢元件的儲存空間。

3. 計算屬性資料庫大小

透過下列方式決定屬性資料庫的大小：

• 將 ContentDBSum 乘以 0.015，即得到磁碟分割前的 TotalPropertyDBSize。

• 將 ContentDBSum 乘以 0.0031，即得到磁碟分割前的 TotalPropertyDBLogSize。假設您針對 SQL Server 資料庫使用簡單復原模式。

• 將 ContentDBSum 乘以 0.00034，即得到屬性資料庫的 TempDBSize。由於建議將屬性資料庫的 33% 重要表格置於 RAM 中，因此暫存資料庫的使用情況並不嚴重。

接著根據您的案例，決定要使用的屬性資料庫數目。屬性資料庫一般最多應包含 5 千萬筆項目，並假設沒有查詢效能問題，且 Managed 屬性數目有限 (標準設定)。

• 將 TotalPropertyDBSize 除以 (屬性資料庫數目)，即得到 PropertyDatabaseSize。

• 將 TotalPropertyDBLogSize 除以 (屬性資料庫數目)，即得到 PropertyDatabaseLogSize。

• 若是 RAM，請將 PropertyDatabaseSize 乘以 0.33，即得到此屬性資料庫的建議 RAM 數量下限。

針對指定的資料庫伺服器，在相同的伺服器上具有多個屬性資料庫，表示您必須根據本文稍早＜搜尋查詢系統＞一節之＜縮放詳細資料＞一節的 IOPS 和 RAM 需求，來安排每個屬性資料庫的儲存空間和 RAM。

4. 計算編目資料庫大小

接著透過下列方式決定編目資料庫所需的大小：

• 將 ContentDBSum 乘以 .046，即得到磁碟分割前的 TotalCrawlDBSize。

• 將 ContentDBSum 乘以 .011，即得到磁碟分割前的 TotalCrawlDBLogSize。假設您針對 SQL Server 資料庫使用簡單復原模式。

• 將 ContentDBSum 乘以 .0011，即得到編目資料庫的 TempDBSize。由於搜尋編目系統影響暫存資料庫的效能，因此不建議將其他資料庫置於主控編目資料庫或受此流量影響之資料庫的伺服器上。

接著根據您的案例，決定要使用的編目資料庫數目。編目資料庫一般最多應包含 2 千 5 百萬筆項目，並假設沒有編目效能問題。

• 將 TotalCrawlDBSize 除以 (編目資料庫數目)，即得到 CrawlDatabaseSize。

• 將 TotalCrawlDBSize 除以 (編目資料庫數目)，即得到 CrawlDatabaseLogSize。

針對指定的資料庫伺服器，在相同的伺服器上具有多個編目資料庫，表示您必須根據本文稍早＜搜尋編目系統＞一節之＜縮放詳細資料＞一節的 IOPS 需求，來安排每個編目資料庫的儲存空間。若是 RAM，建議資料庫伺服器上至少有 16 GB 專屬於編目資料庫。

5. 計算搜尋管理資料庫大小

透過下列方式決定搜尋管理資料庫的大小 (假設使用 Windows 驗證)：

• 將索引中的項目數 (以百萬為單位) 乘以 0.3，即得到 SearchAdminDBSize。

• 若是 RAM，請將 SearchAdminDBSize 乘以 0.33，即得到此搜尋管理資料庫的建議 RAM 數量下限。

針對指定的資料庫伺服器，在相同的伺服器上具有多個資料庫，表示您必須根據本文稍早＜搜尋查詢系統＞一節之＜縮放詳細資料＞一節的 IOPS 和 RAM 需求，來安排每個資料庫的儲存空間和 RAM。

選用：計算備份大小

若要決定備份一個 Search Service 應用程式所需的磁碟空間，請執行下列計算：

• TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize = 基本備份大小。

此基本備份大小是起點，還會受到下列項目的影響：

• 自上次主要合併以來所發生之任何編目，對 TotalIndexSize 造成的額外索引大小。

• 在一段時間後由於額外項目、查詢及安全性描述元而成長。

此外，您可能需要保留不同時段的多個備份，以及保留空間以供下次備份使用。

調整大小練習

使用前述的大小因素進行以下的調整大小練習，該練習使用含有 1 億筆項目的伺服器陣列，來服務主要為 SharePoint 內容的查詢。使用大型伺服器陣列案例時，需要假設下列事項：

• 容納 1 億筆項目需要十個邏輯索引分割區。

• 為了服務查詢，需要 10 個使用中查詢元件，且每個索引分割區各一個。

• 查詢備援很重要，因此需要 10 個容錯移轉查詢元件，且每個索引分割區各一個 (與使用中元件位於不同的伺服器)。

若要決定儲存空間和 RAM 需求，請執行下列步驟：

1. 在含有多個內容資料庫的 SharePoint 內容伺服器陣列中，將您要編目的所有內容資料庫相加得到 20 TB。

2. 使用前述的索引係數，將 20 TB 乘以 0.035 (索引係數) 得到 716.8 GB。此即為 TotalIndexSize。如果您只有一個分割區，則會是靜止索引的大小。

3. 將 TotalIndexSize 除以分割區數目：716.8 GB / 71.68 GB，即得到一個索引分割區之一個查詢元件所需的索引大小 (QueryComponentIndexSize)。使用中查詢元件和容錯移轉查詢元件的大小相同。

4. 如果規劃重新分割，請將 TotalIndexSize 乘以 4；否則請乘以 3 以支援主要合併。71.68 GB * 4 = 286.72 GB。查詢伺服器的磁碟上應該有 286.72 GB，才可支援一個查詢元件。如果相同的應用程式伺服器上具有兩個查詢元件 (例如大型伺服器陣列案例所建議的使用中/容錯移轉拓撲)，則需要如下的磁碟機配置：

   1. 作業系統磁碟機 (標準大小)。

   2. 額外的儲存系統 1：Query Component1_Share (大小 = 至少 300 GB)，用於索引分割區 1 的使用中查詢元件。

   3. 額外的儲存系統 2：Query Component2_Share (大小 = 至少 300 GB)，用於索引分割區 2 的容錯移轉 (鏡像) 查詢元件。

注意

在此含有一個使用中查詢元件的應用程式伺服器上，作業系統至少需要 71.68 GB * 0.33 = 23.65 GB 的 RAM + 3 GB RAM (我們使用 32 GB) 才能快取大部分的查詢。

軟體限制

下表提供為支援可接受之搜尋體驗所設定的軟體限制。

物件	限制	其他注意事項
SharePoint Search Service 應用程式	每個伺服器陣列建議的上限為 20 個。絕對最大總數為 256 個服務應用程式。	您可以在相同的伺服器陣列上部署多個 Search Service 應用程式，因為您可以將搜尋元件與資料庫指派到不同的伺服器。
已編製索引的文件	整體建議的上限為每個索引分割區 1 千萬筆項目，而每個 Search Service 應用程式 1 億筆項目。	SharePoint 搜尋支援索引分割區，這些索引分割區各含整個搜尋索引的子集。在指定的分割區中建議的最大值是 1 千萬筆項目。整體建議的項目數上限 (包括人員、清單項目、文件及網頁) 為 1 億。
索引分割區	每個 Search Service 應用程式建議的上限為 20 個	此索引分割區是 Search Service 應用程式索引的邏輯子集。建議的限制為 20。增加索引分割區的數目會減少索引分割區中的項目數，從而減少主控指派給索引分割區之查詢元件的查詢伺服器所需的 RAM 與磁碟空間。但是，由於索引分割區中的項目數減少，因此這會影響相關性。索引分割區的固定限制為 128。
屬性資料庫	每個 Search Service 應用程式建議的限制為 10 個	屬性資料庫會在每個與其關聯的相關聯索引分割區中儲存項目的中繼資料。索引分割區只能與一個屬性儲存區關聯。建議的限制是每個 Search Service 應用程式 10 個，固定限制為 255 個 (與索引分割區相同)。
編目資料庫	限制為每個應用程式 32 個編目資料庫	編目資料庫會儲存所有已編目之項目的編目資料 (包括時間和狀態)。建議的限制為每個編目資料庫 2 千 5 百萬個項目，或是每個 Search Service 應用程式總共四個資料庫。
編目元件	每個應用程式建議的限制總共為 16 個編目元件，每個編目資料庫兩個編目元件，每部伺服器兩個編目元件，這是假設伺服器至少有八個處理器 (核心)。	每個伺服器的編目元件總數必須少於 128/(總查詢元件)，以便將傳播 I/O 的效能降低減至最小。超過建議的限制可能不會提升編目效能。事實上，編目效能可能會隨編目伺服器、資料庫及內容主機上的可用資源而降低。
查詢元件	每個應用程式的建議限制為 128 個，每部伺服器 64/(總編目元件)	查詢元件的總數會受到編目元件複製檔案能力的限制。每個伺服器的查詢元件數目上限受到查詢元件吸收來自編目元件傳播之檔案能力的限制。
同時編目	每個Search Service 應用程式建議的限制為 20 個編目。	這是同時可進行編目的數目。編目是相當昂貴的搜尋工作，會影響資料庫負載及其他應用程式負載。超過 20 個同時編目數目會造成整體編目速率下降。
內容來源	每個 Search Service 應用程式建議的限制為 50 個內容來源。	建議的限制最多可超過至每個 Search Service 應用程式 500 個的固定限制。不過，應該使用較少的起始位址，而且必須遵循並行編目限制。
起始位址	每個內容來源建議的限制為 100 個起始位址。	建議的限制最多可超過至每個內容來源 500 個的固定限制。不過，應該使用較少的內容來源。當您具有許多起始位址時，較佳的作法是將其以連結的方式置於 HTML 網頁上，然後再讓 HTTP 編目程式編目該頁面，以依循這些連結。
編目規則	每個 Search Service 應用程式建議的限制為 100 個	可以超過此建議值；不過，在搜尋管理中編目規則的顯示會變慢。
編目記錄檔	每個應用程式建議的限制為 1 億個	這是編目記錄檔的個別記錄檔項目數，遵循已編製索引的文件限制。
每個項目已辨識的中繼資料屬性	固定限制為 10,000。	這是編目項目時，可決定且可能對應或用於查詢的中繼資料屬性數目。
編目屬性	每個 Search Service 應用程式 500,000 個	這些是在編目期間所探索的屬性。
Managed 屬性	每個 Search Service 應用程式 100,000 個	這些是在查詢中搜尋系統所使用的屬性。編目屬性會對應至 Managed 屬性。建議每個 Managed 屬性最多對應 100 個。超過這個限制可能會降低編目速度和查詢效能。
範圍	每個網站建議的限制為 200 個	這是每個網站建議的限制。超過這個限制可能會降低編目效率，而且如果將範圍新增至顯示群組，會影響使用者瀏覽器的延遲。此外，當範圍數目增加超過建議的限制時，在搜尋管理中的範圍顯示會變慢。
顯示群組	每個網站 25 個	透過使用者介面的範圍群組顯示會使用這些顯示群組。超過這個限制會開始降低搜尋管理範圍經驗。
範圍規則	建議的限制為每個範圍 100 個範圍規則，以及每個 Search Service 應用程式總共 600 個。	超過此限制將降低新鮮度，並延遲範圍查詢的潛在結果。
關鍵字	每個網站集合建議的限制為 200 個	若每個關鍵字提供五個「首選」，建議的限制最多可超過至每個網站集合 5,000 個的上限 (受到 ASP.NET 限制)。在網站管理使用者介面上的關鍵字顯示將會變慢。ASP.NET 原本的限制可以透過編輯 Web.config 與 Client.config 檔案 (MaxItemsInObjectGraph) 來加以修改。
代表性頁面	建議的限制是一個頂層代表性頁面，以及儘可能最少的第二及第三層頁面，同時達成所需的相關性。	固定限制是每個 Search Service 應用程式每個相關性層次 200 個，但是新增頁面可能不會達到所需的相關性。將關鍵網站新增至第一個相關性層次。在第二個或第三個相關性層次新增後續關鍵網站，一次新增一個，並在每次新增後評估相關性，以確保已達到所需的相關性效果。
提醒	每個 Search Service 應用程式建議的限制為 1,000,000 個	這是已測試的限制。
結果移除	一次作業 100 個 URL	這是從系統中一次作業應該移除的建議 URL 數目上限。

最佳化

下列各節討論提升伺服器陣列效能的方法。

影響效能的因素有許多。這些因素包含使用者數目；使用者作業的類型、複雜度及頻率；每次作業的回傳數目；以及資料連線的效能。這些因素各自對伺服器陣列輸送量有重大影響。您應該在規劃部署時，謹慎考慮每個因素。

搜尋系統的容量和效能與其拓撲極度相關。您可以增加現有伺服器電腦的容量以擴充，或將伺服器新增至拓撲以擴充。

搜尋查詢系統最佳化

一般而言，搜尋查詢最佳化遵循下列其中一個案例：

• 使用者抱怨查詢延遲，因此我必須減少查詢延遲。

• 出現比預期更多的搜尋要求，導致效能開始降低，因此我必須增加查詢輸送量。

向外延展或向上擴充查詢子系統一律需要建立更多查詢元件。如果現有的查詢伺服器上有多餘的容量 (RAM、IO 及 CPU)，您可以選擇在該伺服器上建立更多查詢元件以擴充，如此在遇到瓶頸時，便可以增加 RAM、CPU 或 IO。或者，您可以選擇在新伺服器上建立更多查詢元件 (或移動現有的元件)，以擴充。

下列各節顯示將查詢資源新增至搜尋查詢系統的各種方式。

如何減少查詢延遲

新增查詢元件以減少延遲

下圖說明在不同伺服器上新增使用中查詢元件，而不變更索引大小的影響。

新增更多使用中查詢元件，以在系統上的使用者負載 (以同時進行的使用者查詢數目為單位) 增加時，維持小於一秒的查詢延遲。

新增查詢處理器 (查詢和網站設定服務) 以減少延遲

下圖說明在不同伺服器上新增使用中查詢處理器服務，而不變更查詢系統其他任何部分的影響。

在不同的伺服器上啟動查詢和網站設定服務的其他使用中執行個體，以在系統上的使用者負載 (以同時進行的使用者查詢數目為單位) 增加時，維持小於一秒的查詢延遲。

擴充以增加查詢輸送量

新增查詢元件以增加查詢輸送量

下圖說明在不同伺服器上新增使用中查詢元件，而不變更索引大小的影響。

新增更多使用中查詢元件，以在系統上的使用者負載 (以同時進行的使用者查詢數目為單位) 增加時，增加查詢輸送量。

新增查詢處理器 (查詢和網站設定服務) 以增加查詢輸送量

下圖說明在不同伺服器上新增使用中查詢處理器服務，而不變更查詢系統其他任何部分的影響。

提示：在不同的伺服器上啟動查詢和網站設定服務的其他使用中執行個體，以在系統上的使用者負載 (以同時進行的使用者查詢數目為單位) 增加時，增加輸送量。

搜尋編目系統最佳化

一般而言，您會在使用者抱怨預期的結果不存在，或結果存在卻過時，執行搜尋編目最佳化。

當您嘗試編目新鮮度目標內的內容來源起始位址時，可能會發生下列編目效能問題：

• 編目率由於搜尋編目子系統的 IOPS 瓶頸而很低。

• 編目率由於搜尋編目子系統中缺少 CPU 執行緒而很低。

• 編目率由於存放庫回應變慢而很低。

這些問題都會造成編目率很低。請參閱＜使用搜尋管理報告 (SharePoint Server 2010)＞(指定軟體生命週期階段)，以建立系統在一段時間內的一般編目率比較基準。下列各小節顯示未達成此比較基準時，可解決這些編目效能問題的各種方式。

編目 IOPS 瓶頸

確定編目資料庫或屬性資料庫是瓶頸之後，您必須使用適當的解決方式，擴充編目系統以解決此瓶頸。下表顯示新增 IOPS (其他編目資料庫) 可如何改善編目率 (直到新增更多元件再次成為瓶頸為止)。

提示：請務必檢查編目資料庫並確定其不是瓶頸。如果編目資料庫 IOPS 已成為瓶頸，新增編目元件或增加執行緒數目不會有幫助。

拓撲 (編目元件/ 編目資料庫)	CPU 百分比	RAM：緩衝區快取命中率 %	讀取延遲	寫入延遲	編目速度 (文件數/秒)
2 / 1 資料庫	19.5	99.6	142 毫秒	73 毫秒	50
4 / 2 資料庫	8.502	99.55	45 毫秒	75 毫秒	~75
6 / 2 資料庫	22	99.92	55 毫秒	1050 毫秒	~75

編目 CPU 執行緒瓶頸

如果具有大量主機且沒有其他編目瓶頸，則必須使用適當的解決方式，擴充編目系統。編目程式每個 Search Service 應用程式最多可容納 256 個執行緒。建議使用四核心處理器，以充分利用執行緒數目上限的優點。如果確定存放庫提供資料的速度夠快 (請參閱本文稍後的＜存放庫的編目瓶頸＞一節)，則可以增加編目輸送量，方法是透過增加編目程式執行緒數目，來要求存放庫更快地提供資料。使用下列三個方法可以完成此作業：

1. 使用下列 Windows PowerShell Cmdlet，將索引器效能層級變更為 [部分降低] 或 [最大值]：

   • Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel “Maximum”

     如果使用的處理器核心數目少於四個核心，則會使用最大值。

2. 使用編目程式影響規則，增加每部主機的執行緒數目。請注意，最多支援 256 個執行緒；此外，將大量執行緒指定給少數主機可能會導致從其他存放庫擷取資料的速度變慢。

3. 如果有大量主機，理想的解決方法是在不同的索引器上新增另一個編目元件，來編目需要更快編製索引的主機。

如果搜尋子系統的 IOPS 未遇到瓶頸，且存放庫提供內容的速度很快，則順暢地增加編目輸送量的最佳作法是新增其他索引器。

存放庫的編目瓶頸

有時候，對含有許多巢狀網站集合或遠端檔案共用的 SharePoint Web 應用程式進行編目時，搜尋編目程式可能會成為存放庫的瓶頸。如果下列兩個情況成立，即為存放庫瓶頸：

• 編目伺服器上的 CPU 使用率很低 (低於 20%)。

• 網路上有大量執行緒 (幾乎全部都是最糟的情況) 等候中。

  檢視 OSS Search Gatherer/Threads Accessing Network 效能計數器可識別此瓶頸。

此情況表示在等候存放庫中的資料時，執行緒遭到鎖定。在具有多個內容來源的環境中，識別回應很慢的主機可能會很有用，方法是暫停其他所有編目，然後再使用具有可疑主機之內容來源作為其中一個起始位址執行編目。

識別有問題的主機之後，必須調查回應時間變慢的原因。針對 SharePoint 內容，請參閱＜Capacity management and sizing for SharePoint Server 2010＞一文。

調整編目資料存放庫的效能，即可大幅改善編目輸送量。

效能和縮放問題的疑難排解

請務必了解伺服器陣列上的負載，再開始對效能進行疑難排解。下一節使用含有 6 千萬筆項目之即時伺服器陣列中的資料，來顯示不同搜尋生命週期階段的各種系統評量值。

搜尋生命週期期間的效能範例

評量值	索引擷取	索引維護	索引清理
SQL Server CPU (%) 屬性資料庫 / 編目資料庫	14.8 / 19.13	35 / 55	11 / 63
SQL Server page life expectancy 屬性資料庫 / 編目資料庫	60,548 / 5,913	83,366 / 5,373	33,927 / 2,806
SQL Server average disk sec/ write 屬性資料庫 / 編目資料庫	9 毫秒 / 48 毫秒 最大值：  466 毫秒 / 1,277 毫秒	12 毫秒 / 28 毫秒	20 毫秒 / 49 毫秒 最大值：  253 毫秒 / 1156 毫秒
SQL Server average disk sec/ read 屬性資料庫 / 編目資料庫	8 毫秒 / 43 毫秒 最大值：  1,362 毫秒 / 2,688 毫秒	11 毫秒 / 24 毫秒	24 毫秒 / 29 毫秒 最大值：  2,039 毫秒 / 2,142 毫秒
編目程式 CPU (%) 索引伺服器 1 (2 個編目元件) / 索引伺服器 2 (2 個編目元件)	18 / 11	25.76 / 21.62	8.34 / 7.49 最大尖峰量為 99%
Disk Writes/Sec 索引伺服器 1 (2 個編目元件) / 索引伺服器 2 (2 個編目元件)	64.32 / 42.35	93.31 / 92.45	99.81 / 110.98
Disk reads/sec 索引伺服器 1 (2 個編目元件) / 索引伺服器 2 (2 個編目元件)	0.23 / 0.20	4.92 / 2.03	1.38 / 1.97
Average disk sec/ write 索引伺服器 1 (2 個編目元件) / 索引伺服器 2 (2 個編目元件)	11 毫秒 / 11 毫秒	1 毫秒 / 2 毫秒	5 毫秒 / 4 毫秒 最大值：  1,962 毫秒 / 3,235 毫秒
Average disk sec/ read 索引伺服器 1 (2 個編目元件) / 索引伺服器 2 (2 個編目元件)	1 毫秒 / 2 毫秒	12 毫秒 / 11 毫秒	10 毫秒 / 16 毫秒 最大值：  2,366 毫秒 / 5,206 毫秒

查詢效能問題的疑難排解

SharePoint 搜尋具有檢測查詢管道及相關聯的管理報告，可協助您對伺服器查詢效能問題進行疑難排解。如需詳細資訊，請參閱＜使用搜尋管理報告 (SharePoint Server 2010)＞。本節顯示這些報告，然後以此協助了解如何對伺服器問題進行疑難排解。此外，本節也包含可協助解決用戶端 (瀏覽器) 效能問題的工具和指導。

伺服器查詢問題

伺服器查詢效能問題可分為下列兩個層級：

• 搜尋前端效能問題

• 搜尋後端效能問題

下列兩小節提供對這兩種問題進行疑難排解的詳細資料。請注意，這是概略指導方針。

前端效能問題

疑難排解前端效能的第一步是檢閱「整體查詢延遲」搜尋管理報告。以下是範例報告：

在此報告中，前端效能會以下列資料序列表示：

• 伺服器轉譯：此值表示在前端網頁伺服器上的各種搜尋網頁組件中，每種查詢所需的平均時間 (分鐘)。

• 物件模型：此值表示前端網頁伺服器與搜尋後端之間通訊所需的平均時間 (分鐘)。

伺服器轉譯問題的疑難排解

提供搜尋結果頁面之前端網頁伺服器上所發生的任何情況，都會影響伺服器轉譯問題。一般而言，您需要了解擷取各種網頁組件所需的時間，以找出要增加額外延遲的位置。啟用搜尋結果頁面上的開發人員儀表板 (可能為英文網頁)，以取得詳細的延遲報告。顯示伺服器轉譯延遲過多的常見問題包括：

• 下列平台問題：

  • Active Directory 查閱速度很慢

  • SQL Server 執行時間很長

  • SharePoint Server 2010 的人員查詢或 FAST Search Server 2010 for SharePoint 的所有查詢中，對使用者設定檔應用程式的要求很慢

  • 擷取使用者喜好設定的要求很慢

  • 呼叫以從 Secure Token Service 中取得使用者 Token 的速度很慢

• 程式碼後置問題，例如已存回修改後的搜尋結果頁面 (如 results.aspx 和 peopleresults.aspx)，但尚未發佈。

物件模型問題的疑難排解

物件模型問題可能受到下列因素的影響：

• Windows Communication Foundation (WCF) 層發生問題，例如：

  • 部署中的 WCF 呼叫發生逾時和 threadabortexception。

  • 前端網頁伺服器與應用程式伺服器之間的通訊很慢。這可能是由於 IPsec 問題或低速網路連線所致。

• 內容與服務伺服器陣列之間的通訊發生問題 (設定時)。

後端效能問題

疑難排解後端查詢效能的第一步是檢閱「SharePoint 後端查詢延遲」搜尋管理報告。以下是範例報告：

在此報告中，後端效能會以下列資料序列 (每個序列是每個查詢所需的平均時間 (分鐘)) 表示，並依功能元件群組：

• 查詢元件：

  • 全文查詢：查詢結果的全文檢索索引所需的平均時間。

• 屬性資料庫：

  • 多重結果擷取：擷取將在查詢結果中出現之文件中繼資料 (例如標題或作者) 所需的平均時間。

  • 屬性儲存區查詢：查詢屬性資料庫以進行屬性式查詢所需的平均時間。

• 搜尋管理資料庫：

  • 首選：判斷查詢字詞是否有「首選」可用所需的平均時間。

  • 高度信賴結果：擷取查詢之高度信賴結果所需的平均時間。

• 查詢處理器：

  • 安全性調整：移除使用者無權存取之項目所需的平均時間。

  • 移除重複：移除重複項所需的平均時間。

  • 填入結果：建立要回傳給物件模型之記憶體內部表格所需的平均時間。

查詢元件效能問題的疑難排解

查詢元件需要大量資源，特別是使用元件時 (例如回應查詢要求)。疑難排解查詢元件效能是搜尋中較複雜的一部分。以下是一般考量：

• 需要最多資源的查詢元件事件是主要合併，主要合併會合併陰影索引和主要索引。每個查詢元件會個別發生此事件。您可以在本文稍早所述的「SharePoint 後端查詢延遲」報告中，於下午 1:30 之前的時段內看見此影響範例。如果此事件影響查詢延遲，除非變更的百分比超出定義的限制，否則您可以定義停機時段，以避免在這段時間發生主要合併事件。

• 您可能應該執行下列動作，以確保環境中有夠高的值：

  • 檢查伺服器上每個元件的索引大小。確定伺服器上有足夠的 RAM，以允許快取約 33% 的索引大小總計。

  • 檢查伺服器上的查詢元件 IO 通道。確定未遇到 IO 瓶頸。

  • 如果 IO 和 RAM 不是效能問題的來源，您應該重新分割查詢元件 (新增索引分割區)，並將其他查詢元件向外延展至新伺服器。

屬性資料庫問題的疑難排解

使用＜規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)＞中的概念檢查 SQL Server 狀況。如果執行自訂查詢，可能需要檢視提示，以引導修正查詢計劃。

搜尋管理資料庫問題的疑難排解

使用＜規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)＞中的概念檢查 SQL Server 狀況。

查詢處理器問題的疑難排解

查詢處理器問題的疑難排解，取決於下列哪一部分的查詢處理器會影響查詢延遲：

• 安全性調整：

  • 若是 Windows 宣告，請檢查 Active Directory 與主控查詢處理器之伺服器的連線。

  • 在所有情況下，如果大量 SQL Server 來回之間相互關聯 (由 SQL Server Profiler 來決定)，查詢處理器所使用的快取大小會增加。25% 以上的查詢不需要 SQL Server 呼叫，即可從搜尋管理資料庫中擷取安全性描述元。如果需要，請調整查詢處理器快取大小。

• 移除重複：

  • 查看您是否編目多個位置的相同內容。停用搜尋中心的重複資料偵測。

• 多重結果擷取：

  • 使用＜規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)＞中的概念檢查 SQL Server 狀況。

瀏覽器查詢問題

使用者對搜尋結果的速度可能會感到滿意，也可能會抱怨連連。頁面載入時間是使用者對搜尋經驗是否滿意的其中一個重要因素。頁面載入時間的關注要點在於伺服器端，特別是伺服器傳回結果的時間。但是，用戶端轉譯也可能佔用大量頁面載入時間，因此值得考量。

搜尋使用者經驗的設計目的，是為了提供頁面載入總時間小於一秒的回應。除了該時間之外，根據瀏覽器和轉譯測量，用戶端轉譯一般需要 280 毫秒以下的時間。此經驗提供很快的結果，因此使用者普遍感到滿意。

自訂結果經驗很容易降低轉譯效能。搜尋管理員和開發人員必須在每次修改後謹慎測量轉譯時間，以確保效能不致大幅降低。每次新增項目 (從新網頁組件到新階層式樣式表的樣式) 至頁面，都會增加瀏覽器的轉譯時間，並延遲向使用者顯示結果。然而，延遲時間會隨您在自訂頁面時，是否遵循最佳作法而有顯著差異。

以下是一些通用準則：

• 頁面的基本商標和樣式自訂不應增加頁面載入時間超過約 25 毫秒。請在實作自訂前後測量頁面載入時間，以觀察變更。

• 如果增加 20%，使用者一般會注意到變更 (變快或變慢)。變更時，請記住這點。20% 的標準轉譯時間只有 50 毫秒 (資料來源：設計及規劃時間 (可能為英文網頁))。

• 階層式樣式表和 JScript 是影響轉譯效能的兩個最常見且嚴重的問題。如果您必須自訂階層式樣式表和 JScript，請儘量各使用一個檔案。

• JScript 可以在頁面轉譯後視需要載入，以更快提供使用者可見的結果。如需如何執行這項操作的詳細資訊，請參閱效能考量一文中的討論。

• 新增至頁面的自訂愈多，載入速度愈慢。請考慮新增功能和樣式，是否值得讓使用者延遲更久才看見結果。

除了這些準則之外，網際網路上還提供有關如何減少頁面載入時間，以及頁面載入緩慢對使用者經驗之影響的大量資訊。

編目效能問題的疑難排解

當系統進行索引擷取、維護及刪除階段時，SharePoint 搜尋可能會在編目子系統中遇到瓶頸。若要有效疑難排解編目效能問題，請搭配使用「搜尋狀況監視」報告和本文稍後的＜常見瓶頸及其原因＞一節，以找出編目問題。

在索引擷取階段中進行疑難排解

識別編目問題的第一個位置是「每個內容來源的編目率」狀況報告。如本文稍後所述，此報告提供系統中每個內容來源的編目率概觀。一般而言，人員內容來源的編目率應該超過 15 份文件/秒，而其他所有類型的內容來源則應該超過 35 份文件/秒。

如果發現某項內容來源的編目率較差，建議採取下列步驟：

1. 除了正在調查的內容來源以外，暫停其他所有編目。編目率是否從指定的 15 份文件/秒提升到 35 份文件/秒的目標？

2. 如果以上步驟沒有用，則請確保編目的存放庫適當回應，且不是編目緩慢的原因。請參閱本文稍早的＜存放庫的編目瓶頸＞一節。

3. 如果存放庫不是瓶頸，請識別編目伺服器或資料庫伺服器中的瓶頸，並予以最佳化。本文稍早的＜編目 IOPS 瓶頸＞和＜編目 CPU 執行緒瓶頸＞小節中，可以找到相關指引。

在索引維護階段中進行疑難排解

索引維護階段的主要目標在於儘可能更新索引。其中兩個重要指標為：

• **索引新鮮度：**編目是否在預定時間內完成，並符合索引新鮮度的 IT 準則？

• **累加編目速度：**如果未達成索引新鮮度目標，請調查人員內容來源的累加編目速度是否為 10 份文件/秒，以及其他所有內容來源是否為 35 份文件/秒。如果累加編目速度較差，應該如上所述對編目存放庫和編目子系統執行瓶頸分析。

常見瓶頸及其原因

在效能測試期間，會發現幾個不同的常見瓶頸。瓶頸是伺服器陣列特定區域的容量已滿的情況。這會導致伺服器陣列輸送量停滯或降低。

下表列出一些常見的瓶頸，並說明其原因和潛在解決方式。

瓶頸	徵狀 (效能計數器)	解決方式
資料庫 RAM	屬性資料庫、 搜尋管理資料庫顯示： SQL Server buffer manager/ page life expectancy < 300(s) (應該為 > 1000 (s)) SQL Server buffer manager/ buffer cache hit ratio < 96% (應該為 > 98%)	增加資料庫伺服器的記憶體。 如果已停用每週磁碟重組規則，則重組屬性資料庫。 確定使用 SQL Server 2008 Enterprise Edition 啟用頁面壓縮。 將資料庫移至其他伺服器，並視需要新增多個屬性資料庫。
資料庫伺服器 IOPS	屬性資料庫或編目資料庫顯示： Average disk sec/read 和 Average Disk sec/write ~50 毫秒或 > 50 毫秒	確定資料庫伺服器具有足夠的 RAM，可在快取中保留 33% 的重要表格 (MSSDocSDIDs + MSSDocProps + MSSDocresults)。 執行下列動作，以增加資料庫的專屬 IOPS 數目： 使用不同的存放裝置陣列 最佳化儲存設定；例如，將主軸 (磁碟機) 新增至存放裝置陣列。 執行 SharePoint Health Analyzer 的 [搜尋 - 一個或多個屬性資料庫有分散的索引] 規則 (如果已停用)。 執行 SharePoint Health Analyzer 的 [搜尋 - 一或多個編目資料庫可能含有分散的索引] 規則。 確定使用 SQL Server 2008 Enterprise Edition 啟用頁面壓縮。 將資料庫移至其他伺服器，並視需要新增多個屬性資料庫及 (或) 編目資料庫。
查詢元件 IOPS	用於查詢元件之索引的邏輯磁碟顯示： Average Disk sec/read 和 Average disk sec/write ~30 毫秒或 > 30 毫秒，持續一段時間 (亦即一天當中的大多時候；而不只是索引合併期間)。	確定每部應用程式伺服器具有足夠的 RAM，可在快取 (作業系統快取) 中保留每個使用中查詢元件之索引 (該伺服器上) 的 33%。 執行下列動作，以增加查詢元件的索引所使用之磁碟機的專屬 IOPS 數目： 針對不同的元件使用不同的存放裝置陣列。 最佳化儲存設定；例如，將主軸 (磁碟機) 新增至存放裝置陣列。

關於作者

Brion Stone 是 Microsoft SharePoint Server 搜尋的資深方案經理。