Home » Computer » Software » Database » Archive by category "MySQL" (Page 33)

一些雜記

如果 bug 愈找愈久,代表那個 bug 一定很笨 XD

像是今天一整天跟 ronnywang 在找一個 Zend_Db 會爛掉的 bug,最後發現是因為 PDO_MYSQL 沒裝... XD

愈來愈多關節打通了,接下來就來衝吧...

MyISAM 在 FreeBSD 上效率不好的原因?

Jeff Roberson (也就是目前 FreeBSD 上 SCHED_ULE 的維護者) 的 blog 上說了這樣的話:(原文章連結)

MyISAM performance is terrible in FreeBSD 7.0 due to the user-space pthread_rwlock implementation. Just a word of warning if you intend to deploy a database server based on 7.0. I am certain we will have this fixed in 7.1. It will most likely be in CURRENT in a week or two.

所以不是我在「FreeBSD 上的 MySQL 效率」這裡想的 Filesystem I/O 問題?來等 Jeff Roberson 的 patch 吧...

Twitter

最近很少寫 Blog (程式沒寫幾行,倒是一堆行政上面的事情),不過 Twitter 上倒是常常念。

最近忙一些事情,像是寫不完的採購簽呈 (還好有一部分交給 slzzp 了),然後是開不完的會,如果要抽時間寫程式的話,就得在一般人下班後才有空了...

不管怎麼樣,最近看 jnlin 玩,以及我自己玩一些東西,有些有趣的想法,寫下來紀錄起來。

FreeBSD 7.0 的 SCHED_ULE 長期觀察下來 (超過兩個月) 算是相當穩定,這點在目前 PIXNET 的 Web Server 端可以看出來 (在 FreeBSD 跑 apache22 event 是使用 threading,配合 FastCGIPHP),但 gjournalZFS 在效率以及穩定度上都還不堪使用。(指 heavy I/O)

MyISAM 的讀取速度非常快,但不利於大量 Update (因為寫入的動作需要 table lock)。在國外的討論裡,一般都是推薦使用 InnoDB 解決這類 table 的情況,但實際上目前 InnoDB 的備份問題比起 MyISAM 麻煩 (經驗也是一個大問題),這點可能還要再考慮。

要解決 table lock 的問題,另外一種方式是透過拆 table,而且目前看起來拆 table 撐 performance 的方式似乎相當可行 (在概念上,這是一種 HyperDB 的變形),所以最近應該會對這個方向大量研究。不過就得做不少 Denormalize 的事情,還是得累積經驗...

如果有想到其他值得提的事情再寫好了...

MySQL 在創見 SSD 上跑的情況

最近進了四顆創見 SSD MLC 顆粒 32GB 硬碟 (連結應該沒錯) 跑 RAID 1+0,就讓 jnlinDebian 上跑 MySQL 5.1 測試 MyISAM 的效率,測試的結果相當慘,寫入的速度在個位數 qps (對... <10 query per second),而且不是模擬資料,是 Real Data 的 Replication Update...

測過的 Filesystem 包括 ext3XFS,block size 也調整過好幾次,RAID 1+0 的部份是軟體做,這部份的 block size 也調整過,不過不管怎麼測,速度都還是上不去。

Mtron SSD 硬碟還沒有開始在台灣代理之前,用一堆 RAM 加上 15K RPM SCSI 硬碟做 RAID 1+0 比較便宜,而且也比較穩定...

Update:我要求 jnlin 將測試的想法丟到網頁上,現在可以在他的 blog 上看到了:「MySQL 在創見 SSD 上的測試」。

MySQL Falcon 的一些事情

ZFS 上順便測了一下 MySQL 6.0 (以 6.0.3 版測試) 的 Falcon Engine,紀錄下一些東西:

  • Falcon 與 InnoDB 類似,以一組檔案儲存資料庫的檔案,所以不太容易備份,不像 MyISAM 有 mysqlhotcopy 可以用。
  • 寫入效率上相當差,即使開了 falcon_disable_fsync=1 還是很慢,以四個 client 倒資料進去,寫入速度約 MyISAM 的 1/10 ~ 1/20,以一個 client 倒也是一樣的情況。瓶頸不在 CPU (800% 的量大約用掉 2%) 與 I/O (以 gstat 看約 50% busy),暫時還看不出問題。
  • SELECT 的最佳化似乎有問題,對有 index 的 column 下了幾次有用到 ORDER BY 的 simple query,看反應速度很像 table scan,但 EXPLAIN 出來的結果都顯示有使用 index。

Replication 與 Transaction 暫時還沒測,也許應該先測 PBXT Engine...

FreeBSD 上的 MySQL 效率

測試的結論是,FreeBSD 現在缺乏穩定而且高效率的 Filesystem 讓 MySQL MyISAM 使用。

先解釋一下現在的環境,有兩台 Tyan Server,上面都是 Dual Quad Core 與 12GB RAM (6*2GB),接兩顆 73GB SCSI 硬碟,兩台的差異在於 CPU,新進的這台是 E5410 (2333Mhz,2*6144KB L2),舊的是 E5320 (1866Mhz,2*4096KB L2)。

