效能與容量監視 (FAST Search Server 2010 for SharePoint)

發行項
03/07/2017

適用版本： FAST Search Server 2010

上次修改主題的時間： 2015-03-09

在監視 Microsoft FAST Search Server 2010 for SharePoint 部署的效能及容量時，有兩種主要的分析區域：

編目及索引效能分析
查詢效能分析

如需如何監視 FAST Search Server 2010 for SharePoint 伺服器陣列的一般詳細資訊，請參閱＜監視 FAST Search Server 2010 for SharePoint＞。如需如何監視 Microsoft SharePoint Server 2010 伺服器陣列的完整詳細資訊，請參閱＜監視及維護 SharePoint Server 2010＞。

如需 FAST Search Server 2010 for SharePoint 相關的效能計數器概觀，請參閱＜效能計數器 (FAST Search Server 2010 for SharePoint)＞。

注意

本文假設您使用 SharePoint Server 2010 編目程式、索引連接器架構及 FAST Search Server 2010 for SharePoint 內容 Search Service 應用程式 (內容 SSA) 編目內容。

編目及索引效能分析

內容處理鏈

FAST Search Server 2010 for SharePoint 的項目處理鏈是由下列可能在個別伺服器上執行的元件所組成：

編目程式 為將內容推送至 FAST Search Server 2010 for SharePoint 的任何元件
內容散發者 會批次接收內容並將批次分散至項目處理及索引
文件處理器 (項目處理) 會將項目轉換為統一內部格式
索引發送程式 會將處理過的項目批次分散至索引資料欄
主要索引器 會產生可搜尋的索引
備份索引器 會保留主要索引器中資訊的備份

如項目處理鏈圖中由箭號 1–5 表示出的內容流程。從主要到備份索引器的最後一個流程是選用的部署選擇。已完成處理的非同步回呼會傳播至其他方向，如箭號 6 到 9 所表示。編目程式會依據其接收的文件批次 (1) 回呼 (9) 來節流編目率。整體的編目率是取決於此鏈中最慢的元件。

每個 FAST Search Server 2010 for SharePoint 伺服器陣列有一或多個內容散發者。這些元件會批次接收所有內容，然後傳遞至項目處理元件。若要確保效能良好，您可確認下列條件是否符合：

有效使用項目處理元件
傳入的內容批次能快速分散以利處理

當內容 SSA 具有要提交的批次之持續佇列時，您才可封存最大輸送量。在忙碌時，每個項目處理元件會使用 100% 的 CPU 核心。您可將項目處理元件擴充為每一個元件使用一個 CPU 核心。

索引器是 FAST Search Server 2010 for SharePoint 安裝中最需要大量寫入的元件，因此您必須確保高度的磁碟效能。當大量索引活動在與查詢比對作業相同的資料列上執行時，亦可能影響查詢比對作業。索引器會將項目分散至多個分割區。分割區 0 與其他三個分割區可以同時持續進行活動。在分割區間的項目重新分散期間，一或多個分割區可能會等待其他分割區達到特定檢查點。

提示

編目與索引效能的分析可利用多項工具來執行；例如，Windows Server 2008 [R2] 或 Systems Center Operations Manager (SCOM) 的「效能監視器」。此外，您還可使用 indexerinfo 命令來擷取索引器狀態，例如 indexerinfo -a status。

編目效能計數器

下表顯示內容 SSA 最重要的效能計數器。請注意，您可在主控內容 SSA 編目元件的伺服器上找到這些效能計數器 (在「OSS Search FAST 內容外掛程式」底下)，而不是在 FAST Search Server 2010 for SharePoint 伺服器陣列中。

效能計數器	描述
Batches ready	內容 SSA 從內容來源擷取的批次數目，且已準備好傳遞給內容散發者。當為零時，FAST Search Server 2010 for SharePoint 伺服器陣列後端處理內容的速度會比內容 SSA 編目的速度更快。
Batches submitted	內容 SSA 已傳送至 FAST Search Server 2010 for SharePoint 而回呼仍在等候中的批次數目。當為零時，就不會傳送任何項目至 FAST Search Server 2010 for SharePoint 伺服器陣列後端處理。
Batches open	某階段處理的批次總數
Items Total	內容 SSA 在上一個服務重新啟動時所編目的項目總數。
Available Mbytes	電腦上可用的記憶體總量。依預設，當使用了 80% 的系統記憶體時，內容 SSA 就會停止彙總 batches ready
Processor time	電腦的整體 CPU 使用量。高 CPU 負載可能會限制內容 SSA 的輸送量。
Bytes Total/sec	電腦的整體網路使用量。高網路負載可能會成為內容 SSA 編目資料及將資料推送至 FAST Search Server 2010 for SharePoint 伺服器陣列的速率瓶頸。

內容散發者及項目處理效能計數器

下表顯示內容散發者及項目處理的效能計數器。若要取得系統的完整概觀，您必須將所有內容散發者的這些效能計數器彙總起來。

