史萊姆論壇

返回   史萊姆論壇 > 專業主討論區 > 論壇程式討論區
忘記密碼?
註冊帳號 論壇說明 標記討論區已讀

歡迎您來到『史萊姆論壇』 ^___^

您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的!

請點擊這裡:『註冊成為我們的一份子!』

Google 提供的廣告


發文 回覆
 
主題工具 顯示模式
舊 2007-06-24, 01:17 PM   #1
Admin1
管理員
 
Admin1 的頭像
榮譽勳章
UID - 112827
在線等級: 級別:29 | 在線時長:972小時 | 升級還需:48小時級別:29 | 在線時長:972小時 | 升級還需:48小時級別:29 | 在線時長:972小時 | 升級還需:48小時級別:29 | 在線時長:972小時 | 升級還需:48小時級別:29 | 在線時長:972小時 | 升級還需:48小時級別:29 | 在線時長:972小時 | 升級還需:48小時級別:29 | 在線時長:972小時 | 升級還需:48小時級別:29 | 在線時長:972小時 | 升級還需:48小時級別:29 | 在線時長:972小時 | 升級還需:48小時
註冊日期: 2007-02-18
VIP期限: 0000-00
文章: 3507
精華: 0
現金: 1702 金幣
資產: 10196 金幣
預設 討論 - 辨識 MySQL Slow Queries 的一般性原則

本篇文章是由 Daniel Nichter 的 "Non-technical Guide to Isolating Slow MySQL Queries" 翻譯而來。



本文開始

由於 MySQL 的普及,我們不難發現有許多 MySQL 的非專業使用者,他們十分依賴 MySQL 進行日常營運但卻不想(也不打算)進一步的成為 MySQL 專家,對他們而言只要可以用就好了。當與 Query 相關的效能瓶頸出現時,這些使用者將沒有能力解決所糟遇的難題,因為在這世界上並不存在對於 Slow Query 的通用解決方案;你所糟遇到的所有情況都是獨一無二的。

此份文件並非技術文件,而是記載辨識 MySQL Slow Queries 的一般性原則。你不需要是 MySQL 專家、也不需要知道如何分析 Query,也可以懂得如何辨識出對系統效能產生最多影響的 Slow Query。一但你辨識出這些 Queries 後,你就可以求助於 MySQL 專家來解決此問題。



一、建立基準(Baseline)
在你對 MySQL Server 進行任何改變之前,一定要先建立目前 MySQL Server 的效能基準,不然的話你就無法得知後續對於 Server 的調校是否真的可以提升效能。要建立基準的最簡單方式就是使用 mysqlreport,你只要先讓 MySQL Server 至少先運作個一整天然後再使用 mysqlreport 產生分析報表即可掌握 Server 目前的運作狀況。如果你沒辦法讓 MySQL Server 至少運作個一整天,那麼產生出來的報表可能會具有偏誤、比較不具代表性。


二、評估基準
mysqlreport 所產生出來的報表包含有非常多的資訊,但我們目前只需要關注在其中三項即可。首先要看的是 "Read ratio" (line 6 or 7),它應該要低於 0.01,若它超過 0.01 你就必須要分配多一點的 RAM 給 MySQL Server 使用。務必要確定系統有足夠的 RAM 可使用,若系統整體的 RAM 使用量已超出負荷,然後你又調高 MySQL 可使用的 RAM 上限,將會造成 MySQL 不斷地進行 SWAP 而讓問題變得更嚴重。

接下來要看的是 "Slow" (line 16)。Slow 表示 Slow Queries 的數量,系統預設將執行時間超過 10 秒的 Query 判定為 Slow Queries,而這個項目的最後一個欄位之數值應該要低於 0.05,若它高於 0.30 你八成會發現系統有些很明顯的問題發生。我們必須要儘全力地去降低 Slow 的數值。

最後一個要注意的項目是 "Waited" (line 48),尤其是最後一個欄位的數值。這個數值表示 MySQL 需要等待以取得 Table Lock 的次數之多寡,通常這個數值會低於 10%,若是它超過 10% 通常是因為 Slow Queries 所造成的。

