この3代目サーバも稼働後既に2年が経過し、これから死亡の確率が日に日に高くなっていくだろう。ああ、ほんとサーバって可哀想だね。24時間365日動いていて当り前、止まれば文句を言われるのに金はかけてもらえない。俺のメインゲームマシンのように意味もなく新しいパーツを注ぎ込まれるマシンもあるのに・・・
とサーバの侘寂を感じつつ、もうちょっとだけサーバのレスポンスを上げられないかなと思い、このCMS(
Nucleus)のキモであるMySQLのチューニングにチャレンジしてみた。参考にしたのは
mysqlを高速化したいときのチューニング方法。
このサーバの場合、しばらくなんにも設定せずに素のままMySQLを動かしていた。それじゃ芸がないので
ちょっとだけいじってMySQL起動時にパラメタを渡してクエリキャッシュだけは有効になるようにしてある。これだけでもなんとなく速くなったんだけど、サーバのアクセスはどういうわけか集中するときには集中するので、負荷が高いときにより効果的なレスポンスが得られるようイジってみた。
まずはサンプル設定ファイルをコピーする。サンプル設定ファイルは、Vineの場合は/usr/share/mysql/ディレクトリに入っていて、搭載メモリの量別に4種類が用意されている。コメントによると
my-small.cnf -- 64MB以下
my-medium.cnf -- 128MB程度
my-large.cnf -- 512MB程度
my-huge.cnf -- 1〜2GB
ってのが目安のようだ。このサーバは古いマシンだけど一応512MB積んでいるのでmy-large.cnfを使うことにする。
このサンプルを/etcディレクトリにmy.cnfとしてコピーする。
# cp /usr/share/mysql/my-large.cnf /etc/my.cnf
あとはこのmy.cnfを修正してやる。本当はボトルネックを調べて修正するのが正解なんだろうが、取り敢えず該当しそうなところを修正してみる。修正箇所は以下のとおり。
table_cache = 256 -> 1024
thread_cache = 8 -> 32
query_cache_size= 16M -> 32M
innodb_buffer_pool_size = 256M -> 384M
innodb_flush_log_at_trx_commit = 1 -> 2
この設定でクエリが遅くなるリクエストが発生したらLogを取るよう、この設定ファイルの最後に
long_query_time=3
log-slow-queries=/var/log/slow.log
を追加して設定ファイルの修正は終了。あとはMySQLを再起動しておしまい。
# /etc/rc.d/init.d/mysql restart
innodb_log_file_size = 64M を 128Mに変更したらエラーでMySQLが起動しかなかったのは不思議。
効果があるのかは今後の様子を見ないと断定は出来ないけれど、一時期にアクセスが集中したときの処理スピードは上がったように感じる。気のせいかも知れないけれどね。まぁ、設定方法を少し覚えたってことだけでも良しとしよう。
といいつつ、普段いじらないサーバをいじり始める時期はどういうわけか死期が近いときと重なる場合が多いので、今回もそろそろヤバいのかも知れん。代替の準備をしておかないとなぁ。次のサーバはAtomかな？
MySQLの設定をちょっとだけ見直す
