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

一個診斷案例（ ）

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

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

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

究竟是什么導(dǎo)致了性能低下？

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

資源被過度使用 余量已經(jīng)不足以正常工作

資源沒有被正確配置

資源已經(jīng)損壞或者失靈

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

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

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

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

$ awk

/mysqld *tmp/ {

total += $ ;

}

/^Sun Mar / total {

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

total = ;

} lsof txt

: : MB

: : MB

: : MB

: : MB

: : MB

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

返回目錄 高性能MySQL

編輯推薦

ASP NET開發(fā)培訓(xùn)視頻教程

數(shù)據(jù)倉庫與數(shù)據(jù)挖掘培訓(xùn)視頻教程

lishixinzhi/Article/program/MySQL/201311/29695

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

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

高性能mysql 第三版怎么樣

在MySQL社區(qū)，這是一本重量級的書，我不知道出版社是怎么挑選譯者的，但是很明顯，我個人的意見，這次挑選非常的失敗。書中98頁倒數(shù)第4行的"binary search"的翻譯（二進制搜索）已經(jīng)道出了一切，但凡學(xué)過計算機的，我估計都不能做出這樣的翻譯。在計算機領(lǐng)域，二進制是一個專門的術(shù)語，有特定的含義。我不僅懷疑譯者根本沒學(xué)過"binary search"算法，以至于只能按字面翻譯，我甚至懷疑他們連“二進制”的含義可能也不懂，找這樣的人來翻譯，真是天大的笑話。 再舉一個術(shù)語的翻譯“secondary index”，書中的譯法是“第二索引”，暫且不論慣用的“二級索引”是否是一個標(biāo)準(zhǔn)的譯法，假如在主鍵之外，還有B，C兩個索引，如果B叫“第二索引”，那么C就應(yīng)該叫“第三索引”了？為什么C也叫“第二”呢，難道是并列第二？“第二”在漢語中是一個意思很明確的詞，你當(dāng)然可以說“第二”也能表示“二級”的意思，這種牽強的脫離通用語義的翻譯真是對翻譯標(biāo)準(zhǔn)“信雅達”中“達”字的諷刺。 關(guān)于“達”我們還可以找一個例子，介紹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的查詢”，原文讀來沒有任何的歧義，譯文卻變了樣，第一遍讀的時候，你能分辨出“即使該列不是索引的一部分”中的“該列”是指代的“l(fā)ast_name"呢？還是后面出現(xiàn)的"actor_id”呢？將代詞放在指代的名詞之前出現(xiàn)，這絕對是對人的智力的挑戰(zhàn)，即便是詩歌，我也沒見漢語中有多少這樣的用法，遑論技術(shù)性文字。在原文中"that column"這個代詞出現(xiàn)在了"actor_id"之后，不知道為什么在譯文中，代詞就鉆到了指代的名詞之前。 如果可以拋開“達”，還要爭辯詞的譯法是“見仁見智”的，那么對“信”的違背則已經(jīng)使這本重量級巨著的翻譯失去了最基本的存在價值，隨便舉兩個例子： 1. 4.6查詢提示優(yōu)化對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語句放在其他語句的前面，以便它修改數(shù)據(jù)”，原文中的“so they can modify data"變成了"以便它可以修改數(shù)據(jù)"，復(fù)數(shù)形式的they變成了單數(shù)形式的"它"，這個改變雖然細微，但直接影響了這個位置的代詞所指代的主語，這個代詞到底是"SELECT statement"呢？還是"other statements that may be waiting for locks"？原文中當(dāng)然是其他能modify data的statements，而到了疑問中，變成了"SELECT statement"，問一個菜鳥級的問題，select statement能modify data嗎？ 2. 還是4.6查詢提示優(yōu)化，對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"，譯文是"應(yīng)用了這個提示的語句會立即返回并將待插入的列放入緩沖區(qū)，在表空閑的時候再執(zhí)行插入"，粗看沒什么問題，細看問題一大堆。 2.1 在原文中，主語是it，指代的是"DELAYED"這個hint，到了譯文中，主語從"提示"本身變成了"應(yīng)用了這個提示的語句"，于是在原文中的"delayed"這個hint一方面使語句立即返回，另一方面使MySQL在后臺處理被緩存的數(shù)據(jù)兩層意思變成了語句一方面返回，另一方面“將待插入的列放入緩沖區(qū)”，到底是"DELAYED"使數(shù)據(jù)被插入buffer，還是應(yīng)用了"DELAYED"的語句使數(shù)據(jù)被插入了buffer，區(qū)別雖然微妙，但區(qū)別就是區(qū)別，譯文的意思與原文已差之毫厘，謬以千里。 2.2 原文中"which will be inserted in bulk..."是一個被動語態(tài)，指數(shù)據(jù)被插入，主語沒有明確指出，在上下文環(huán)境中當(dāng)然是數(shù)據(jù)庫；而到了譯文中，“在表空閑的時候再執(zhí)行插入”是一個主動的語態(tài)，“誰”執(zhí)行了插入？如果和上句連起來，很容易理解成“應(yīng)用了這個提示的語句在表空閑的時候再執(zhí)行插入”，這不是扯淡嗎？當(dāng)然，稍微有點數(shù)據(jù)庫常識的人都不會這樣理解，但原文原本語義清晰，翻譯過來卻主語混亂，實在令人難以接受。 2.2 在原文中的"rows"，一個復(fù)數(shù)形式的詞，到了譯文中，變成了"列"，假如說復(fù)數(shù)變單數(shù)還能接受，把"row"翻譯成"列"真是天才的創(chuàng)舉。 2.3 原文中"will be inserted in bulk when ..."明確指出了insert的方式是"in bulk"，但是這個信息在譯文中丟失了。 類似的問題簡直處處可見，原文的文字簡潔清晰，非常容易理解，但我讀到的譯文卻非常難以理解，更可恨的是，原文中大量的信息被扭曲，拋棄?！靶叛胚_”這三標(biāo)準(zhǔn)沒有一個做到。我個人的總結(jié)是，這個譯本的水平跟中國足球的水平一樣，能把球停在百米開外，一個字，糙。 客觀地說，這本書至少將MySQL優(yōu)化的知識在中國的傳播門檻大大降低，但咱不是黃鶯，不會唱贊歌，既然是書評，就是要來挑刺的，看不到刺，容不得刺，電子工業(yè)永遠沒有趕上O'Relly的機會，中國的技術(shù)書籍永遠都只能是菜鳥水平。

