高性能MySQL：一個診斷案例（3）

一個診斷案例（ ）

我們提供的服務有：網站設計制作、成都網站制作、微信公眾號開發、網站優化、網站認證、柳南ssl等。為上1000家企事業單位解決了網站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的柳南網站制作公司

我們看到了兩種可能性 要么是數據庫導致了I/O（如果能找到源頭的話 那么可能就找到了問題的原因） 要么不是數據庫導致了所有的I/O 而是其他什么導致的 而系統因為缺少I/O 資源影響了數據庫性能 我們也很小心地盡力避免引入另外一個隱式的假設 磁盤很忙并不一定意味著MySQL 會有問題 要記住 這個服務器主要的壓力是內存讀取 所以也很可能出現磁盤長時間無法響應但沒有造成嚴重問題的現象

如果你一直跟隨我們的推理邏輯 就可以發現還需要回頭檢查一下另外一個假設 我們已經知道磁盤設備很忙 因為其等待時間很高 對于固態硬盤來說 其I/O 平均等待時間一般不會超過 / 秒 實際上 從iostat 的輸出結果也可以發現磁盤本身的響應還是很快的 但請求在塊設備隊列中等待很長的時間才能進入到磁盤設備 但要記住 這只是iostat 的輸出結果 也可能是錯誤的信息

究竟是什么導致了性能低下？

當一個資源變得效率低下時 應該了解一下為什么會這樣 有如下可能的原因

資源被過度使用 余量已經不足以正常工作

資源沒有被正確配置

資源已經損壞或者失靈

回到上面的例子中 iostat 的輸出顯示可能是磁盤的工作負載太大 也可能是配置不正確（在磁盤響應很快的情況下 為什么I/O 請求需要排隊這么長時間才能進入到磁盤？） 然而 比較系統的需求和現有容量對于確定問題在哪里是很重要的一部分 大量的基準測試證明這個客戶使用的這種SSD 是無法支撐幾百MB/s 的寫操作的 所以 盡管iostat 的結果表明磁盤的響應是正常的 也不一定是完全正確的 在這個案例中 我們沒有辦法證明磁盤的響應比iostat 的結果中所說的要慢 但這種情況還是有可能的 所以這不能改變我們的看法 可能是磁盤被濫用注 或者是錯誤的配置 或者兩者兼而有之 是性能低下的罪魁禍首

在檢查過所有診斷數據之后 接下來的任務就很明顯了 測量出什么導致了I/O 消耗 不幸的是 客戶當前使用的GNU/Linux 版本對此的支持不力 通過一些工作我們可以做一些相對準確的猜測 但首先還是需要探索一下其他的可能性 我們可以測量有多少I/O來自MySQL 但客戶使用的MySQL 版本較低以致缺乏一些診斷功能 所以也無法提供確切有利的支持

作為替代 基于我們已經知道MySQL 如何使用磁盤 我們來觀察MySQL 的I/O 情況 通常來說 MySQL 只會寫數據 日志 排序文件和臨時表到磁盤 從前面的狀態計數器和其他信息來看 首先可以排除數據和日志的寫入問題 那么 只能假設MySQL 突然寫入大量數據到臨時表或者排序文件 如何來觀察這種情況呢？有兩個簡單的方法 一是觀察磁盤的可用空間 二是通過lsof 命令觀察服務器打開的文件句柄 這兩個方法我們都采用了 結果也足以滿足我們的需求 下面是問題期間每秒運行df–h 的結果

下面則是lsof 的數據 因為某些原因我們每五秒才收集一次 我們簡單地將mysqld 在/tmp 中打開的文件大小做了加總 并且把總大小和采樣時的時間戳一起輸出到結果文件中

$ awk

/mysqld *tmp/ {

total += $ ;

}

/^Sun Mar / total {

printf %s % f MB\n $ total/ / ;

total = ;

} lsof txt

: : MB

: : MB

: : MB

: : MB

: : MB

從這個數據可以看出 在問題之初MySQL 大約寫了 GB 的數據到臨時表 這和之前在SHOW PROCESSLIST 中有大量的 Copying to tmp table 相吻合 這個證據表明可能是某些效率低下的查詢風暴耗盡了磁盤資源 根據我們的工作直覺 出現這種情況比較普遍的一個原因是緩存失效 當memcached 中所有緩存的條目同時失效 而又有很多應用需要同時訪問的時候 就會出現這種情況 我們給開發人員出示了部分采樣到的查詢 并討論這些查詢的作用 實際情況是 緩存同時失效就是罪魁禍首（這驗證了我們的直覺） 一方面開發人員在應用層面解決緩存失效的問題 另一方面我們也修改了查詢 避免使用磁盤臨時表 這兩個方法的任何一個都可以解決問題 當然最好是兩個都實施

返回目錄 高性能MySQL

編輯推薦

ASP NET開發培訓視頻教程

數據倉庫與數據挖掘培訓視頻教程

lishixinzhi/Article/program/MySQL/201311/29695

深入淺出mysql和高性能mysql哪本好

看過高性能mysql，對于想深入了解mysql性能優化的人來說絕對值得一看

