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,這個部份還要到其他機器看看到底是怎麼一回事...

11 thoughts on “FreeBSD 上的 MySQL 效率”

  1. SGI發展的這個XFS除了穩定外 也夠快
    我現在大部份應用都用xfs了
    以前在專放tmp session的地方還有用reiserfs,但不穩定,就放棄

  2. XFS 是 ok, 不過不要使用 xfs_freeze
    死過不少次.. 配合 LVM 特別會出事(@Debian-etch)

    若要使用 LVM snapshot
    倒是建議先 stop service -> remount ro -> create snapshot -> start service

Leave a Reply

Your email address will not be published. Required fields are marked *