freebsd mysql性能_FreeBSD下提高MySQL使用效率

测试的结论是，FreeBSD现在缺乏稳定而且高效率的Filesystem让MySQL MyISAM使用。 先解释一下现在的环境，有两台Tyan Server，

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

本条技术文章来源于互联网，如果无意侵犯您的权益请点击此处反馈版权投诉

本文系统来源：php中文网