如何調查瓶頸

本主題說明如何調查瓶頸的建議程序。

問題根源為何？

問題根源可能與硬體或軟體相關。 未充分利用資源通常表示系統中某處發生瓶頸。 造成瓶頸的可能原因是硬體限制或無效率的軟體組態或兩者。

識別瓶頸是一項遞增程序，解決一個瓶頸，可能導致下一個瓶頸被發現。 識別和解決瓶頸的技術是本主題的目標。 系統在短時間內處於尖峰執行狀態，這種情形有可能發生。 不過，對持續性輸送量來說，系統最快只能用其最慢執行元件的速度處理。

使用循序方法

瓶頸可能在系統端點 (進入點/結束點) 或中間某處 (協調流程/資料庫) 發生。 在分離出瓶頸位置之後，可以採取結構化方式識別問題根源。 在解決瓶頸之後，請務必再次測量效能，確保系統後面的其他位置未傳入新瓶頸。

識別和解決瓶頸的程序應該是循序方法，即每次只應變動一個參數，接著測量效能，驗證該單一變更的影響。 同時變動多個參數可能會掩蓋此變更的作用。

例如，變更參數 1 可能改進效能，但同時變更參數 1 和參數 2 可能會有否定變更參數 1 之結果的不利影響，因此導致淨效果為零。 然而，其結果則為漏報 (False Negative) 變更參數 1 的影響，以及誤報 (False Positive) 變更參數 2 的影響。

測試一致性

在變更設定之後，請務必測量效能特性，驗證變更的影響。

• 硬體：請務必使用一致的硬體，因為不同硬體可能會顯示不一致的行為，因而產生誤導的結果，例如不要使用膝上型計算機。

• 測試回合持續時間：也請務必測量固定最小期間的效能，以確保結果確實持續，而不只是尖峰。 長時間執行測試的另一個原因，是為了確保系統經歷初始的暖機/突發量期間，所有快取都能填入、資料庫資料表達到預期計數、有充分時間可以啟動節流，並在達到預先設定的閾值時立即調整輸送量。 這種方法有助於探索最佳、持續性輸送量。

• 測試參數：也請務必不要將測試參數從測試回合變更為測試回合。 例如，變更對應的複雜性和 (或) 文件大小，可能會產生不同的輸送量和延遲結果。

• 清除狀態：測試完成後，在執行下一次測試回合之前，請務必清除所有狀態。 例如，歷程記錄資料可能會在資料庫中增加，因此影響執行階段的輸送量。 回收服務執行個體有助於釋出快取資源，如記憶體、資料庫連線和執行緒。

預期：輸送量與延遲

部署的系統有特定輸送量和 (或) 延遲是合理預期。 嘗試產生高輸送量和低延遲就像是往兩個不同方向拉扯。 然而，最佳輸送量和合理延遲是比較符合現實的預期。 當輸送量提高時，會對系統造成更大的壓力 (CPU 高使用量、磁碟 IO 高爭用量、記憶體壓力、高鎖定爭用量)，因此對延遲造成負面影響。 若要探索系統的最佳容量，一定要識別和解決所有瓶頸。

瓶頸可能是因為舊版數據 (已完成的實例所造成，) 在資料庫中未清除。發生這種情況時，效能可能會降低。 讓系統有充分時間來清除，有助於減輕問題。 但是，探索積存增加的原因並解決問題則更為重要。

若要探索積存的原因，請務必分析歷程記錄資料、監控「效能監視器」計數器 (以便探索使用模式並診斷積存的原因)。 在一般狀況下，每晚都會以批次方式處理大量資料。 探索系統的容量及其從積存復原的能力，有助於評估硬體需求以處理過度負載的狀況，以及系統內配合處理輸送量中非預期尖峰的緩衝區數量。

若要微調系統以產生最佳、具持續性的輸送量，便需要深入了解部署的應用程式、在特定實例中系統和使用模式的強弱項。 探索瓶頸並可靠預測最佳、具持續性輸送量的唯一方法，是透過在最符合實際執行的拓撲上進行完整測試。

本節的其他主題將引導您執行定義該拓撲的程序，並提供有關如何解決瓶頸的指導，希望有助於預先避免瓶頸。

調整大小

在部署拓撲的各個階段都可能會發生瓶頸。 有些瓶頸可藉由升級硬體來解決問題。 硬體升級有兩種方式：向上擴充 (更多 CPU、記憶體或快取) 和向外擴充 (更多的伺服器)。 要向上/向外擴充取決於遇到的瓶頸類型和設定的應用程式。 以下將指示如何根據遇到的瓶頸來變更硬體部署拓撲。 應用程式必須從頭開始建置，才能利用相應增加/相應放大。例如：

• 如果應用程式已經序列化並且相依於單一執行緒，則增加 CPU 和 (或) 記憶體將伺服器向上擴充便無助於解決問題。

• 如果更多的伺服器只不過是對無法擴充的一般資源增加爭用，則增加伺服器的向外擴充也沒有幫助。 不過，向外擴充具有其他優點。 相較於一個四處理器伺服器，部署兩個雙處理器伺服器有助於提供備援伺服器，它可提供兩個用途：擴充處理額外的輸送量以及提供高可用性的拓撲。