久しく（といっても多分１ヶ月くらい？）ブログサイトをほったらかしにしていて、
でもその間ローカルではマシンを使っていて、Software updateなどで
セキュリティアップデートなどがでていれば、それを素直にあてて再起動して
いたわけなのですが、今日久しぶりにブログサイトを覗いて、動いていない
のに気が付き、あわてふためきました（汗）

 

どうも２月末あたりにMacOS X 10.4にあてた、セキュリティアップデートが
勝手にapacheの起動プログラムを書き換えていたようで（いや、勝手に
書き換えているのは僕の方なのですが、笑）、

 

　　/usr/sbin/apachectl -> /usr/local/apache2/bin/apachectl

 

とシンボリックリンクになっているべきところが、2/26の時点で新しい実体に
置き換わってました。おかげで、古いhttpd1.1.2を起動しようとして、
ｐｈｐ４などの環境が変わっているおかげで、エラーで起動が失敗していた
様子。

 

MacOS Xをサーバに使っていると、GUI環境で作業がいろいろできるという
便利な反面、システムが標準で使っているLinux系の様々なプログラムを
勝手に最新版に置き換えたりしていると、予告も無くいつのまにか、システム
アップデータが上書きをする、ということがあるんです。

 

MacOS X自体はUnix（風OS）としても使えるので非常に便利なんですが、
このへんは要注意です。

 

ということで、ひとしきり悩んだ後、古いhttpdで上げようとしていることに気が付き、
あらためて/usr/sbin/apachecltをapachectl.orgとしてリネームしてから、
/usr/local/apache2/bin/apachectlにシンボリックリンクを張りなおしました。

 

