当前位置:Gxlcms > mysql > FreeBSD下提高MySQL使用效率

FreeBSD下提高MySQL使用效率

时间:2021-07-01 10:21:17 帮助过:27人阅读

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

linux

人气教程排行