mysql數(shù)據(jù)庫的優(yōu)點

mysql數(shù)據(jù)庫的優(yōu)點如下：

1、速度:運行速度快。

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

3、容易使用;與其他大型數(shù)據(jù)庫的設(shè)置和管理相比，其復(fù)雜程度較低，容易學(xué)習(xí)。

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

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

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

高性能MySQL：運行基準(zhǔn)測試并分析結(jié)果

運行基準(zhǔn)測試并分析結(jié)果

一旦準(zhǔn)備就緒 就可以著手基準(zhǔn)測試 收集和分析數(shù)據(jù)了

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

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

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

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

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

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

假設(shè)該腳本名為 *** yze 當(dāng)前面的腳本生成狀態(tài)文件以后 就可以運行該腳本 可能會得到如下的結(jié)果

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

返回目錄 高性能MySQL

編輯推薦

ASP NET開發(fā)培訓(xùn)視頻教程

數(shù)據(jù)倉庫與數(shù)據(jù)挖掘培訓(xùn)視頻教程

lishixinzhi/Article/program/MySQL/201311/29735

網(wǎng)頁標(biāo)題：高性能的mysql怎么樣 mysql性能比較
分享路徑：http://jinyejixie.com/article22/doscdjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、云服務(wù)器、網(wǎng)站收錄、App開發(fā)、Google、網(wǎng)站改版

廣告

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