你並不需要了解這些數值所代表的詳細意義,但是它們的確讓我們對於 MySQL 的運作狀況有一個整體的概念。若是這些數值偏高,那麼負責處理這些問題的 MySQL 專家將可以很容易的就找出問題點;但若是這些數值偏低,但 MySQL Server 卻運作的十分沒有效率,MySQL 專家們應該還是可以找出確切的問題點。


三、記錄 Slow Queries 並且等待
MySQL 預設並不會記錄 Slow Queries,你必須要修改 MySQL Server 的系統設定檔,例如 /etc/my.cnf:
引用:
[mysqld]
log-slow-queries
long_query_time = 1
重新啟動 MySQL 並且等待至少一整天的時間,MySQL 將會記錄所有執行時間超過一秒的 Slow Queries。Slow Query Log 的檔案名稱預設是 slow_queries,它們會存在 MySQL 的 Data Dir 之中,若是你不知道 MySQL Data Dir 在什麼地方,可以在登入 MySQL 指用以下的指令來找出:"SHOW VARIABLES LIKE 'datadir';"。在 Linux 系統中它通常會是 /var/lib/mysql/,因此 Slow Query Log 就會是 /var/lib/mysql/slow_queries.log。


四、辨識出 Top 10 Slow Queries
要辨識出 Top 10 Slow Queries 的最簡單方式就是使用 mysqlsla 來分析 slow loq,你可以將 mysqlsla 所產生出來的報表交給 MySQL 專家,讓它們協助你解決問題。在大部份的情況下,就算是只有 Top 3 的 Slow Queries 可以被克服,MySQL Server 的整體效能仍然可能會有大幅度的提升。從這裡開始,之後的工作就要交由 MySQL 專家來處理。


五、確認系統效能是否已改善
假設您的 MySQL 專家具有解決 Top Slow Queries 的能力,那麼你的最後工作就是確認系統效能已確實的改善。重新啟動 MySQL 並且讓它至少執行個一整天,再以 mysqlreport 來評估系統的運作效能,然後再將結果與之前的報表做比較,尤其注意第二步驟中所提到的那三個項目(Read ratio, Slow, and Waited)。這三個項目的值應該會很顯著的降低才是,若沒有,則進一步的向您的 MySQL 專家詢問,他們將會告訴你為什麼這不是一個可以輕易達成的 "simple fix"。


事先告知
當你的 MySQL Server 順利的運轉了幾個星期之後同樣的問題卻再度發生時,不要覺得驚訝,因為效能的調校往往牽涉到許多複雜的層面,而不是單一的問題。當你今日解決了 MySQL 的效能問題後,有可能在幾個月後你會需要再重新進行一次整個步驟,這不是 MySQL 的錯,而是 "成長" 所造成的負作用。有可能只是單純的因為你的資料庫使用者發現 MySQL 運作的更順暢,因此他們就更頻繁的使用,而更頻繁的使用就再度的加重系統的負載。當越多的負載加諸在您的 MySQL Server 上時,自然就需要越多的效能調校。

此帖於 2007-06-27 10:19 PM 被 Admin1 編輯. 原因: 修正錯字
Admin1 目前離線  
送花文章: 8870, 收花文章: 2195 篇, 收花: 5820 次
回覆時引用此帖
有 4 位會員向 Admin1 送花:
cchiung (2007-06-27),fcya (2007-06-26),Tianuc (2008-03-21),飛鳥 (2007-06-26)
感謝您發表一篇好文章
發文 回覆


主題工具
顯示模式

發表規則
不可以發文
不可以回覆主題
不可以上傳附加檔案
不可以編輯您的文章

論壇啟用 BB 語法
論壇啟用 表情符號
論壇啟用 [IMG] 語法
論壇禁用 HTML 語法
Trackbacks are 禁用
Pingbacks are 禁用
Refbacks are 禁用


所有時間均為台北時間。現在的時間是 06:21 PM


Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2019, Jelsoft Enterprises Ltd.


SEO by vBSEO 3.6.1