效能計數器	描述
Document processors	向每個內容散發者登錄的項目處理元件數目。當有多個內容散發者時，項目處理元件會平均分散至內容散發者。
Document processors busy	目前正在內容批次上運作的項目處理元件數目，這應該與最大負載下的項目處理元件總數接近。
Average dispatch time	內容散發者用以將批次傳送至項目處理元件所需的時間，這應該小於 10 毫秒；較高的值則表示網路壅塞。
Average processing time	項目處理元件用以處理批次所需的時間，這個時間可能依據不同內容類型與批次大小而有差異，不過通常都小於 60 秒。
Available Mbytes	電腦上可用的記憶體總量。每個項目處理元件可能需要最多到 2GB 的記憶體。記憶體耗盡將會影響處理輸送量。
Processor time	電腦的整體 CPU 使用量。項目處理元件需要大量 CPU。一般而言，在編目期間，CPU 使用率較高，但項目處理會降低優先順序，並在需要時將 CPU 資源讓出。
Bytes Total/sec	電腦的整體網路使用量。高網路負載可能會成為 FAST Search Server 2010 for SharePoint 伺服器處理資料的速率瓶頸。

索引發送程式及索引器效能計數器

下表顯示索引發送程式及索引器最重要的效能計數器。

效能計數器	描述
Current queue size	傳入的索引器佇列在高負載情況下工作，這是一種常態，尤其在局部更新時更是如此。若 API 佇列從未 (間歇性) 達到零，則索引器是瓶頸。當其中一個索引器的佇列達到 256MB 時，編目程式會暫停。而這通常會在儲存裝置子系統不夠強大時發生，也會在分割區間的內容大量重新分散期間發生，這會暫時封鎖更多內容不讓其被編製索引。
FiXML fill rate	依預設，會在每天凌晨 3 到 5 點間定期壓縮 FiXML 檔案 (索引器中的內部項目存放區)。低 FiXML fill rate (<70%) 會導致作業效率低落。
Active documents	分割區 0 及 1 都應少於一百萬個項目，最好更少，才能維持低索引延遲。在高項目輸送量期間，索引延遲會較高，這是為了達到整體輸送量的最佳化，所以分割區 0 和 1 將會比較大。在輕量負載期間，查詢比對元件會自動將項目重新排列至編號較高的分割區。
% Idle Time	低磁碟閒置時間表示儲存裝置子系統飽和。
% Free space	索引器在下列兩個部分需要空間：查詢比對元件目前所用的索引產生及正在處理中之新的索引產生。在完全負載的系統中，相同數目的項目，其磁碟使用量可能會介於 40% 到接近 100% 之間，而這是取決於索引器的狀態而定。

查詢效能分析

SharePoint Server 2010 管理報告會從端對端的角度，提供實用的查詢效能統計資料。若您要追蹤一段時間的趨勢及識別效能未達最佳化時該調查何處，這些報告都非常有效。

查詢延遲可能發生在三個不同區域：Web 伺服器轉譯、查詢 SSA 處理及後端處理。一般而言，由 Web 伺服器頁面轉譯及查詢 SSA 導致的延遲，會發生在執行 SharePoint Server 2010 (查詢 SSA) 的伺服器上。這些延遲也會取決於備份 SharePoint Server 2010 安裝的 SQL Server 效能。後端延遲會在 FAST Search Server 2010 for SharePoint 的下列伺服器中：

查詢處理
查詢比對

查詢是從查詢 SSA 傳送到 FAST Search Server 2010 for SharePoint 查詢處理元件 (部署檔案中的 "query")。在報告中，查詢處理會顯示為 “QRproxy”、“QRserver” 及 “Fdispatch”。查詢 SSA 及查詢處理元件有可能代表瓶頸。其兩者間的差異是由通訊延遲或查詢處理所導致。

查詢發送程式 (報告中的 "Fdispatch") 會將查詢分散至各索引資料欄。每個查詢比對伺服器上亦有一個查詢發送程式，以將查詢分散至索引分割區。當查詢結果中有大量資料時，兩者的查詢發送程式都可能是瓶頸。這會導致網路壅塞。因此，建議您在查詢處理及查詢比對元件間，使用個別的網路交換器。

查詢比對元件 (報告中的 "Fsearch") 是負責執行查詢與索引的實際比對、計算查詢相關性及執行深入的精簡搜尋。對每個查詢而言，其會從索引器產生的索引來讀取必要的資訊，而可能會重複使用的資訊就會儲存在記憶體快取中。良好的查詢比對效能是仰賴於強大的 CPU 及小型隨機磁碟讀取 (通常是 16-64 kB) 的低延遲。

查詢處理效能計數器

下表顯示對查詢 SSA 及查詢處理元件報告的後端延遲相互關聯有所助益的效能計數器。

效能計數器	描述
# Queries/sec	目前的每秒查詢數目。
# Requests/sec	目前的每秒要求數目。除了查詢負載以外，每秒會接收一個內部要求，以查看 QRserver 是否運作。
Average queries per minute	Average query load
Average latency last - ms	平均查詢延遲
Peak queries per sec	尖峰查詢負載

查詢比對效能計數器

下表顯示對執行查詢比對元件伺服器之分析有所助益的效能計數器。

效能計數器	描述
% Idle Time	低磁碟閒置時間表示儲存裝置子系統飽和。
Avg. Disk sec/Read	每個查詢都需要一系列的磁碟讀取。而平均讀取延遲最好小於 10 毫秒。
Avg. Disk Read Queue Length	在飽和的磁碟子系統中，會建立讀取佇列，而佇列會影響查詢延遲。任何執行查詢元件的伺服器，其平均佇列長度最好都小於 1。但通常在編製索引期間，單一資料列部署中的這個佇列都會超過 1，這可能會影響搜尋成效。
Processor time	高查詢輸送量的 CPU 使用率有可能會成為瓶頸。當查詢比對有大量處理器時間 (接近 100%)，則查詢輸送量就無法再增加。