文章是转载来的，作者从用词上看应该是港台那边的,可惜不知道名字！

　　测试的结论是，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，这个部份还要到其他机器看看到底是怎么一回事。

评论 (0) All

登陆 还没注册？