高性能mysql 第三版怎么樣

在MySQL社區，這是一本重量級的書，我不知道出版社是怎么挑選譯者的，但是很明顯，我個人的意見，這次挑選非常的失敗。書中98頁倒數第4行的"binary search"的翻譯（二進制搜索）已經道出了一切，但凡學過計算機的，我估計都不能做出這樣的翻譯。在計算機領域，二進制是一個專門的術語，有特定的含義。我不僅懷疑譯者根本沒學過"binary search"算法，以至于只能按字面翻譯，我甚至懷疑他們連“二進制”的含義可能也不懂，找這樣的人來翻譯，真是天大的笑話。 再舉一個術語的翻譯“secondary index”，書中的譯法是“第二索引”，暫且不論慣用的“二級索引”是否是一個標準的譯法，假如在主鍵之外，還有B，C兩個索引，如果B叫“第二索引”，那么C就應該叫“第三索引”了？為什么C也叫“第二”呢，難道是并列第二？“第二”在漢語中是一個意思很明確的詞，你當然可以說“第二”也能表示“二級”的意思，這種牽強的脫離通用語義的翻譯真是對翻譯標準“信雅達”中“達”字的諷刺。 關于“達”我們還可以找一個例子，介紹coverring index的部分，譯文第96頁，原文第124頁。原文是“For example,the sakila.actor table uses InnoDB and has an index on last_name, so the index can cover queries that retrieve the primary key column actor_id, even though that column isn’t technically part of the index”，譯文是“例如，sakila.actor表適用了InnoDB并且在last_name上有索引，因此，即使該列不是索引的一部分，索引頁可以覆蓋取得主鍵actor_id的查詢”，原文讀來沒有任何的歧義，譯文卻變了樣，第一遍讀的時候，你能分辨出“即使該列不是索引的一部分”中的“該列”是指代的“last_name"呢？還是后面出現的"actor_id”呢？將代詞放在指代的名詞之前出現，這絕對是對人的智力的挑戰，即便是詩歌，我也沒見漢語中有多少這樣的用法，遑論技術性文字。在原文中"that column"這個代詞出現在了"actor_id"之后，不知道為什么在譯文中，代詞就鉆到了指代的名詞之前。 如果可以拋開“達”，還要爭辯詞的譯法是“見仁見智”的，那么對“信”的違背則已經使這本重量級巨著的翻譯失去了最基本的存在價值，隨便舉兩個例子： 1. 4.6查詢提示優化對HIGH_PRIORITY的描述，譯本第152頁，原書第195頁，原文是“HIGH_PRIORITY tells MySQL to schedule a SELECT statement before other statements that may be waiting for locks, so they can modify data.”，譯文是“HIGH_PRIORITY告訴MySQL將SELECT語句放在其他語句的前面，以便它修改數據”，原文中的“so they can modify data"變成了"以便它可以修改數據"，復數形式的they變成了單數形式的"它"，這個改變雖然細微，但直接影響了這個位置的代詞所指代的主語，這個代詞到底是"SELECT statement"呢？還是"other statements that may be waiting for locks"？原文中當然是其他能modify data的statements，而到了疑問中，變成了"SELECT statement"，問一個菜鳥級的問題，select statement能modify data嗎？ 2. 還是4.6查詢提示優化，對DELAYED的描述，譯文第152頁，原文第196頁。原文是"It lets the statement to which it is applied return immediately and places the inserted rows into a buffer, which will be inserted in bulk when the table is free"，譯文是"應用了這個提示的語句會立即返回并將待插入的列放入緩沖區，在表空閑的時候再執行插入"，粗看沒什么問題，細看問題一大堆。 2.1 在原文中，主語是it，指代的是"DELAYED"這個hint，到了譯文中，主語從"提示"本身變成了"應用了這個提示的語句"，于是在原文中的"delayed"這個hint一方面使語句立即返回，另一方面使MySQL在后臺處理被緩存的數據兩層意思變成了語句一方面返回，另一方面“將待插入的列放入緩沖區”，到底是"DELAYED"使數據被插入buffer，還是應用了"DELAYED"的語句使數據被插入了buffer，區別雖然微妙，但區別就是區別，譯文的意思與原文已差之毫厘，謬以千里。 2.2 原文中"which will be inserted in bulk..."是一個被動語態，指數據被插入，主語沒有明確指出，在上下文環境中當然是數據庫；而到了譯文中，“在表空閑的時候再執行插入”是一個主動的語態，“誰”執行了插入？如果和上句連起來，很容易理解成“應用了這個提示的語句在表空閑的時候再執行插入”，這不是扯淡嗎？當然，稍微有點數據庫常識的人都不會這樣理解，但原文原本語義清晰，翻譯過來卻主語混亂，實在令人難以接受。 2.2 在原文中的"rows"，一個復數形式的詞，到了譯文中，變成了"列"，假如說復數變單數還能接受，把"row"翻譯成"列"真是天才的創舉。 2.3 原文中"will be inserted in bulk when ..."明確指出了insert的方式是"in bulk"，但是這個信息在譯文中丟失了。 類似的問題簡直處處可見，原文的文字簡潔清晰，非常容易理解，但我讀到的譯文卻非常難以理解，更可恨的是，原文中大量的信息被扭曲，拋棄。“信雅達”這三標準沒有一個做到。我個人的總結是，這個譯本的水平跟中國足球的水平一樣，能把球停在百米開外，一個字，糙。 客觀地說，這本書至少將MySQL優化的知識在中國的傳播門檻大大降低，但咱不是黃鶯，不會唱贊歌，既然是書評，就是要來挑刺的，看不到刺，容不得刺，電子工業永遠沒有趕上O'Relly的機會，中國的技術書籍永遠都只能是菜鳥水平。