舊的是目前 PIXNET production 的 MySQL database,跑 Debian/amd64,kernel 是 2.6.22,檔案系統是 XFS。另外一台則是前陣子另外進的,裝了 FreeBSD/amd64 7.0-BETA2,然後透過 make kernel & make world 升級到 7.0-PRERELEASE,跑 SCHED_ULE,檔案系統是 UFS2。依照慣例,noatime 與 nodiratime 之類的參數都會設上去,兩台都是跑 MySQL 5.1.22-rc,都是 MySQL slave。

要複製 slave 很簡單,把 production 停機 (利用使用者比較少的時候,其他的 slave 會負責這台本來的事情),整個目錄複製一份到新的 FreeBSD 上,改 server_id 後跑起來後 MySQL 會跟 master 更新。

然後用 databases/mytop 看 replication delay 的情況 (原版的 mytop 沒有這個訊息,這是 FreeBSD ports patch 的功能),發現即使是放著跑 replication sync,某些時候 UPDATE 的速度反而會跟不上 master,跟不上時的 I/O 是滿載的 (透過 gstat 看的)

目前測過最好的情況是這樣跑:gstripe -s 16384 將 da{0,1} 串起來,用 async + noatime。其他的情況包括:

  • gstripe -s 16384 + gjournal + async + noatime:日誌類的 Filesystem 在 DB 這類用法的速度不會提昇,與預料的差不多。
  • gstripe -s 16384 + soft updates + noatime:畢竟要維持 consistent,速度慢一些。
  • 單顆硬碟 + async + noatime:也如同預期的,速度只有一半...

以效率來看,短期內還是會跑 Debian/amd64 養 MySQL...

另外補充一點,本來是在開啟 gjournal 的情況下用 rsync 把資料複製到本機,結果發生 kernel panic,後來是先複製完再使用 gjournal,這個部份還要到其他機器看看到底是怎麼一回事...

Twitter 離開 Joyeur

今天最大的新聞應該還是 Microsoft 向證交所提出併購 Yahoo! 要求的新聞,不過這種事情也只能看他變化,然後依據變化決定在台灣要怎麼因應。

另外一件事情是 Twitter 離開 Joyeur,搬到 NTT America,也就是說,Twitter 將來會自己建立整個網站的底層。可以預期的是,他們會遭遇到一堆問題,然後想辦法解決,然後再遭遇到其他問題,再想辦法解決,然後發現需要在 Application 層將 MySQL 拆開...

這個轉換的動作應該還會有一個月,或是更久的陣痛期吧...

Ref:Twitter Chooses NTT America Enterprise Hosting Services

用 SSD 當作 MySQL 的儲存空間

Update:原作者拿到硬碟後測試了一天,發現寫入速度不盡理想:24 Hours with an SSD and MySQL

SSD 硬碟應該要列入耗材...

國外有一些先驅已經在測試把 MySQL 的 data 丟上去跑:Thoughts on SSD and MySQL 5.1,這篇裡建議把 sync_binloginnodb_flush_log_at_trx_commit 保留預設打開的狀態 (用 InnoDB 時,如果為了效率會把這兩個都關掉,尤其是後者,有寫入動作時的速度 (INSERT/UPDATE/DELETE) 會差十倍到三十倍),不過我覺得為了減少 I/O 還是要開。另外在 OS Filesystem 層的參數也要注意。

寫這篇才想到 FreeBSD 7.0 有 iSCSI 可以測試,來測看看效率...

最近的幾件事情...

累積太久沒寫,有些議題剛好可以合併起來看...

第一個想到的是 買下,以及在 上看到有人認為 成功是 Computer Science 界的一大退步 ()。

把時間點再往前,拉到 買下 Innobase Oy 及 (Berkeley DB) 兩家公司時一般的反應 (分別是 2005 年十月、2006 二月),以及買下後的進展...

買下 Sleepycat Software 後推出的 Berkeley DB 4.5 多了 Replication 的功能,並且在 Berkeley DB 4.6 對穩定性及大幅度修正。InnoDB 則是不斷的改進穩定度及效率,仍然是目前 MySQL 裡最常被使用的 Transactional Engine。以現在看起來,其實 Oracle 並沒有打算要以這個手段打擊 MySQL。

話題回到 Slashdot 那篇 MapReduce,其實在 comment 有人講得很清楚了:簡單的東西並沒有什麼不好,重點在於能不能解決問題。如果能用簡單的方法解決問題,就不要拿複雜的方法解決,25 年前就發展出的技術並沒有什麼不好。

另外我提一下,最近寫過後才發現 Berkeley DB 其實相當好用 (支援 Transactional Operation 及 Replication),沒人用的原因是 PHP/Perl/Python/Ruby 上的 Library 都沒有把實做所有的功能,目前只有標準的 dbm operation 而已。換句話說,如果你要用這些好用的 Operation 得自己刻 C/C++/Java。由於開發上的問題,很多人寧可用 MySQL 放...

由於 Berkeley DB 看起來很棒 (傳言 的使用者資料都是用 Berkeley DB 為底層架起來的),初期的目標是希望有個 Reliable DBM-style Database,類似 的軟體放使用者資料,透過 TCP connection 與 PHP 端溝通...

Archives