Linux性能優化:性能追蹤方法

Blog:博客園 我的服務器

記錄

在調查性能問題時,你能夠作的最重要的事情大概就是記錄下看到的每個輸出、執行的每一條命令,以及研究的每個信息。結構清晰的記錄能讓你只查看記錄就能夠檢驗關於性能問題緣由的猜測,而不是從新運行測試。這能節約大量時間。寫下來而且建立性能記錄。工具

每一步操做、每一個輸出結果,能夠直接截圖或者複製保存在文檔,便於後期對比分析。性能

以腳本代替手動輸入

使用腳本自動執行,能夠節省時間,並有助於避免因不當工具和測試調用形成的誤導性信息。測試

舉個例子,你想在特定工做負載下或某段時間內監控系統,可是在測試結束時,你可能不在現場。這種狀況下,腳本就很好用了,在測試完成時,能夠自動收集、命名、保存所有生成的性能數據,並將它們自動放到「Results」目錄中。有了這些基礎以後,你就能按照不一樣的優化和調整從新運行測試,而且不用擔憂數據是否已經保存好。你反而能夠集中精力找出問題的緣由,而不是去管理測試結果。優化

選擇低開銷的工具

使用工具觀察性能變化的同時,也會佔用系統的資源,因此儘可能選擇低開銷的工具來下降對系統的影響。搜索引擎

有些性能工具可以給出高度精確的系統信息,但其檢索信息的開銷也很高。高開銷工具對系統行爲帶來的變化大於低開銷工具。若是你只須要了解系統的粗略信息,那麼使用低開銷的工具是更好的選擇,即便它們不夠準確。blog

同時使用多個工具

雖然在找出性能問題緣由的時候,若是隻須要用一個工具那將是很是方便的,但這種狀況至關少見。實際上,你使用的每一種工具都會爲問題的緣由提供線索,所以,你必須同時使用多個工具來真正搞清楚發生了什麼。好比,一種性能工具會告訴你係統存在大量的磁盤I/O,而另外一種工具則告訴你係統使用了大量的交換。若是隻以第一個工具的結論制定解決方案,你可能會簡單地選擇更快的磁盤驅動器(而後發現性能問題僅僅改善了一點點)。而將兩種工具的結果放在一塊兒,你就會判斷出:大量的磁盤I/O是由大量使用的交換形成的。在這種狀況下,你可能會買更多的主存以減小交換(這樣就不會再有大量的磁盤I/O)。索引

肯定指標和基線

明確性能峯值有助於你設置合理的性能指望值,並能給你一個性能目標,這樣你就知道什麼時候應該中止優化。你可能老是沒有目標地時不時對系統作一點調整,這會浪費大量的時間,只爲獲得一些額外的性能,即便你可能並不真的須要它們。資源

要想知道何時結束優化,你必須爲系統自行確立或是使用已發佈的指標。指標是一種客觀的度量,用於指示系統的執行狀況。例如,若是你要優化一個Web服務器,你就能夠選擇「每秒服務的Web請求數」。若是你沒有一個客觀的途徑來度量性能,那麼在調整系統的時候,你幾乎沒法肯定是否取得了進展。開發

在調整和優化以前,運行應用程序並記錄其性能,這就是基線值,它是性能調查的起點。

追蹤近似問題

經過初始的粗略嘗試,你能對問題造成大體的見解。這個簡單切口的目的就是收集足夠的信息傳遞給程序的其餘用戶和開發者,以便他們提出意見和建議。這裏很是重要的一點是要有良好的書面記錄來解釋你認爲問題是怎樣的,以及什麼樣的測試使你得出了這個結論。

查看問題是否早已解決

經過搜索引擎(谷歌、百度或國內常見的技術博客平臺,好比博客園、CSDN等)查找類似的錯誤信息/問題。

Web搜索經常會揭示不少與應用程序以及你正在查找的具體錯誤狀況相關的信息。它們還能夠指向其餘用戶所嘗試的系統優化,還可能提示哪些有做用、哪些沒有做用。成功的搜索能夠產生好幾頁可以直接用於你的性能問題的信息。

分離問題

若是可能的話,刪去任何運行於被調查系統的多餘的程序或應用。運行許多不一樣應用程序的系統,其負載較重,會影響性能工具收集信息的準確性,並最終將你引導到錯誤的方向。

一次只改變一件事

這點很是重要。要真正肯定問題出在哪兒,一次只能有一個變化。這可能會很花時間,並讓你運行多個不一樣的測試,但它的確是發現你是否解決了問題的惟一途徑。

始終在優化後從新測量

若是你稍稍調整了系統,那麼在調整後對全部的事情從新進行測量是很重要的。當你開始修改系統配置時,全部以前生成的性能信息可能再也不有效。一般,在你解決一個性能問題時,別的問題會隨之而來。新問題可能與老問題有着極大的不一樣,所以,你真的須要從新運行性能工具來確保正在調查的問題沒有出錯。

相關文章
相關標籤/搜索