mysql數據庫的優點

mysql數據庫的優點如下：

1、速度:運行速度快。

2、價格:MySQL對多數個人來說是免費的。

3、容易使用;與其他大型數據庫的設置和管理相比，其復雜程度較低，容易學習。

4、可移植性:能夠工作在眾多不同的系統平臺上，例如:Windows、Linux、Unix、MacOS等。

5、豐富的接口:提供了用于C、C++、Eiffel、Java、Perl、PHP、Python、Rudy和TCL等語言的APl。6、支持查詢語言:MySQL可以利用標準SQL語法和支持ODBC(開放式數據庫連接）的應用程序。

7、安全性和連接性;十分靈活和安全的權限和密碼系統，允許主機驗證。連接到服務器時，所有的密碼均采用加密形式，從而保證了密碼安全。并且由于MySQL時網絡化的，因此可以在因特網網上的任何地方訪問，提高數據共享效率。

高性能MySQL：運行基準測試并分析結果

運行基準測試并分析結果

一旦準備就緒 就可以著手基準測試 收集和分析數據了

通常來說 自動化基準測試是個好主意 這樣做可以獲得更精確的測試結果 因為自動化的過程可以防止測試人員偶爾遺漏某些步驟 或者誤操作 另外也有助于歸檔整個測試過程

自動化的方式有很多 可以是一個Makefile 文件或者一組腳本 腳本語言可以根據需要選擇 shell PHP Perl 等都可以 要盡可能地使所有測試過程都自動化 包括裝載數據 系統預熱 執行測試 記錄結果等

一旦設置了正確的自動化操作 基準測試將成為一步式操作 如果只是針對某些應用做一次性的快速驗證測試 可能就沒必要做自動化 但只要未來可能會引用到測試結果 建議都盡量地自動化 否則到時候可能就搞不清楚是如何獲得這個結果的 也不記得采用了什么參數 這樣就很難再通過測試重現結果了

基準測試通常需要運行多次 具體需要運行多少次要看對結果的記分方式 以及測試的重要程度 要提高測試的準確度 就需要多運行幾次 一般在測試的實踐中 可以取最好的結果值 或者所有結果的平均值 亦或從五個測試結果里取最好三個值的平均值 可以根據需要更進一步精確化測試結果 還可以對結果使用統計方法 確定置信區間（confidence interval）等 不過通常來說 不會用到這種程度的確定性結果注 只要測試的結果能滿足目前的需求 簡單地運行幾輪測試 看看結果的變化就可以了 如果結果變化很大 可以再多運行幾次 或者運行更長的時間 這樣都可以獲得更確定的結果

獲得測試結果后 還需要對結果進行分析 也就是說 要把 數字 變成 知識 最終的目的是回答在設計測試時的問題 理想情況下 可以獲得諸如 升級到 核CPU 可以在保持響應時間不變的情況下獲得超過 % 的吞吐量增長 或者 增加索引可以使查詢更快 的結論 如果需要更加科學化 建議在測試前讀讀null hypothesis 一書 但大部分情況下不會要求做這么嚴格的基準測試

如何從數據中抽象出有意義的結果 依賴于如何收集數據 通常需要寫一些腳本來分析數據 這不僅能減輕分析的工作量 而且和自動化基準測試一樣可以重復運行 并易于文檔化 下面是一個非常簡單的shell 腳本 演示了如何從前面的數據采集腳本采集到的數據中抽取時間維度信息 腳本的輸入參數是采集到的數據文件的名字

假設該腳本名為 *** yze 當前面的腳本生成狀態文件以后 就可以運行該腳本 可能會得到如下的結果

第一行是列的名字 第二行的數據應該忽略 因為這是測試實際啟動前的數據 接下來的行包含Unix 時間戳 日期 時間（注意時間數據是每 秒更新一次 前面腳本說明時曾提過） 系統負載 數據庫的QPS（每秒查詢次數）五列 這應該是用于分析系統性能的最少數據需求了 接下來將演示如何根據這些數據快速地繪成圖形 并分析基準測試過程中發生了什么

返回目錄 高性能MySQL

編輯推薦

ASP NET開發培訓視頻教程

數據倉庫與數據挖掘培訓視頻教程

lishixinzhi/Article/program/MySQL/201311/29735

網頁標題：高性能的mysql怎么樣 mysql性能比較
分享路徑：http://vcdvsql.cn/article22/doscdjc.html

成都網站建設公司_創新互聯，為您提供網站排名、云服務器、網站收錄、App開發、Google、網站改版

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