找出MySQL瓶颈的基准测试和剖析
????? 有些時候,我們需要優化MySQL。那我們要對MySQL進行哪些改進呢?一條特殊的query?數據庫模式?服務器硬件?唯一的辦法是測量你的系統在做什么,在各種條件下測量它的性能。這就是我們下面要學習的。
????? 最好的策略就是找出最弱的環節,并加強你的應用程序鏈的組成。這非常有用,如果你不知道什么阻止最優性能,或者以后什么將要阻止最優性能的發揮。
????? 基準測試和剖析是兩條基本的找出瓶頸的方法。它們是有關聯的,但是它們又不完全相同。基準測試你的系統的性能。這將有助于確定系統的承受能力,向你展示哪些改變有用哪些沒用,或者顯示在不同的數據下你的應用程序的性能。
?????? 相反,剖析幫助你找出你的應用程序在哪里花費了大量的時間,或者消耗了大量的資源。換句話說,基準可以回答“這種執行表現怎么樣?”,而剖析可以回答“為什么它會這個樣子執行?”
?????? 我們準備在這個章節中講述兩部分內容,基準測試和剖析。我們開始討論基準測試的原因和對策,然后引入特定的基準測試的標桿(或者尺子)。我們先向你展示如何計劃和設計基準測試,為精確的結果做設計,執行基準測試和分析結果。最后,來看看基準測試工具和如何使用它們的例子。
?????? 剩下的章節講述如何優化應用程序和MySQL。我們將會詳細地展示我們已經應用于生產幫助分析應用程序的性能,真實的優化代碼。我們也會展示怎樣記錄MySQL的query語句,分析日志,使用MySQL的狀態計數器,以及用來查看MySQL和你的query語句怎樣做的其它工具。
為什么需要基準?
????? 很多大中型的MySQL部署有專門的標桿用在基準測試里。然而,每個開發者和DBA也應該熟悉基礎的基準測試和操作,因為它們非常有用。下面是基準測試可以幫助你的一些事情:
- ?測量你的應用程序當前是怎樣執行的。如果你不知道你的應用程序當前執行多快,你不能確定哪些改變有用。你還可以用歷史基準結果,來診斷比不能預期的問題。
- 證實你系統的可擴充性。你可以用基準測試來模仿比你的生產環境能處理的多得多的負載,比如成千上百倍的增加用戶。
- 計劃增長。基準測試能幫助你評估將來你的預計負荷需要多少硬件,網絡容量和其它資源。這能在升級或者大量應用程序改變的時候,幫助減少風險。
- 測試你的應用程序在一個變化的環境里的承受能力。例如,你可以找出你的應用程序,在并發下不定時的峰值或者不同的服務器的配置的情況下,是怎樣執行的,或者你可以看到在不同的數據分布下它是怎樣處理的。
- 測試不同的硬件、軟件和操作系統配置。對于你的系統來說,是RAID5還是RAID10更好?當你從ATA磁盤切換到SAN存儲的時候,隨機寫的性能是怎樣變化的?2.4的Linux內核比2.6的更好嗎?MySQL的升級有助于提高性能嗎?對于你的數據,不同的存儲引擎有影響嗎?你可以用不同的基準來回答這些問題。
????? 對于其他目的,你也可以用基準測試,例如,為你的應用程序創建一個單元測試套件,但是在這里我們僅僅關注性能相關方面。
??? 2.基準策略
???? 有兩條基本的基準測試策略:你可以對應用程序作為一個整體,或者隔離MySQL,用基準問題測試。這兩種策略分別以全棧和單組件基準測試聞名。有以下幾點測試整個應用程序而不僅僅是MySQL:
- 你測試整個應用程序,包括web服務,應用程序代碼和數據庫。這非常有用,因為你不僅僅關注MySQL的性能,更關心整個應用程序。
- MySQL并不總是應用的瓶頸,全站基準測試可以證明這一點。
- 只有測試整個應用,你才能知道每個部分的緩存行為。
- 基準測試在某種程度上是好的,因為它反映了你的應用的真正行為,當你單獨測試某個模塊的時候,很難發現的行為。
?? 另一方面,應用程序基準測試很難創建,甚至很難正確地安裝。如果你的基準測試設計的很糟糕,你就會得出錯誤的結論,因為結果不能反映真實情況。
?? 然而,有時你不想了解整個應用。在最初階段,可能你只想了解MySQL基準測試。下面的基準測試是有用的:
- 你想比較不同的模式或者query語句
- 你想測試應用中一個特殊的問題
- 相比長篇大論的基準測試來說,你更傾向短的基準測試,能向你展示標記和測量改變的快的“循環時間”。
??? 當你在真實數據集的環境中,一次又一次的重復你的應用query語句時,基準測試MySQL是非常有用的。數據集本身和數據集的大小都必須是真實的。如果可能的話,做一個生產環境中的數據快照。
??? 不幸的是,建立一個真實的基準,是非常復雜和耗時的;如果你能得到生產環境中的數據集的復制品,算你走運。當然,這有可能是不可行的。比如,你可能開發了一個新的應用程序,只有少數的用戶和數據。如果你想知道,如果它變得龐大時,將會有什么問題發生,除了模擬更大應用數據和負載,你沒得選擇。
??? 測試什么?
??? 在你開始基準測試之前,甚至是在你設計測試之前,你需要確定你的目標。你的目標將會決定你的工具和技術,以便得到精確地有意義的結果。用問題來設計你的目標,比如“CPU是多的好嗎?”或者“新的索引是不是比現在的索引執行的更快?”
??? 它不可能是顯而易見的,這就需要你用不同的方法來測試不同的事情,例如:延遲和吞吐量需要不同的基準測試。
??? 考慮以下幾個量度和它們如何完善你的性能目標:
?? 單位時間的交易量
????這是一個經典的歷史為基準的數據庫應用程序。標準化測試,如TPC-C標準(見http://www.tpc.org)被廣泛引用,很多數據庫提供商,工作非常努力以使它們工作的好。這些基準測試在線處理(OLTP)性能,這些基準最適合多用戶交易應用程序。通常的測量單位是每秒交易量。
??? 吞吐量這個詞通常的意思是等同于單位時間內的交易量(或者工作的其它單元)。
??? 響應時間或延遲?
??? 這測量了一個任務需要的總時間。依賴你的應用,你可能需要測量毫秒,秒或者分鐘。從這里你可以得出平均響應時間,最小響應時間和最大響應時間。
??? 最大響應時間是很少有用的度量,因為基準測試運行時間越長,可能最大響應時間越大。它并不總是能重復的,這就可能會在運行的過程中拉大差距。正是因為這個原因,很多人使用百分比的響應時間。例如,如果95%的響應時間是5毫秒,你就可以知道任務可以在總時間的95%內少于5毫秒完成。
??? 畫出基準測試的結果,為圖形或者線性圖(例如,平均值和95%百分比)或者是散列圖,將是非常有幫助的,因為這樣你就可以看到結果的分布情況。通過這些圖形,可以看出在長時間運行過程中,基準測試是怎樣執行的。
?? 假設你的系統每小時做一分鐘檢測。在檢測期間,系統“拋錨”,沒有交易完成。95%的響應時間不會顯示峰值,所以結果會掩蓋這個問題。然而,一個圖形會顯示響應時間內的周期性峰值。圖2-1會闡述這點。
?? 圖2-1顯示了每分鐘的交易量。線條顯示了象征性的超過平均值的峰值。第一個峰值是因為服務器的緩存被冷凍了,另一個峰值顯示了服務器刷新臟頁穩定性到磁盤花費的時間。如果沒有圖形我們很難看到這些差異。
???穩定性
?? 對于系統來說,穩定性測試非常重要,因為系統需要在變化的工作負載下保持性能。
?? “在一個變化的工作負載下保持性能”是一個很抽象的概念。性能是可以被度量的,例如,吞吐量和響應時間;工作負載隨著數據庫大小,當前連接數,或者硬件不同,可能會存在差異。
????穩定性測試,對于評估系統承載能力來說是好的,因為它能展示出你的應用中的薄弱環節,而在其它基準測試中不會展示。
圖2-1 30分鐘運行的結果
???? 例如,在單鏈接(不好的測試策略)的情況下做響應時間測試,你設計的系統性能良好;但是在任何等級的并發下,你應用可能會表現糟糕。一個測試關注的是在不斷增加的連接下的持續響應時間,這樣才可以看到設計的瑕疵。
???? 有一些活動,例如搜集顆粒數據創建總結性數據表的周期性批量作業,僅僅需要快速響應時間。單純地測試響應時間是好的,但是也要關心他們和其它活動是怎么交互(相互影響)的。批量作業可能會導致交互的query語句表現較差,反之亦然。
????? 并發
????? 并發是很重要的,但是很多時候都被濫用和被錯誤地衡量。例如,有一種很流行的說法,有多少用戶在同時瀏覽網站。然而,HTTP是無狀態的,大多數用戶只是簡單地閱讀瀏覽器展示的內容,所以這并不能轉化為web服務器的并發。同樣地,在web服務器上的并發并不一定轉化到數據庫服務器上。有直接關聯的就是你的會話存儲機制能處理多少數據。一個更精確的測試web服務器的并發的方法是在峰值的時候,用戶每秒請求的次數。
?????? 你也可以在應用程序的不同地方測試并發。在web服務器上的并發越高,可能引起更高的數據庫并發等級。但是語言和工具套件可能影響它。例如,Java的連接池可能會比持續連接的PHP,會降低MySQL服務器的并發連接。
????? 更重要的是在一個給定時間內運行query語句的并發數量。一個很好的設計應用程序可能會打開MySQL服務器的數以百計的并發,但是其中的一少部分應該會同時執行query語句。這樣,一個“50,000用戶同時在線”的web站點,可能在MySQL服務器上只需要10~15個同時執行query語句。
????? 換句話說,你要真正關心的基準測試就是工作并發,或者線程數量,或者同時工作連接。測試當并發增加的時候,性能掉下來多少。如果是這樣的話,你的應用程序可能就無法處理高負載下的峰值。
????? 你也需要確保性能不會很快地降下來,或者設計應用程序,這樣就不會在應用程序的各個部分產生不能處理的高并發了。在通常情況下,你要設計限制MySQL服務器的并發,如應用隊列。
????? 并發不能完全等同于響應時間和穩定性:它并不是一個結果,而是你怎樣建立基準測試的一個屬性。你應該在不同的并發水平下測試應用程序的性能,而不是測試你的應用程序的能達到的并發。
????? 總之,你應該測試對用戶來說重要的東西。測試衡量性能,但是“性能”對不同的人意味著不同的東西。收集一些關于系統應當怎樣測量的需求(正式或非正式的),能接受的響應時間,期望的并發類型,等等。然后,嘗試設計你的測試來解釋所有的需求,而不是“井底之蛙”排除其他東西關注某項東西。
????? 3.測試標桿
??????在有個大致了解的情況下,讓我們轉向怎樣設計和執行基準測試上來。在我們討論如何把基準測試做好之前,先讓我們看下一些常見的錯誤,這些錯誤能導致不能用或者不精確地結果:
- 使用真實數據大小的子集,例如,當應用程序不得不處理好幾百G的數據時,我們只使用其中的1G數據;或者當你準備擴大你的應用程序時,使用現在的數據集
- 使用錯誤的數據分布,例如當真實系統數據中的“熱點”規則的數據分布(隨機生成的數據通常是不切實際的分布)。
- 使用不切實際的分布參數,例如,假設所有用戶的配置文件同樣地被瀏覽。
- 在多用戶應用中,使用單用戶場景。
- 在單臺服務器上測試分布式應用。
- 和真實用戶的行為錯誤地比較,例如web頁面上的“思考時間”。真實用戶請求并閱讀它;他們不會一個接一個沒有停頓地點擊鏈接。
- 在一個循環里執行相同的query語句。真實的query語句是不同的,所以它們會引起緩存未命中的情況。相同的query語句將會在某種級別全部或者部分被緩存。
- 未能檢查錯誤。如果一個基準測試的結果沒有意義-例如,如果一個慢操作突然非常快地完成,那么就該檢查錯誤。你就能測試出在一個SQL查詢時,MySQL能多快地探測到語法錯誤!原則性來說,每次測試完后都應該檢查錯誤日志。
- 當系統還沒有變熱的時候,忽略系統是怎樣執行的,例如,系統剛剛重啟后。有時你需要知道你的服務器重啟后,需要多長時間達到承載能力,所以你需要在熱啟動期間注意觀察。相反地,如果你想研究它的正常性能,你需要關心,如果你的測試正好在重啟后,許多緩存將被冷凍,那么測試結果將不會反映,在緩存在變熱后,在負載下得到的結果。
- 使用默認的服務設置。
???? 僅在避免這些錯誤上就會花費你很長時間來改進你的結果質量。
???? 對于別的所有事情都是同樣的,你應該在盡可能真實的環境中做測試。盡管有時,使用一個稍微不真實的測試也是明智的。例如,假如說你的應用程序在不同的主機上。使用相同的配置執行測試,將會更接近真實情況,但是這樣做就會增加更多變量,例如,網絡負載多少,多快。在單節點上測試往往很簡單,然而在某些情況下,將會更精確。什么時候使用最合適,完全取決于你的判斷。
?????? 設計和規劃測試
?? 規劃測試的第一步就是確定問題和目標。然后,決定是否使用標準的測試還是你自己設計。
??????如果你使用標準測試,要保證你選用的測試符合你的需求。例如,不要使用TCP測試你的電子商務系統。用TCP自己的話說,TCP“”。所以對于OLTP系統來說,不是一個合適的測試。
??????設計你自己的測試是一個復雜的反復的進程。開始,使用你生產環境中的數據集的快照。確保你能為后來的運行恢復這些數據集。
??????然后,你需要在數據里運行query語句。你可以在基本測試里添加單元測試套件,多次執行,但是這和你怎樣真實地使用數據庫,不大可能匹配。一個比較好的方法是在一個典型的時間框架內,記錄你生產環境中的所有的query語句,例如,在峰值負載內的一個小時,或者一整天。如果你在很短的時間框架內,記錄了query語句,你可能需要選擇幾個時間框架。這將會使你覆蓋所有系統活動,例如,每周報告query語句,或者在低峰值的時期,執行計劃任務。
??????你可以在不同等級下記錄query語句。例如,如果你需要全棧測試的話,你就可以記錄WEB服務器上的HTTP請求。你也可以啟用MySQL的查詢日志,但是如果你重放查詢日志,要確保重新創建單獨的線程,代替線性地重放每條query語句。在日志里為每個連接創建一個單獨的線程也是非常重要的,避免線程間的query阻塞。查詢日志顯示了哪個連接執行了哪條query語句。
?????? 即使你還沒有構建自己的測試,你可以寫下你的測試計劃。你可以使測試跑很多遍,你需要重新精確地構建你的測試。也為將來打算。你可能不是下次執行這個測試的人,即使你是,你可能也不太記得你第一次是怎么執行它的。你的計劃應該包括測試數據,安裝系統的步驟和熱啟動計劃。
???? 設計一些規范參數和結果的方法,并詳細地記錄每次執行。你的文檔方法可能如電子表格或者筆記那么簡單,也可能如定做的數據庫那么復雜(但是要記住,你要寫一些腳本來幫助分析測試結果,所以沒有比打開電子表格和文本文件更容易的方法了)。
???? 你可能會發現創建一個測試目錄,包含每次執行的結果的子目錄,會很有用。在相應地的子目錄,你可以放結果,配置文件,和每次執行的筆記。如果你的測試比你預想的多,而且你也很感興趣,無論如何記錄額外的數據。錯過記錄重要的數據總比不需要的數據要好,可能以后你會發現額外數據非常有用。在測試期間盡可能多地記錄附加信息,如CPU的使用情況,磁盤I/O,和網絡流量統計;SHOW GLOBAL STATUS的計數器,等等。
?????獲得精確結果
???? 獲得精確結果的最好方法是,設計你的測試來回答你想要的問題。你有選擇正確的測試嗎?你捕捉到你需要的答案的數據了嗎?你的測試有錯誤的標準嗎?例如,你有運行一個計算密集型的測試來預測I/O密集型的應用程序的性能嗎?
???? 接著,確保你的測試結果可以重復的。盡量確保你的系統在每次開始執行的時候,是處在相同狀態的。如果測試很重要,你應當在每次執行后重啟系統。如果你需要一個預熱過的服務器,正常來講,你也應當確保你的系統已經有足夠長的預熱。例如,如果預熱過程包含了隨機query查詢,那么你的測試結果將會不可重復。
???? 如果測試改變了測試數據或數據庫模式,在每次執行的時候,用快照重新設置它。向一個表中插入一千行記錄和向一個表中插入一百萬行記錄,不會給出相同的的結果。在磁盤上的數據存儲和分布也會使結果不可重復。一個方法是確保物理布局相近,做一個快速的格式和文件拷貝分區。
???? 當心額外負載,優化和監控系統,詳細記錄日志,計劃任務,以及其它因素能使你的結果發生偏移。
?????
?
轉載于:https://www.cnblogs.com/sunss/archive/2010/09/27/1836543.html
總結
以上是生活随笔為你收集整理的找出MySQL瓶颈的基准测试和剖析的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 马上消费金融会上征信吗 谨慎应对征信系统
- 下一篇: 远程管理MAC OS