ほとん同一のBlueOnyx 環境をVMware 上に構築した。1つはVMware Server2 上に、もう1つはVMware Player 上に。後者のほうがマシンとしては高性能だから仕方ないのかもしれないが、動作速度に問題はなくストレスを感じずに利用できる。
しかし前者は、サイト定義がたくさんあるとはいえ、動作が遅い。どうやらMySQL あたりがネックになっているようなのだが、確証はない。さらに、WordPress を使っているサイトだったから、キャッシュプラグインなどを試してみるも効果がない。
マシン性能が違うのは十分承知しているが、それでももう少し早いハズだと思い込む。
たしかにVMware Player はいくつものVM が動作しているわけでもないし、それに比べればマシン性能が劣る上にVM がいくつも動作しているVMware Server2 上で、しかもBlueOnyx を介して動作しているわけだから、遅いのはわからないでもないが・・・。
それでもphp-apc を入れるとかそれなりの効果があるものはあった。だが、遅い。どうしてもVMware Player の軽快な動作を観てしまうと、余計にストレスを感じてしまうのは許して欲しいところ。
というわけで、MySQL の設定を変更してみる。きっとキャッシュやメモリをもう少し使ってくれるようにすれば、良い結果を返してくれるはず。
スポンサードリンク
※管理者権限が必要なので、レンタルサーバーでは利用できない
標準設定
# cat /etc/my.cnf [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
設定変更
以下を追記した。
query_cache_limit=1M query_cache_min_res_unit=4k query_cache_size=32M query_cache_type=1
動作確認
キャッシュが有効になっているかを確認する。
mysql> SHOW VARIABLES LIKE "query_cache_%"; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 0 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | +------------------------------+---------+ 5 rows in set (0.02 sec)
有効になっていない。おっと。再起動を忘れていた。
# service mysqld restart Stopping mysqld: [ OK ] Starting mysqld: [ OK ]
動作確認
改めて確認する。
mysql> SHOW VARIABLES LIKE "query_cache_%"; +------------------------------+----------+ | Variable_name | Value | +------------------------------+----------+ | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 33554432 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | +------------------------------+----------+ 5 rows in set (0.00 sec)
有効になったようだ。
最終的に
結局のところ、以下のようになった。確かに動作速度は改善したが、それでも求めるレスポンス速度には遠い。
既にVM の使用するメモリは物理メモリに限定しているのだが、最終手段としてメモリの割当も多くした(VM 内のOS でもスワップは発生していし、極端にロードアベレージも高くない)。
確かにそれでも多少はさらに改善したが、他の似通ったVM より贅沢にリソースを消費し、手入れをしてもそれに見合った速度だとは思えなかった。
そうすると、最終的にはBlueOnyx が・・という話になってしまいそうだ。そして新しいサーバーにすれば解決するということになりそうだ。なぜなら同様の設定で、さらに高速な環境では遥かにレスポンスが良かったから。
これは確かさくらインターネットの公式サイトに記載されていたようなきがするのだが、”可能な限り高速な物理CPU を利用して、さらに多くのメモリを搭載する。これによってディスクIO などを減らし、同一の環境に比べて高速に動作する”という主張にある程度の信頼性を付与する結果かもしれない。
設定例
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 # 2011.09.20 add by casey query_cache_limit=2M query_cache_min_res_unit=4k query_cache_size=64M query_cache_type=1 # 2011.09.20 add by casey innodb_buffer_pool_size = 16M innodb_log_file_size = 2M # 2011.09.20 add by casey set-variable=key_buffer_size=128M set-variable=table_cache=256 set-variable=record_buffer=2M set-variable=thread_cache_size=8 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
# 高速に動作した環境にLVM があったかどうかは不確か。同じような環境を3つの物理マシンで試した。うち2つがUbuntu 10.04 LTS 上の VMware Server2 で、残りがWindows7 SP1 64bit 上のVMware Player 。
# 共通したように感じたのは、VMware Server2 で動作するBlueOnyx 5107R のベースOS であるScientific Linux 6.1 の起動処理の最後のほうがとても遅かったということ。単体でインストールしたScientific Linux 6.1 では感じなかったと思うのだが。
参考文献
- チューニング – データベース ( MySQL ) – 自宅サーバーの構築 – 自宅サーバーでやってみよう!!
- [MySQL]メモリ設定のチューニング: ソフトウェア開発技術者として逝きます (c)てるとみ
- MySQL のキャッシュサイズ変更で高速化
- MySQL のクエリキャッシュを有効にして WordPress を高速化する
- MySQLクエリ結果のキャッシュMySQL|プログラムメモ
コメント