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

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 端溝通...

MySQL 在 NetBSD 上的效率

參考:Thread benchmarks,因為 被廣泛應用,所以大家都拿他當作 Thread/Lock/... 的實際效率測試指標。

這個測試結果顯示 輸了一屁股,一定會讓 src committer (大光頭與 Jeffrey Roberson?) 測試 在 AMD64 上跑 的效率,這陣子應該可以在 的 mailing list 上看到相關的討論...

InnoDB 的重大修正

MySQL InnoDB 的 auto-increment 會造成 INSERT 時使用 table-level lock 的 bug 終於修正 (從 2006 年一月就進 MySQL 回報系統的 bug),下個 5.1 的版本 (預定是 5.1.22) 就會包括在裡面:InnoDB auto-inc scalability fixed

這個 bug fix 目前介紹了新的變數:innodb_autoinc_lock_mode,目前有三個數值可以用:

  • 其中 0 是原來的 table level lock 架構 (主要是因為其他原因而需要升級到 5.1.22,但是又不想上這個 patch)。
  • 1 是預設值,在 simple insert 時會改用新的 row level lock,但 bulk insert 時會使用新的 table level lock (要與 row level lock 配合)。
  • 而 2 目前不保證在 statement-based replication 下能夠正常運作 (預設是 statement-based + row-based 混和使用),但現在用 不搞 replication 的很少了吧 :/

無論無何,這是一個重大修正,在大量 INSERT 卻不能 bulk 時會造成的問題終於解決了。雖然最近我都用 開發... XD

MySQL 5.0.37 的 semisync patch

先前 放出 4.0.x 的 patch,並且放出會做 5.0 patch 的消息,本來以回要等上一陣子的,結果剛剛在 Semi-sync replication for MySQL 5.0.37 這裡看到 semisync replication 的 patch 已經在 trunk/ 裡面的消息了,這個 patch 目前指支援 ,不過據他的說法,應該蠻容易 porting 到別的 storage 上:mysql-5.0.37_semisync.patch

另外在 Wiki 上也註明了:

PS:不知道前陣子 幹的事情的人,請參考 寫的兩個 MySQL 的舊「新」聞

Archives