系統瓶頸分析舉例

　　系統瓶頸分析舉例  軟件測試

　　經驗舉例1

　　交易的響應時間如果很長，遠遠超過系統性能需求，表示耗費CPU的數據庫操作，例如排序，執行aggregate functions(例如sum、min、max、count)等較多，可考慮是否有索引以及索引建立的是否合理;盡量使用簡單的表聯接;水平分割大表格等方法來降低該值。

　　經驗舉例2

　　分段排除錯誤。測試工具可以模擬不同的虛擬用戶來單獨訪問Web服務器、應用服務器和數據庫服務器，這樣，就可以在Web端測出的響應時間減去以上各個分段測出的時間就可以知道瓶頸在哪并著手調優。

　　經驗舉例3

　　UNIX資源監控(NT操作系統同理)中指標內存頁交換速率(Paging rate)，如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。也可能是內存訪問命中率低?！癝wap in rate”和“Swap out rate”也有類似的解釋。

　　經驗舉例4

　　UNIX資源監控(NT操作系統同理)中指標CPU占用率(CPU utilization)，如果該值持續超過95%，表明瓶頸是CPU.可以考慮增加一個處理器或換一個更快的處理器 .合理使用的范圍在60%至70%.

　　經驗舉例5

　　UNIX資源監控(NT操作系統同理)中指標磁盤交換率(Disk rate)，如果該參數值一直很高，表明I/O有問題?？煽紤]更換更快的硬盤系統、重新部署業務邏輯等，另外設置Tempdb in RAM，減低"max async IO"，"max lazy writer IO"等措施都會降低該值。

　　經驗舉例6

　　Tuxedo資源監控中指標隊列中的字節數(Bytes on queue)，隊列長度應不超過磁盤數的1.5~2倍。要提高性能，可增加磁盤。注意：一個Raid Disk實際有多個磁盤。

　　經驗舉例7

　　SQLServer資源監控中指標緩存點擊率(Cache Hit Ratio)，該值越高越好。如果持續低于80%，應考慮增加內存。注意該參數值是從SQL Server啟動后，就一直累加記數，所以運行經過一段時間后，該值將不能反映系統當前值

原文轉自：http://www.anti-gravitydesign.com