いやー、参ったまいった。(_ _;;

ここのところ急にwebサーバへのスパムが急増しています。

主としてtrackbackスパムなので、このサイト(Xoops)ではブログモジュールであるwordpressのサブモジュールtrackbackのスパム対策機能を使っていたのですが、もっと手前で、apacheがリクエストを処理する前に退治できないものか悩んでました。

友人に相談したところ、

　　mod_security
　　トラックバックスパムよけにも使える「mod_security」(GiGaZine2006/7/13記事)

なるものがあることを教えてくれました。

mod_securityは非商用利用に限ってフリー版が使えます。上記GiGaZine記事は少々古く、現時点(2008/2/17時点)では、安定板として2.1.5, 開発版として2.5.0-rc4というのが配布されています。

　　2.1.5および2.5.0-rc4アーカイブ

なんかよさげなのが、web版の管理コンソールがあるからで、ルール、ブラックリストの管理やアタックの状況監視が簡単にできそうな点です。

ちなみに現サーバの環境を書いておきます。

• マシン：PowerMac G4改(500MHz)
• OS ：MacOS X 10.4.11
• Webサーバ：Apache 2.2.8（10.4標準の1.3から入れ替えてます）

で、さっそくインストールですが、./configure, make, make install, とは行きませんでした（涙）ビルドに必要なライブラリが無いようです。

1. libpcrc
2. libapr
3. libaprutil
4. liblua

libpcrcはperl用の正規表現処理ライブラリのようで、ここからダウンロードしてインストール。またlibapr, libaprutilはapacheプロジェクトのライブラリで、調べたところちゃんと/usr/libに以下のようなものがあります。

/usr/lib/libapr-1.0.2.7.dylib
/usr/lib/libapr-1.0.dylib
/usr/lib/libapr-1.dylib
/usr/lib/libaprutil-1.0.2.7.dylib
/usr/lib/libaprutil-1.0.dylib
/usr/lib/libaprutil-1.dylib

しかしどうもこれらの*.dylibというのはMacOS X用のダイナミックライブラリのようで、素からmod_securityをビルドするにはどうもconfigureはこれらを使ってくれないみたい。なので下記のサイトからlibapr, libaprutilを持ってきて新たにビルドしました。

　　The Apache Portable Runtime Project


現状最新版は下記の通りです。

1. apr-1.2.12.tar.gz
2. apr-util-1.2.12.tar.gz
3. liblua-5.1.3.tar.gz
4. libxml2

libaprは./configure, make, make installとやると、/usr/local/apr/libにイメージがインストールされます。またlibaprutilは./configure –with-apr=
, make, make installとやって、おなじく/usr/local/apr/libにインストールされます。

libluaについては、./configure macosx, make, make installです。

さて、これでようやくmod_securityのインストールが出来ます。

　% ./configure –with-apr=
–with-apu=

とやります。あとはmake, make installですね。
とりあえず無事ビルドが完了し、一番基本の設定をしてからapachectl restartしました。

とりあえずエラーも無く動いているようです。しかし実際ちゃんと検査をしてくれているのか？続きはまた次回！

Xoopsの高速化の第一弾として、MacOS X 10.4のウェブサーバをapache1.3から2.2.8へアップしました。あわせてphpもphp4.4.7から4.xの最後のバージョン、php4.4.8へアップしました。
さて、次の作業としてphpの高速化を図ります。
phpを高速化するためのプログラムがいくつかあるようですが、ここは国内のphpソリューションベンダとしては最大のZendが無償提供している"Zend Optimizer"を使ってみることにしました。
　　Zend Optimizer
現在Zend Optimizer3.3.0英語版が最新版で、MacOS Xに関してはユニバーサルバイナリー版が提供されています。嬉しいですね！MyZendにユーザ登録をし（無償）ログインするとダウンロードできます。ちなみに日本語ドキュメントも提供されていますが、こちらはひとつまえの3.2.0のものです。まぁさほど違わないでしょう。
インストールは超簡単。ダウンロードしたパッケージを解凍するとinstall.shというシェルスクリプトがあるので、これをターミナルから実行するだけです。
実行により、Optimizer一式が/usr/local/Zend以下にインストールされます。またphpの初期化ファイル、/etc/php.iniの最後にOptimizerの設定が追加され、/usr/local/Zend/etc/php.iniに移動されます。あわせてphp.iniのシンボリックリンクが/etc以下にできます。
無事インストールが終わったら、インストーラがapacheの再起動をしてくれます。これで完了です。

さて、無事オプティマイザーが組み込まれているかどうか確認します。

phpinfo()をつかってphpの環境変数を表示したときに、下記のようなバナーが表示されるはずですが、そこに"Zend Optimizer v3.3.0″という文字が現れれば、無事組み込まれています。

うちのサーバはPowerMac G4 500MHzという非力なマシンなのですが、Xoopsという便利ではあるけれども非常に重いCMSを使っています。いろいろとモジュールが揃っていたり、インターネットを探せばたくさん情報もあるし本も多く出ているのでなかなか他に移行できないのです。

 

が、いよいよもってこの重さに耐え切れず、また先日Apacheの最新版, apache2.2.8がリリースされた というニュースを見て、ぼちぼち高速化を進めることにしました。

 

まずサーバの構成を確認します。俗に"MAMP"というものですが、Living-e AGが最近配布している超お手軽パッケージではなく、地道に各パッケージごとに手動で入れています。理由としては、MAMPパッケージに含まれるアプリケーション以外のものを入れたいときに、格納場所などが特殊なところになっていたりするとやっかいだからです。

 

• OS : MacOS X 10.4.11 (Tiger)
• Webサーバ : Apache 1.3.3 (Tigerに標準のもの)
• php : php 4.4.7 (Xoops2.0.6jaに合わせて)
• MySQL : mysql-standard-4.0.25-apple-darwin7.9.0-powerpc
• CMS : Xoops 2.0.6ja

phpやMySQLが非常に古いバージョンを使っている唯一の理由はXoops2.0.6を安定して走らせるためです。（ひょっとしたら最近だとphp5にMySQL5で動くのかな）

 

一気に全てをアップグレードするのはリスクが大きすぎるので、まずは最もXoopsから遠く、直接的な関係のないapacheから。

 

現在apacheは1.3系とスレッド処理などで負荷処理が賢くなった2.x系があります。

MacOS Xでは、10.4が1.3系、そして新しい10.5が2.x系（現時点で10.5.2には2.2.6が入っています）となっています。なので、「OSを10.5にすりゃいいじゃん！」という気がするのですが、10.5はG4 800MHz以上（たしか）にしかインストールができず、うちのマシンには10.5を入れることが出来ないのです。なので、OSは10.4のままで、必要なアプリのみ手動でアップデートするしかないというわけです。

 

さて、Linux等と違いMacOSの場合、おいそれと簡単には./configure, make, make installとはいかないという事情があります。apacheの場合はそれ自身がMacOSの重要な機能をつかさどっている一部になっているので、その部分を無視して入れてしまうとMacOS側の機能が使えなくなってしまいます。特に問題なのは「Webファイル共有」関係。詳しいところは分からないのですが、例えばLinux向けのapacheディストリビューションには含まれない"mod_bonjour"というモジュールが組み込まれています。

 

またapacheの起動に関しても、rcなどではなく、/etc/hostconfigにWebサーバの起動・停止フラグを記述し、それを見て/System/Library/StartupItems/Apache以下のスクリプトが走るようになっています。ちなみにこれらのMacOS Xとのからみを完全に無視していれることも可能ですし、ちゃんと動きます。ができるだけMacOS Xの作法に従ってエレガントに入れておいたほうがあとあとややこしくなくていいかと。

 

さて、とりあえず実行モジュールを準備する上で一番の問題は上のmod_bonjourをどうするか？という点。Apacheサイトの説明によると、1.3系から2.x系への移行でモジュールとのAPIが大幅に書き換えられ、1.3系のモジュールをそのまま持ってきても動きません　とのこと。

 

なので、その他の多くのモジュールは2.xに含まれるソースからビルドしても問題ないわけですが、mod_bonjourがない。ところでMacOS Xの最新版である、10.5 (Leopard)に標準でバンドルされるapacheは2.2.6なのです。2.2.6と2.2.8の差異はわずかなので、PPC版のMacでMacOS X 10.5が入ったやつがあれば、これから少なくともmod_bonjourだけひっぱってきてインストールしてやれば動きそうな気配です。

 

幸いにもPowerBook G4 15inch (late2006)に10.5を入れたものがあったので、こいつからひっぱってくることにしました。

• /etc/apache2 （設定関係の入っているフォルダ。1.3では/etc/httpdでした）
• /usr/libexec/apache2 (mod_*の入っているフォルダ。1.3では/usr/libexec/httpdでした）
• /usr/include/apache2 (ヘッダファイル関係。実行時には直接は必要ありませんが）
• /usr/sbin/apachectl, httpd （apache2.2.6の制御アプリと本体）

ためしに、そのままごっそりコピーしてきて、ただし/usr/sbin以下の2つのファイルだけは現行の1.3と重なっていますので、上書きしてしまっては大変ですから、オリジナルをapachectl1.3, httpd1.3にリネームして、2.2.6のものをapacheclt2.2.6, httpd2.2.6として同様にコピーし、MacOS Xが起動時に期待する名前となるようシンボリックリンクを張ってから起動してみます。

 

% ln -s ./apachectl2.2.6 ./apachectl

% ln -s ./httpd2.2.6 ./httpd

 

これで、だめもとでapachectl startをかけてみます。

が、見事撃沈。予想はしていましたが、ダイナミックリンクライブラリ関係も大幅に新しくなっているようで、エラーが出るライブラリをひとつひとつ10.5からコピーしてきましたがきりがありません。早々にLeopardの2.2.6を動かすという甘い考えは捨てて、apache本家のソースアーカイブからビルドすることにしました。（これにより必要なダイナミックライブラリも作られます）幸いにも本家ソースはそのままMacOS Xでビルドできるようになっているので、./configure, makeでおしまいです。

さて、ここで普通ならばmake installとやりたいところですが、標準のapacheがインストールされる場所とMacOS Xでは場所が違います。さて困った、どうするか。

しかし幸いにもapache2のインストール先は、ダイナミックライブラリを除き、/usr/local/apache2以下に設定ファイルなども含め全て集約されるので、とりあえずmake installでインストールしておき、あらためて必要なファイルをコピーして移動するか、シンボリックリンクを張ることで対応することを考えます。ちなみに対応関係は以下のとおりです。

	MacOS X	apacheオリジナル
実行イメージ	/usr/sbin	/usr/local/apache2/bin
設定ファイル	/etc/apache2	/usr/local/apache2/conf
モジュール	/usr/libexec/apache2	/usr/local/apache2/
コンテンツ	/Library/WebServer/Documents	/usr/local/apache2/htdocs

MacOSが期待する場所へあとでシンボリックリンクを張っておけば大丈夫でしょう。またいっぽうで上記でビルドしたapachectl, httpdはapacheデフォルトのパスにhttpd.confなどがあることを期待するので、そちらにリンクを張ります。モジュール関係、ログファイル、コンテンツファイルの場所に関しては、httpd.confと、あと2.xから増えた./conf/extra, ./conf/otherディレクトリ以下にある追加設定ファイルに記述されているのでこれらを書き直せば問題ありません。

 

こういう付け焼刃的なやり方をせず、きちんと見るべき場所、インストールされるべき場所を指定してビルドするときは、apacheのconfigureのマニュアルをご覧下さい。

 

1.3のhttpd.confと、MacOS X 10.5に標準で入っていた2.2.6のhttpd.confの中身を良く見比べて、1.3の方で手動で設定している部分を転記します。

 

終わったらapache -vとか、httpd -vとかやってちゃんと2.2.8の実行イメージが見えているかを確認したうえで、apachectl startをします。

 

これで無事入れ替え完了！

 

となればよかったのですが、xoopsが使っている肝心のphp4.4.7のモジュール、php4_mod.soが動きません。php4のサイトを見ると、どうやら2.x系向けに作り直してやらねばならない様子。しょうがないのでphpのサイトから、4.4.7、ではなく、つい最近リリースされた最新版の4.4.8を持ってきて、

 

./configure –with-apxs2=/usr/local/apache2/bin/apxs –with-mysql=/usr

 

とかやったように思います（汗）

追記：

その後いじってると、mb-string関係の機能がごっそり落ちていたので、ブログで記事がアップされない、などの不具合が出ました。以下のスクリプトをconfigure.shという名前で保存し、chmod 555 configure.shとしてビルドしたらうまく動くようになりました。手抜きはいけません、手抜きは（汗）

#!/bin/sh
./configure \
  –with-apxs2=/usr/local/apache2/bin/apxs \
  –enable-mbstring \
  –enable-mbregex \
  –enable-zend-multibyte \
  –with-xml \
  –with-mysql

これで/usr/local/apache2/modules/libphp4.soが出来るので、これを/etc/apache2/httpd.confのモジュールがロードしてあるところの下のほうに下記を追記し、

#LoadModule fastcgi_module     libexec/apache2/mod_fastcgi.so
LoadModule php4_module        /usr/local/apache2/modules/libphp4.so　←これを追加

<IfModule !mpm_netware_module>

さらに、/etc/apache2/other/php4.confというファイルを以下の内容で作り（同じ場所にあるphp5_mod.confからコピーして作ります）

<IfModule php4_module>
        AddType application/x-httpd-php .php
        AddType application/x-httpd-php-source .phps

        <IfModule dir_module>
                DirectoryIndex index.html index.php
        </IfModule>
</IfModule>

あらためて、apachectl startを実行すると。。。お！無事動いています。

とりあえずいくつかあるバーチャルホストでxoops、Drupalなどの動きを確認してますが、いまのところ問題なく動いているようです。

次はｐｈｐの高速化か、MySQLだなぁ。。。

追伸：

新しいApache2.2.8の本体をMacOS Xが期待する場所に直接おかず、シンボリックリンクにしたのにはわけがあります。apacheはMacOS Xの機能の一部になっているので、ソフトウェアアップデートで上書きされてしまう可能性があるからです。ソフトウェアアップデートを実行したがために上書きされてしまっては元も子もないので、シンボリックリンクにしておき、ソフトウェアアップデートが上書きするのはリンクのみにしようとしたわけです。これならアップデート後、おかしくなったらリンクを確認し、実態に置き換わっていたらあらたえてリンクを張りなおせばオッケーです。

追伸２：

apache1.3をapache2.2.8に入れ替えた結果ですが、残念ながら劇的に応答が速くなった感じはありません。ただまぁ、アクセスが集中することがあれば、威力をきっと発揮してくれることでしょう（汗）

以前から気になっていたのですが、なかなか時間が取れなかったのと、そもそもの根本原因を突き止めきれなかったのでほったらかしにしていたdaemontoolsの負荷の問題がようやく解決しそうです。

MacOS X 10.4 (Tiger)をwebサーバやらメールサーバに使っているのですが、qmailを使うときに定番の、プロセス監視プログラム"daemontools"が異常にCPUの負荷を食うのです。

そのおかげで、ApacheからMySQLへのアクセスが異常に遅くなりタイムアウトする事しばしばで、ブラウザでページを見たときにページが表示されないという状況が多々発生し、サーバとしてはまったく使い物にならない状況でした。

なので、マシンを再起動した後にはかならずsvscanbootやらsvscanやら、superviseなどをいちいち全部手でkillし、とりあえず運転をしていたのですが、これではdaemontoolsを使っている意味が全くありません（汗）

たぶん何か問題があるはず、と思い、いろいろと調べていたのですが、まさかTigerのカーネルにバグがあるとは思いもよりませんでした。サーバとかではなく、普通の個人ユースでは問題にならないはなしですもんね。

ひょんなことで、知人の方の日記でその事を知り、「そうそう！まさにそれ！」と飛びついたのでした。

どーもはなからTigerを疑う事をしなかったので、見つけきれなかったようです。

以下のURLによると、"named fifoのPOLLINが常にPOLLNVALを返すので、daemontoolsはスリープする事無く、CPUリソースを食いつぶしながら延々とループを繰り返す"のだそうです。

supervise broken on MacOS 10.4 (Tiger)

なるほどー。svscan.cのソース最後の方にあるsleep(5)をだめもとでsleep(30)にしてみましたが、なんの効果もなかった訳だ（汗）

さっそく/package/admin/daemontools/compile以下で

% make clean
% make

してから、/package/admin/daemontools/command以下にある実行イメージを全て入れ替えて、daemontoolsの再起動。

% /package/admin/daemontools/command/svscanboot &

その後、アクティビティモニタでCPU負荷を見てみると、daemontoolsを動かす前と動かした後で殆ど負荷の高さに変化が見られません！ばっちりです！

これでようやく再起動したときや、UPSがサーバを再起動したときにサービスがきちんと復旧できそうで安心しました。

　　「人生は毎日が勉強」

といいますが、xoopsサイト運営に付いても同じ事が言えるようです。

　　「Webサイトは毎日機能強化」

　一通りサイトの形ができたので、当面コンテンツ作りに専念しようと思ってたんですが、やりはじめると、「あ、これはここにメニューを追加したいなぁ」とか「ここにリンク追加のボタンを追加したいなぁ」と、とめどもなくやりたいことがでてきて、結局コンテンツを作りながらサイトそのものの機能強化も併せて実施しているような状況です。

　さて、先日トップページに「このサイトについて」のカスタムブロックを作成して設置したんですが、いつも表示しておくのもスペースがもったいないので、左側のメニューに追加する事にしました。

　必要なときに読めればいいですからねー。

　こういった任意のブロックはXoopsのカスタムブロックで作っちゃうのが早いんですが、このカスタムブロックを表示するには、いずれかのモジュールに割当をしないとだめですよね。とりあえず「トップページ」に割り付けをしてたんですが、メニューに表示をするには、カスタムブロック単独では無理。さてどうしたものか。。。

　いろいろと調べてると、noneモジュールってのを見つけました。

　noneモジュールってのは、何の機能も持たないモジュールとしてXoopsに追加できる必要最低限のコードのみを持ったモジュールです。このnoneモジュールはモジュールなので、Xoopsにモジュールを追加した後、「none→このサイトについて」てな感じで名前を変更してやれば、メニューに「このサイトについて」が追加され、これをクリックすると、白紙のページが表示されます。このモジュールに先ほどのカスタムブロックをアサインしてやればいいわけです。

　さて、とりあえずこのnoneモジュールをXoopsのmodulesディレクトリにコピーします。あとあとメニューに追加されたときに、noneモジュールへのURLが

http://www.sailweb.net/modules/none/

になってしまうので、これはかっこよくない！なので、ついでにディレクトリ名も変更する事にしました。
単純に

modules/none/

を

modules/about/

にしてやればいいんですが、これだけだと管理画面でアイコンが出てきません。それでnoneモジュールを構成する以下のファイルのxoops_version.phpファイルを編集します。

// change
$modversion[’name’] = ‘NONE モジュール’;
$modversion[’dirname’] = “none”;

このnoneをaboutに変更してやります。

　これでXoopsの管理画面からモジュールの追加をしてやると、無事noneモジュールの追加が完了です。管理画面のモジュール管理画面にて、noneモジュールの名前をnoneから「このサイトについて」に変更し、メニューでの表示順序を1にしておきます。（これで「ホーム」の下に表示されます）

　さてモジュールを追加したら、忘れずにゲストへのアクセス権減を追加しましょう。

　最後に「このサイトについて」を記述したカスタムブロックを、このnoneモジュールの中央真ん中へ表示するよう割り付けします。これでおしまいです。

　うむ、なかなかいい感じ。

　Xoopsの管理画面で何か設定を変更したりした際に、それを実行する際のボタンが画面の下に表示されます。たとえば下記のような感じ。

 

 

　だいたいが「キャンセル」「送信」という場合が多いですが、いったいこの「送信」ってどういう意味なんでしょうね。元々の英語版での文字列は"GO"です。GOならば意味がピンと来ます。こういう場合の意味は「実行」です。ところがなぜか、日本語版では、何かを決定する場合のボタンの文字列が全て「送信」になってます。なぜこのような文字に訳してしまったのか、不思議で仕方ありませんが、僕としては非常に気に入りません。ここは「実行」あるいは「決定」であるべきです。

 

　そこで、これを変更する事にしました。Xoopsの日本語モードであちこちに表示される「送信」文字列は、

{xoops_dir}/language/japanese/global.php

で定義されています。

define('_GO','送信');
define('_NESTED','ネスト表示');
define('_NOCOMMENTS','コメント非表示');

上から１７行目に肝心の「送信」文字が設定されている所がありますので，これをテキストエディタ等で変更してやればOKです。

define('_GO','実行');

　終わったら忘れずに、システム管理画面の「モジュール設定」で「システム管理」モジュールの更新を忘れずに実行しましょう。（そうしないと、変更が反映されません）

 

　「送信」という意味合いは、このXoopsという管理システムを作ったか、あるいは中身とその動作を良く理解している人間からすれば、このボタンを押す事で，内部でどのような処理が実行されるのか，が想起される表現なのかも知れません。

 

　しかし、多くの利用者は中身の動きについてよく理解している人はまれで、殆どの人の理解はもっと直感的です。

「送信」ボタンを押す　→　ただちに変更される。

間でどのような処理がなされ、何がおきているかなど、まぁどうでもいいことです。例えば車を運転しているときに、ブレーキを踏む行為を考えます。普通は

「ブレーキを踏む」　→　「車が減速する（とまる）」

という具合に、行為と結果が単純に結びついています。もしブレーキペダルにラベルをつけるとすれば、「減速する」とか「停止する」といったところが妥当でしょうか。ところが車の設計者は、ブレーキペダルを踏む事によって中で何が起きているか知っているので，つい「油圧を高める」といったラベルをつけてしまうかもしれません。「送信」という訳にはそういった意味あいがあるように感じます。

 

　ユーザからすれば、極端な話中身の動作はどうでも良く、自信が実行した行為によって、結局何が起こるのか？が直感的に分かれば良いし、むしろ複雑なシステムでは極力中身の動きを意識せずに操作できるように、外側からそのシステムを操作するための手足、インタフェースをデザインする必要性があります。これをユーザサイドから見たときに「インタフェースの透明化」、システムサイドから見たときには「機能の隠蔽（あるいはカプセリング）」と言います。「透明化」の意味する所は、いまこのボタンを押したら、結果として何が起こるか瞬間的に分かるようにまるで向こう側がガラス張りのように見通し良くなっている、ということであり、「隠蔽」とは、ユーザが中を見なくても良いよう、外側のインタフェーを分かりやすくして、中の動きや機能を見えなくする、（そして混乱を少なくする）ということを意味します。

 

　このような意識が少しでも頭の中にあれば、ちょっと工夫でシステムの誤操作や操作上の混乱を少なくする事ができます。今後ますます、世の中にある道具や機械、システムが複雑化していくのに伴って、これまで以上に設計者／管理者はこのようなインタフェースの透明化を明示的に意識する必要があるでしょう。Xoopsの「送信」の問題は些細なことではありますが、まだまだそんな些細な事にさえ注意が払われない道具が氾濫しており、とても気になります。■

 

↓↓↓　「いいね！」と感じたら、クリックしてBlogRanking投票お願いします(^o^)/

pingテスト２

テスト１

 

先日mysqldの調整をしました。
まぁ調整と言っても、システムのメモリサイズに応じて用意されている設定ファイルのテンプレートを変更しただけなのですが、それでもまだ遅い感じなので、個々のパラメータも若干弄ってみる事にしました。

 

最初に当方環境を書いておきます。

• MySQL : MySQL 4.0.25
• Apache: Apache 1.3.33

かなり古いですね（汗）
MySQLに関しては、xoopsの関係で4.1にあげずに使っています。またApacheに関しては、ほんとはApache2にしたいのですが、MacOS Xで標準インストールされているApacheと共存させるのにけっこうめんどくさいので、そのまま使っています。

 

まずmysqldです。
教科書的なことを言えば、調整に際し、以下のログ

/usr/local/mysql/data/slow.log

を見て、どのテーブルに対する、どのSQLコマンドが遅いのか？を確認してから適切なパラメータを調整する必要がある訳ですが、今回はそこまではせずに、直接webページを表示してみて、表示速度に変化があるかどうかで簡単に確認する事にしました。

 

まずmysqldの調整にあたって下記のサイトを参考に致しました。

 

　　blogのチューニング

 

上記サイトでは、my.cnfの下記のパラメータの調整に付いて説明してあります。

query_cache_limit=1M
query_cache_min_res_unit=4k
query_cache_size=32M
query_cache_type=1

このうち、当方のmysqldではquery_cache_min_res_unitのパラメータが存在しないふるいバージョンの様でエラーとなってしまいましたので、これは指定しませんでした。その他を下記のように設定しました。

query_cache_limit=4M　←1Mから変更
query_cache_size=64M　←32Mから変更
query_cache_type=1

さて、これでmysqldを再起動します。

% /usr/local/mysql/support-files/my.server stop
% /usr/local/mysql/support-files/my.server start

うん、また少し早くなったようです。いったん描画を始めると早いのですが、一番最初に画面に書き始める所でまだもたつきます。xoopsの画面は、すべてMySQLに格納されたデータを毎回SQL文で検索して読み出してからhtmlを生成するので、MySQLへのSQL文実行に関わる部分を調整してみるのが効果の期待できるところなのですが、それ以外にもアフィリエイト関係でその他のサイトのテキストやバナーイメージを引っ張ってきているので，サイトのサーバの調整だけでは力の及ばない所があるというのが実際の所です。

 

その他に何かmysqlに対してできることはないか、と調べていると、mysqldを起動するときのパラメータとして

–skip-name-resolve

を指定するのが効果ありそうです。–skip-name-resolveは、mysqlがアクセスしてきたクライアントのIPアドレスからホスト名を引く処理をスキップするオプションで、当方立ち上げているxoopsのサイトでは、mysqldにアクセスしてくるクライアントは、基本的に同じマシン上で動いているwebサーバであるApacheとxoopsを構成しているphpのみです。従っていちいちmysqldへアクセスがあるたびに名前解決をする処理は必要ありません。従って、このオプションを

/usr/local/mysql/support-files/mysql.server

スクリプトの、起動時のパラメータ指定の所に追記しました。（赤字の所が追記部分）

case “$mode” in
’start’)

# Start daemon

if test -x $bindir/mysqld_safe then

# Give extra arguments to mysqld with the my.cnf file. This script may
# be overwritten at next upgrade.

$bindir/mysqld_safe –datadir=$datadir –pid-file=$pid_file –skip-name-resolve >/dev/null 2>&1 &

# Make lock for RedHat / SuSE

if test -w /var/lock/subsys then
touch /var/lock/subsys/mysql fi else echo “Can’t execute $bindir/mysqld_safe from dir $basedir” fi ;;

さて取り敢えずの所、MySQLでできる調整はこの辺までです。

 

さて、もう一つ関係しているのが、webサーバ"Apache"です。
Apacheに関しては、下記の@ITのサイトを参考にしました。

 

　　第15回　Apacheパフォーマンス・チューニングのポイント
　　最終回　Apacheパフォーマンス・チューニングの実践

 

Apacheの設定ファイルは下記にあります。

/etc/httpd/httpd.conf

上記のサイトの説明を参考に下記を変更しました。これらは主として、Apacheの子プロセスに関する設定です。

MaxClients 300　←150から変更
MinSpareServers 5　←1から変更
MaxSpareServers 10　←5から変更
MacRequestsPerChild 1000　←100000から変更

MaxClientsは同時アクセスできるクライアント数の上限です。すなわち、最大で300の子プロセスhttpdが起動する事になります。そしてこれらが個々にクライアントとセッションを張るので、イコールコネクションの最大数となります。

これは実際に仕事をするプロセスですが、これ以外に子プロセスが起動するのに生ずるオーバーヘッドを抑制するため、余分にプロセスを起動して待機しています。これらの数を指定するのがMinSpareServersとMaxSpareServersです。MinSpareServersは最小待機プロセス数で、MaxSpareServersは最大待機プロセス数です。通常は待機プロセスとしてMinSpareServers分のプロセスが待機していますが、この待機プロセスは稼働状況に応じて最大で10まで増えます。結果として、システムで起動するhttpdの数は

MaxClients + MaxSpareServers = 300 + 10 = 310

となります。これらの値はCPUの負荷とかメモリの利用状況をみながら調整する必要があります。

あと、MaxRequestsPerChildは、起動している子プロセスの生存期間です。あまり同じプロセスが起動しっぱなしになっていると、メモリリークなどが発生したりしてシステムに悪い影響を及ぼす可能性もあります。したがって、或る程度クライアントの処理をこなしたらプロセスに終了してもらい、新たに別の子プロセスを起動するようにするためのものです。当初100000という、かなりのセッションをこなせるようになっていましたが、これを1000回処理したら終わるように変更しています。

変更が終了したらApacheを再起動します。

% apachectl restart

さて、ここまで変更が終わったらサイトにアクセスしてみます。

 

うんうん、劇的といえるほど早くはなってませんが、それでもだいぶ改善されたように思います。まだ若干最初の表示開始までの時間がかかっているのが気になりますが、また改めて調整をして行きたいと思います。■

 

↓↓↓　「いいね！」と感じたら、クリックしてBlogRanking投票お願いします(^o^)/

このサイトも、ブログの部分はとりあえず枠組みができあがったので、ぼちぼち日記も（なるべく）毎日書くようにしています。

 

そこそこコンテンツも増えてきたら気になるのが、自分のサイトがGoogleとかの検索サイトでちゃんと検索できるようになっているか？ということです。 一応、最初の頃にGoogleとYahoo!に関しては検索登録をしていたのですが、ここんところいくつか書き加えた記事が検索にひっかかるようになっているか調べてみました。

 

一般的に検索サイトのbotが探しにくるにはしばらく時間がかかるのですが、Xoops Analyzerでログを見ていると、定期的にGoogleやYahoo!などのbotがちゃんと見にきてくれているようです。 ところが、Googleで検索をかけてみると、トップページしか出てこない！肝心の日記記事はまったくひっかかりません。 Webをぐぐってみると、どうやら検索エンジンは、URL表記が動的表記よりも静的表記をより好んでクロールしてくれるようです。

 

インストールしたままのwordpressの各日記記事へのURLは以下のようなフォーマットになっています。

    http://www.sailweb.net/modules/wordpress/index.php?p=96 　※1

つまり、index.phpというphpのスクリプトに、記事番号96を与えると、ID=96の記事が表示されるという寸法です。このようにphpやperlなどのスクリプトにパラメータを与えて、表示される内容を動的に生成しているページをbotはどうも苦手としているようです。

 

またこのような動的生成ページのURL表記を俗に「動的表記」と言います。

 

いっぽう、Googleなどの検索サイトのbotが好む静的表記は、以下のような表記です。

    http://www.sailweb.net/modules/wordpress/2007/04/23/96/   ※2

つまり、URLを見た限り、一見/2007/04/23/96/index.htmlといったようなプレーンなhtmlファイルへのリンクです。

したがってせっかく見に来てくれたbotにきちんと情報を持っていってもらうには、※1のような表記を※2にしてやる必要があります。

 

さてそのやり方ですが、単純な方法は、動的に生成されたページをあらためて静的なhtmlファイルとして別に保存してやる、という方法ですが（たとえプログラムなどで自動処理をしたとしても）手間がかかる上、同じ情報がひとつのwebサーバに２重に存在するという点であまりよろしくありません。ディスクスペースを２倍消費するし、管理も２度手間になります。

通常はこのような人海戦術的単純戦略はとらずに、webサーバのURL書き換え機能を利用するのが常套手段です。例えば多く使われているwebサーバであるApache（アパッチ）には、mod_rewriteというモジュールが組み込まれていることが多く、これを使ってURLの書き換えを比較的簡単に行うことができます。mod_rewriteモジュールは大手のフリーのブログサイトであればだいたい組み込まれていることが多いようです。

またApacheのmod_rewriteモジュールの使い方については、例えば下記のようなサイトを参照されると良いでしょう。

  mod_rewriteリファレンス

mod_rewriteの基本ですが、

Apacheのsystem configurationファイル: /etc/httpd/httpd.confなど、もしくは

ユーザディレクトリの設定ファイル: <任意のユーザwebドキュメントディレクトリ>/.htaccess

のいずれかに、mod_rewrite機能をonにするコマンドと、書き換えのルールを記述してやれば使えるようになります。

 

httpd.confはApache全体のシステム設定用のファイルで、こちらにmod_rewriteの記述をしてやる方が.htaccessへ記述するよりも処理の負荷が低いらしいです。しかしながら、当然自分が管理しているサーバでなければhttd.confはいじれません。フリーや商用のブログサイトに間借りしている場合は.htaccessを使うことになります。

今回、僕はhttpd.confへの記述追加を試みたのですが、後述しますがwordpressが自動生成してくれるmod_rewrite用のコードが、.htaccess用に記述されているようで、単純にこれをhttpd.confへ追記しただけではうまくいきませんでした。なので、以後は.htaccessへ追記するやり方を書きます。

 

１．httpd.confの確認

この項目は、ご自身がサーバを管理していてhttpd.confをいじれる人のみが必要な作業です。外部サーバを借りている場合は、殆どのケースすでに設定がなされているケースが多いようなので、次に進んでください。

まず、httpd.confで、ユーザディレクトリで.htaccessが使えるようになっているかどうかを確認しましょう。今回はwordpressのモジュールにアクセスがあった場合にmod_rewriteが動けばよいので、Xoopsのwordpressモジュールのインストールディレクトリを<wp_home>だとして、以後説明をします。<wp_home>はご自身の環境にあわせて読み替えてください。

まず<wp_home>にあとで設置する、.htaccessファイルをapacheがきちんと読んで処理してくれるよう、<wp_home>での.htaccess利用を許可する必要があります。これは、httpd.confの中に以下の行を追記することで使えるようになります。

<Directory <wp_home>>

    AllodwOverride all

</Directory>

なお、これを指定することで、ユーザ側が.htaccessに必要な処理を記述することで、全ての処理をオーバーライドできるようになるので注意が必要です。なので、<Directory *>などとせず、ほんとに使いたいディレクトリ（今回はWordpressのインストールディレクトリ）のみを明示的に指定するようにしたほうが良いでしょう。バーチャルホストを使っている場合は、

<VirtualHost <バーチャルホスト名>>

<Directory <wp_home>>

    AllodwOverride all

</Directory>

</Virtual>

という感じで、バーチャルホストの記述の中に追記します。

httpd.confでこの記述を追記したら、apacheを再起動する必要があります。

% apachectl restart

これで無事新しいhttpd.confが読み込まれて、該当のwordpressのディレクトリで.htaccessを使えるようになります。

もしうまくいかなかったら、apacheのエラーログを見て、記述に間違いがないか、きちんと起動しているかを確認すると良いでしょう。

(/var/log/httpd/error_logとか）

 

２．.htaccessの作成

.htaccessは普通のテキストファイルなので、ご自身でサーバがいじれる場合は、サーバの<wp_home>に直接viなどで作成しても良いですし、外部のサーバを使っている場合はPCでテキストファイルを作成しておいて、ftpでアップロードしても良いでしょう。

さて、基本的なやり方は下記のとおりです。（実際のwordpress用の設定方法は後述します）

例えば、

http://www.sailweb.net/modules/wordpress/index.php?p=97　(1)

を

http://www.sailweb.net/modules/wordpress/articles-97.html　(2)

という静的リンクに書き換えたいとします。その場合は下記のようなルールを.htaccessに記述します。

RewriteEngine on　(3)
RewriteCond %{REQUEST_FILENAME} !-f  (4)
RewriteRule ^articles-([0-9]+).html+ index.php?p=$1  (5)

(3)は、このディレクトリへのアクセスの際にmod_rewriteエンジンを使う、という宣言です。(4)は、外部のウェブブラウザからこのディレクトリにアクセスしてきた場合に、該当ファイルがなければ、(5)のルールを適用する、という条件文です。そして(5)が肝心のルールです。

(5)のルールの意味は"^"が行頭を示し、行頭からすぐに"articles-"という文字列が続くことを意味します。そのあと([0-9]+)は"0〜9までの数字が一つ以上続く文字列"を意味しますので、(2)の"97″がこれにマッチします。そしてその後ろに”.html"が続くというパターンを示しています。なお([0-9]+)の両サイドの"(,)"（カッコ）がグループを意味し、マッチした文字列を$1という変数で参照することができます。

つまりここでは"$1=97″ということになります。さて、スペースをはんさんで"index.php?p=$1″という記述がありますが、$1はここでは97に置換されるので、結果として、(2)の"articles-97.html"は(1)の"index.php?p=97″に置換されて、無事アクセスできる、という仕組みです。

なお、.htaccessへ記述するルールのなかで、(5)の検索パターン"^articles-([0-9]+).html+"の中には、サブディレクトリの記述ができないようなので、注意しましょう。たとえば、archiveというサブディレクトリが<wp_home>以下にあったとして（wp_home>/archive）このarchiveというサブディレクトリを検索パターンに含めたいことがあるかもしれません。

つまり"^archive/articles-([0-9]+).html+"という感じです。しかしこれはちゃんと動きません。もしそのようなサブディレクトリを使いたい場合は、まさにそのサブディレクトリの中に.htaccessを作るようにします。（ちなみに、httpd.confではそういった記述は可能です。ただし、<Directory <dir>>の<dir>との兼ね合いになります）

.htaccessは、その場所にアクセスがあった場合に毎回webサーバが読み込むので、.htaccessを置いた瞬間から有効になります。もし一時的にこの設定を無効にしたいとか、編集中は使って欲しくない、というときは、.htaccess.workとか適当な名前に変更しておくと良いでしょう。

さて、これで無事(2)のURLで(1)へアクセスがリダイレクトされるようmod_rewriteの設定が終わりました。

が、これで終わりではありません。mod_rewriteとしての設定はこれで十分なのですが、本来の目的はSEO対策、つまり検索サイトのbotが当該ホームページをクロールしにきたときに、そのページのどこかにこの静的URL(2)で書かれたリンクがあって、当該ホームページにそのページが存在することを知ってもらわねばなりません。

 

３．wordpressでの静的リンク設定

予め当方環境では、xoops用のwordpressモジュールである、WordPress Me 0.6.0aを使っていることを記しておきます。

当該サイトに、肝心の静的URLで示される日記ページがあることをbotはどのようにして知るでしょうか？人間のユーザであれば、wordpress Meの「最近の投稿」ブロックのリンクから辿るでしょう。つまり、この「最近の投稿」ブロック（を含め、そのほかの関連ブロック）からのリンク表記も静的URLになっていなければなりません。デフォルトでは、このへんのリンクは、マウスカーソルをリンクにあわせてもらえばわかりますが、依然として動的表記のままです。つまりこれではSEO対策になりません。

サイトのページ上で現れるそのほかのリンクも全て静的URL表記になっていなければ結果としてBotは肝心の各日記ページを登録できないのです。幸いにもwordpressでは、$Permalinkという変数で、各モジュール内部でのリンク表記が記述されており、この$Permalinkを適切に設定してやることで、複数あるブロックのphpのファイルや、htmlテンプレートを書き換える、ということをしなくて良いようになっています。

xoopsの管理者メニューの中で、「wordpress」モジュールを選んで、

wordpressオプション

ブロック管理

一般設定

のうち、「wordpressオプション」を選びます。画面が切り替わると、複数あるオプションカテゴリのうち、一番最後に「Permalinks」という項目があります。これを選択します。このPermalinksの設定画面で、$permalinkという変数に置換文字列の指定をします。この文字列中で使える変数に関しては、詳細説明がこの画面にありますので、詳しくはそれを参照していただくとして、当方は下記の文字列を指定しました。

/%year%/%monthnum%/%day%/%post_id%/

その下にある「Permalinks構造の更新」というボタンを押すと、その下のテキストエリアに、ReWriteEngine onという文字列から始まる、複雑な文字列が生成されますので、これを全て選択してクリップボードにコピーし、（つまりWindowsであれば、ctrl+a, ctrl+c、MacならCommand+a, Command+c）、これを先ほどの２．の.htaccessに全てコピーします。

これで、2007/04/22のid=97の日記記事の場合は、/2007/04/22/97/という文字列に変換され、

http://www.sailweb.net/modules/wordpress/2007/04/22/97/

という静的URLでアクセスできるようになります。またwordpressの各ブロックのリンクもこの$permalinkの設定によって、すべてこれを使ったリンクを生成するようになるので、検索エンジンのbotがクローリング時にちゃんと情報を取り込んでくれるようになります。

これで、大元のSEO対策は終了です。

 

２．に記した一般的なmod_rewriteのやりかたは、wordpressモジュールに限らず使えますので、そのほかのモジュールなどで静的リンク書き換えをしたい場合は利用すると良いでしょう。mod_rewriteにはそのほかにも、エラーページのカスタマイズや、直リンク禁止の処理など、多様な処理が可能なので、さらに一歩進んで勉強したい場合は下記あたりを参照すると良いでしょう。

　　Apacheチュートリアル：：.htaccess

　　Apache Module mod_rewrite

 

↓↓↓「いいね！」と感じたら、クリックしてBlogRanking投票お願いします(^o^)/

 

サイトを再開して１週間ちょっとたち、以前の日記等も復活させつつ、だいぶコンテンツも増えてきました。ぼちぼち知り合いも見てくれているようですが、

「日記をクリックしたら、表示されるまでに時間がすごくかかる！」

というコメントをいただきました。

 

実はこのサイトを立ち上げる前、同じサーバで動かしている別のサイトを構築しているときから気にはなっていたのですが、訪問者もそれほど多くないサイトだったのであまり問題になってなかったのでそのままにしていました。

 

いや、正直をいえば、多少のパラメータチューニングを試みたのですが、あまり応答性が改善されなかったので、それ以上追求せずそのままにしていました。

 

それで今回は良いタイミングだと思い、改めてMySQLの運用環境の整備をはじめとしてチューニングに再挑戦することにしました。

 

まずはmysqlをいじるための管理のツールの準備です。

 

mysqlはコマンドラインからmysqlコマンドを使って操作をするのが基本ですが、コマンドやパラメータをいろいろ覚えないと行けない事と、数多くのパラメータ類や動作状況を一目で把握するにはちょっと不便です。MySQLはシェアも大きいので、MySQLを管理する為の様々なツール類がフリーや商用で出ています。

 

今回は以下の２つを使います。

phpMyAdmin
phpMyAdminはweb経由でMySQLの殆ど全ての操作をGUIベースで行える、非常にすぐれたプログラムで、これを入れておけば、ローカルでの作業のみならず、外出時に遠隔でこのwebページにアクセスすることでサーバの運用状況とか、パラメータの調整とか、あるいは各テーブルの操作ができます。
MySQL Administrator
MySQL AdministratorはWindows, MacOS X(10.4), Linuxのバイナリ、およびソースで提供されているスタンドアローンの管理アプリケーションで、動作状況をグラフで見たりすることもでき、MySQLのパフォーマンスを視覚的に把握するのに便利です。もちろん各テーブルの操作も可能です。

phpMyAdminやMySQL Administratorのインストール等に関しては省略します。

 

さて、動作状況を見る為にMySQL Administratorを動かしてサーバに接続します。ところがMySQLの管理ユーザ／パスワードで接続をしようとしても、該当のホストは接続許可されていません、というエラーが出ます。ちなみにこの作業は、MySQLやブログサイトを動かしているサーバとは別のマシンから作業をしようとしています。確か以前MySQL Administratorを使っていた記憶があるんですが、なぜかつながらない！

 

基本に立ち戻って、このエラーメッセージの内容を信じてmysqldの管理テーブルに、いま作業しているホストからの接続を受け付けるよう登録されているかどうか確認します。

 

すると、あれ？localhostしか登録されていない！

 

どうやら以前動作させた記憶というのは、MySQLが動いているマシンのローカルからだったようで、あらためてmysqlデータベースのuserテーブルに、ホスト、ユーザ名、パスワードを登録します。ちなみにホストの指定はローカルアドレスからは全て接続を許可するようにします。仮にMySQLのサーバのIPアドレスを192.168.1.1、作業中のマシンを192.168.1.128、サブネットマスクを255.255.255.0とします。記述の方法には以下の２つが可能です。

192.168.1.128
これだと、192.168.1.128というホストからのみ接続を受け付けます。
192.168.1.0/255.255.255.0
192.168.1.0のサブネットに属するホストからは全て接続を受け付けます。
192.168.1.%
上記と同じく、192.168.1.0のサブネットから全て接続を受け付けます。

今回は簡単なほうで、192.168.1.%とすることにしました。

 

さて、あらためてMySQL Administratorから接続しようとすると。。。
ありゃ？まだつながらない。

 

ごく一般的に考えて、テーブルの設定を変更してからすぐにサーバ側に反映されないけーすがあるので、おそらくmysqldにテーブルの更新を何らかの方法で通知する必要がありそうです。mysqldを再起動するのが確実そうですが、phpMyAdminからログインし、トップのページを見てみると、

MySQLのリロード

という項目があります。まずはこれを試してみます。するとmysqlデータベースのテーブルで更新された項目がmysqlに読み込まれた旨メッセージが表示されました。さて、あらためてMySQL Administratorからログインすると、お！うまくいきました。

 

さて、本来の作業としてMySQLのチューニングに入ります。

 

アプリケーション上部の"Health"ボタンをクリックして、"Memory Health"タブを選択します。すると、Query Cache Hitrateと、Keybufferの利用状況がグラフで時々刻々と表示されます。このグラフを表示させておいて、該当のブログサイトの画面からいろいろなリンクを押して、画面切り替えをすると、その度に発生するSQLコマンドの処理状況に応じてグラフが上下します。ためしにある日記へのリンクをクリックするとKey bufferのグラフが跳ね上がりました。現在のkey bufferの設定値は16kByteになっています。ん？16kByte?　なんか値が異常に小さい気がします。それでターミナルを開いてサーバにログインし、mysqldの設定ファイルを確認することにしました。

 

mysqlの設定は大きく分けて以下の４つのところで行います。mysqldを起動した際、この順番で設定が読み込まれ、同じ設定項目があった場合、あとから読み込まれた方のパラメータが有効になります。

/etc/my.cnf　　　グローバルオプション（このマシン全部で共通）
<data_dir>/my.cnf　　サーバ固有オプション
defaults-extra-file　　mysqldへの–defaults-extra-file=<path>で指定されたファイル
~/.my.cnf　　ユーザ固有オプション

ここで<data_dir>はひとつのMySQLインスタンスがインストールされている場所です。一般的にひとつのマシンで複数のMySQLを動かすケースがあり、その場合は全部のMySQLについては/etc/my.cnfが、そして個々のMySQLインスタンスについてはそれぞれがインストールされ、データが格納される場所にある<data_dir>/my.cnfが適用されます。
ちなみに僕のマシンはMacOS X 10.4で、MySQLの標準インストールパスは

 

　　/usr/local/mysql

 

なので、<data_dir>=/usr/local/mysql/dataです。

 

以前インストールして動作の調整をした際に/etc/my.cnfをいじった覚えがあり、たしかkey bufferのサイズは16kbから1Mに拡張していたはず。。。
サーバ固有オプションの方を眺めてみると、ありゃ、こちらは16kbのままです。他のパラメータも同様にかなり小さい値が設定されています。

 

MySQLをインストールすると、サーバのスペックに応じて標準的なパラメータを設定したファイルがいくつか用意されており、MySQLのインストールディレクトリの./support-files以下に入ってます。

my-small.cnf　　　小規模システム用。メモリサイズが64M以下用で応答遅い
my-medium.cnf　　MySQL主体で動かすメモリ32M〜64M程度のマシンもしくは128M程度で他のプログラムも動く
my-large.cnf　　MySQL主体で動かすメモリ512M程度のマシン
my-huge.cnf　　MySQL主体で動かすメモリ1G〜2G程度の大規模システム
my-innodb-heavy-4G.cnf　MySQL主体で動かすメモリ4G以上の大規模システムで、データベースにinnoDBを使っており、接続数がそれほど多くない複雑なQueryを処理するシステム（つまりトランザクションシステムではない、ということでしょうか）

僕も今回初めてきちんとこの辺に目を通している所で、/etc/my.cnfと<data_dir>/my.cnfのヘッダのコメントを見て、上記のどの設定ファイルが標準で使われているかを確認しました。現状のmysqlが使っているのは<data_dir>/my.cnfで、こいつが最終的にmysqldのパラメータを決定しています。<data_dir>/my.cnfを見てみると、my-small.cnfを使っているようです（汗）
現状のマシンはMacOS X 10.4.9でPowerPC 500MHz、メモリを900MB弱搭載しています。このスペックにしてはmy-small.cnfは小規模すぎ、またインターネットから（将来的に）多くのトラフィックが予想されるMySQLの設定としては小さすぎる事が分かりました。メモリサイズから考えると、my-large.cnfかmy-huge.cnfか悩む所ではありますが、MySQL専用マシンではないのと、他にもサーバアプリケーションが常駐していることを考え、少し小さめのmy-large.cnfを選ぶ事にしました。my-large.cnfを/etcと<data_dir>以下にコピーし、名前をmy.cnfへ変更します。

 

さて改めて、phpMyAdminでMySQLのリロードをしてからサーバパラメータの設定を確認してmy-large.cnfのものに変更されているかどうかを見ます。先ほどkey bufferが16kBだったので、これが256MBになっていればOKなわけですが、16KBのままです。
どうやらmysqldを起動したままmyslqテーブルの値を読み込むリロードではだめのようで、mysqldの再起動が必要な様子です。

 

mysqldの起動・停止については、MySQL Administratorからもできるようですが、勉強のためコマンドラインから実行します。
mysqldを正しく停止／起動させる方法は下記にあります。

 

　2.4.3. MySQL を自動的に起動および停止する

 

手動で停止，起動させるときはmysql.serverスクリプトを使うと良いようです。mysql.serverはインストールディレクトリのsupport-filesにあります。僕のマシンでは

 

　/usr/local/mysql/support-files/mysql.server

 

です。さて、あらためてターミナルから

% /usr/local/mysql/support-files/mysql.server stop
% /usr/local/mysql/support-files/mysql.server start

を実行した後に、あらためてphpMyAdminでkey buffer他の値を確認すると、今度はきちんと変更されていました。

 

さて、ブログの方へもどってブラウザからブログサイトの日記等をクリックして画面更新のスピードを確認してみます。うん、少し早くなったようです。

 

サイトの表示が遅い場合、今回は気になっていたMySQLのパラメータ調整を試みましたが，実際には様々なプロセスが絡んでいるため、他にも速度低下の要因が考えられます。Webサーバであるapache、ブログサイトで読み込んでいるECサイトの応答、ネットワークインタフェースカード、ルータ、ハブ、そしてサーバがつながっている回線そのものの輻輳（混雑）などなど。。。

 

ま、これでとりあえず様子を見てみようと思います。場合によってはメモリを増やしてmy-huge.cnf設定ファイルに切り替える事も検討します。

 

ちなみに僕の環境はMacOS X 10.4(.9)ですが、下記のような本を参考にしています。（あとはインターネットですね）

 

 

↓↓↓　「いいね！」と感じたら、クリックしてBlogRanking投票お願いします(^o^)/