MySQL 調整

昨天晚上幫「測試」,發現速度卡在 的 CPU bound,先用 丟在背景跑,再用 抓幾個比較明顯的 slow query,補了幾刀 INDEX 後,速度快了不少,不過還是不太滿意。

印象中 MySQL 除了可以紀錄 slow query 外,還可以紀錄沒用到 INDEX 的 SQL query,花了不少時間才找到。這些指令是可以線上改,不需要重開 (如果你堅持要改設定檔重開也 ok),不過請不要在 production 的機器上開,以免 SQL query 寫的很爛,產生大量的 log:

mysql> SET GLOBAL log_queries_not_using_indexes = 1;
Query OK, 0 rows affected (0.00 sec)
mysql> SET GLOBAL slow_query_log = 1;
Query OK, 0 rows affected (0.00 sec)

參考:

PS:這只是告訴你問題在哪裡,而非解決的方法。要知道為什麼會慢,你需要讀不少資料,像是 這類的書籍,以及網路上 MySQL 資料庫長輩們的討論。

Update:翻到 這篇,可以檢查過度 index 時造成效能降低的問題 :p

MySQL UDF (User-defined function) 與 memcached

以往 + 的作法是由 application 端「拉」資料後再塞到 memcached 上,這會產生幾個問題:

  • 資料不同步:MySQL 上的資料更新了,但 memcached 裡的 cache 因為還沒過期而尚未更新。
  • 第一次的 Race Condition:同時有很多 client 向 memcached 要一份目前還不存在的 cache,這時候這些 client 都會跑到 MySQL 要資料再放一份到 memcached 上。

這兩個問題都有在 MySQL UDF + memcached 出來之前都有解法:前者可以在更新 MySQL 時順便更新 memcached 裡的資料;後者可以靠 memcached lock 的技巧避免突然有大量 Query 造成後端 MySQL 負荷過重。這兩個方法需要 application (client) 配合,不是很完美,但在實際應用上還算堪用。(一個很簡單的場景:如果公司內同時使用 ,那麼就必須維護這兩個 library)

除了 client 自己推資料到 memcached 上,也有人研究,當 MySQL 上的資料更新時,由 MySQL server 自動到 memcached 上更新資料,也就是把資料「推」到 memcached 上的方法。資料更新時的觸發動作可以用 做到,而寫入到 memcached 的部份透過強者的 處理:

btw, 也用 libmemcache 寫過類似的東西: 這篇的下方 (「MySQL and memcached」的部份)

Mtron SSD 固態硬碟

補「」這篇的說明。

價位上, SSD Pro 7000 系列 32GB 的單顆進價大約在 $40K (含稅),兩顆就 $80K 了,相較 15K RPM 73GB SCSI 硬碟四顆只要 $40K 的價錢偏高不少。

效率上,MyISAM 的 real data 測試發現不論是 Mtron SSD 32GB*2 跑 RAID0,還是 15K RPM 73GB SCSI*4 跑 RAID10,都是 CPU 先到瓶頸,I/O 都沒有問題。至於 的結果在 的 Blog 上可以看到不少 real data 的資訊。

不過,如果你的資料庫遇到 I/O 瓶頸的話 (用 RAID 1+0 都還解決不了) 可以考慮用多顆 Mtron SSD RAID 把效率換出來,不過比較治本的方法應該是改寫程式,想辦法 partition。另外看看是不是因為大量的 Table scan 造成效率低落...

對了,Mtron SSD 硬碟台灣有代理商了,

MySQL Proxy 的用途

作者的 Blog 上看到一些關於 transaction 時有趣的用法:

話說回來,最近 又有一陣子沒什麼動作了,看起來心力都花在 上面了...

InnoDB Barracuda

InnoDB Barracuda (InnoDB Plugin 提供的新格式) 有測試結果了,在「」這篇裡面以一個 30GB 的 mysqldump 檔案測試 (看他文章的內容,應該是 real data),在裡面提到幾個重點:

  • 目前的 有個與 UTF-8 有關的 bug 會影響測試結果 (「」),所以測試時以 latin1 測試。
  • 為了測試 fast index,他用兩種不同的方式測試。第一種是把所有 DB scheme 與 index 都建立好,再將資料匯入;第二種是只先建立 primary key,等到匯入資料後再下 index。測試的結果發現,後者的總時間遠遠超越前者。
  • 如果使用壓縮格式,匯入的速度會慢 30% ~ 50%,但是檔案大小只有原來的 1/3,讀取的速度不在這次測試的範圍裡,不過 comment 有人期待對於偏 I/O 的 query 效能會有提昇。

變天了...

好幾天沒寫 Blog 了,主要是星期五六日去員工旅遊 (參考「」這邊),然後星期日晚上與星期一狂看 與新番,於是就好幾天沒寫 Blog 了...

說變天的原因是因為很多單位在 這段時間發表了一堆東西,就管理與政策面來看,這是 買下 後第一次的 MySQL Conference,很多人都在看 Sun 對於 MySQL 這套 Open Source Software 到底會有什麼大計畫。

另外一方面 (技術上), 推出的 所列出的優點讓人相當驚豔,解決了不少問題,不過可惜在目前最新版 5.1.24-rc 上無法運作。

再來是 用硬體的方式大幅增加 transaction 的速度,站上 Non-cluster 100GB data 的王座,實際上機器也很便宜,才 USD$35K。(如果你真的需要用到這麼快的 transaction 速度,百萬台幣應該不是什麼問題)

結果玩回來後發現一堆計畫都要再重新思考...