Sun が Oracle に買われて以降、Solaris がどうなるのかハッキリしない状態が続いていたので、新しいバージョンがリリースされた事は良かったと思います。OpenSolais の体制のままで新バージョンがリリースされていれば最高だったんですけどね。

リリースはされましたが、Oracle Solaris 11 Express は snv_151 で、OpenSolaris 2009.06 の snv_111b からは大きく変わっているらしく、一回でアップグレードはできません。一度 snv_134b（キャンセルされていた OpenSolaris 2010.06 になるはずだったバージョンですね）に上げた後で、パッケージリポジトリ（パブリッシャ？）を変更して再度アップグレードを行う必要があるようです。

最終的に Oracle Solaris 11 Express（毎回書くのは長いな、略称は何だろ？）を使うか、OpenIndiana を使うようになるかは分かりませんが、どちらにしろ 134b にアップデートしておく必要はあるみたいです。

134b へのアップデート方法

アップデートはpkg image-updateコマンドで行いますが、先に SUNWipkg パッケージを更新しておく必要があるみたいです。

pfexec pkg install SUNWipkg
pfexec pkg image-update -v --be-name snv_134b

いろいろとパッケージをインストールして遊んでいたので、2時間くらいかかりました。

本番環境をアップグレードする前に VirtualBox に OpenSolaris 2009.06 をインストールして、アップデートの実験は何度もしていたので、この手順自体は問題なく終わりました。svcsコマンドでサービスの起動状況を確認して、maintenance になっているものも無かったので、アップグレードは無事終わったかと思っていましたが、ブログを表示させようとするとこんな感じになっていました。

お使いのサーバーの PHP では WordPress に必要な MySQL 拡張を利用できないようです。

問題の調査

php-cgi コマンドが正常に動いていないのか、と思い直接実行してみると

# /usr/php/bin/php-cgi -v
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/5.2/zts-modules/apc.so' - ld.so.1: php-cgi: 重大なエラー: 再配置エラー: ファイル /usr/php/5.2/zts-modules/apc.so: シンボル compiler_globals_id: 参照シンボルが見つかりません。 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/5.2/zts-modules/bz2.so' - ld.so.1: php-cgi: 重大なエラー: 再配置エラー: ファイル /usr/php/5.2/zts-modules/bz2.so: シンボル core_globals_id: 参照シンボルが見つかりません。 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/5.2/zts-modules/curl.so' - ld.so.1: php-cgi: 重大なエラー: 再配置エラー: ファイル /usr/php/5.2/zts-modules/curl.so: シンボル core_globals_id: 参照シンボルが見つかりません。 in Unknown on line 0
PHP Warning:  PHP Startup: ftp: Unable to initialize module
Module compiled with module API=20060613, debug=0, thread-safety=1
PHP    compiled with module API=20060613, debug=0, thread-safety=0
These options need to match
 in Unknown on line 0
（略）
PHP 5.2.12 (cgi-fcgi) (built: Apr  5 2010 20:00:17)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

マルチスレッドでない PHP のプロセスから、マルチスレッドを有効にしたモジュールを読み込もうとして失敗しているようです。php コマンドは正常に動作していましたが、nginx は CGI を使えない。そもそも zts-modules なんてディレクトリは php.ini で指定していないのに、どこから出てきたのかがわかりません。

しばらく悩みましたが、phpinfo() の出力を見て、ようやく気がつきました。

Loaded Configuration File	/etc/php/5.2/nsapi/php.ini

これまでは/etc/php/5.2/php.ini を読んでいたのが、バージョンアップ時に変わってしまっていたようです。NSAPI 用の php.ini ならスレッドセーフのモジュールを読むのは自然です。（NSAPI が現役なのかは知りませんが。自分で最後に NSAPI モジュールを書いたのは13年くらい前か。）

原因は分かれば修正は簡単で、/etc/php/5.2/nsapi/php.ini を以下のように修正して問題解決。

543c547
< extension_dir=/usr/php/5.2/zts-modules
---
> extension_dir = "/usr/php/5.2/modules:/var/php/5.2/modules"

前回（と言っても1年半前か） までで nginx と PHP の fast-cgi のビルドと設定が終わったので、OS の起動時に自動的に起動するようにサービスとして登録を行います。

OpenSolaris ではサービスの管理に SMF という仕組みを使用しています。SMF はサービスの依存関係を記述できたり、サービスの起動を監視して自動的に再起動してくれたりと、Linux などで使われている /etc/init.d の rc スクリプトに比べるとメリットがありますが、コマンドが独自だったり、自分で SMF にサービスを登録するには manifest と呼ばれる XML ファイルを書く必要があるので、慣れるまではハードルがあります。（この辺は Mac OS X の launchd と似ている。）

以下が、私が nginx を管理するために作成した nginx.xml です。

<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
<service_bundle type='manifest' name='export'>
  <service name='network/nginx' type='service' version='0'>
    <create_default_instance enabled='true'/>
    <single_instance/>
    <dependency name='fs' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/system/filesystem/local'/>
    </dependency>
    <dependency name='net' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/network/loopback'/>
    </dependency>
    <exec_method name='start' type='method' exec='/usr/local/sbin/nginx -c /usr/local/conf/nginx.conf' timeout_seconds='60'>
      <method_context working_directory='/usr/local/logs'>
        <method_credential user='root' group='root'/>
        <method_environment>
          <envvar name='PATH' value='/usr/bin:/bin:/usr/local/bin'/>
        </method_environment>
      </method_context>
    </exec_method>
    <exec_method name='stop' type='method' exec=':kill' timeout_seconds='60'>
      <method_context/>
    </exec_method>
  </service>
</service_bundle>

このファイルを以下のように SMF に登録します。

# svccfg -v import nginx.xml

同様に PHP の FastCGI のプロセスも SMF に登録します。

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="manifest" name="php-fcgi">
 <service name="network/php-fcgi" type="service" version="0">
   <create_default_instance enabled="true"/>
   <single_instance/>

   <dependency name="net" grouping="require_all" restart_on="none" type="service">
     <service_fmri value="svc:/network/loopback"/>
   </dependency>

   <exec_method name="start" type="method" exec="/usr/local/sbin/php-fcgi.sh" timeout_seconds="60">
     <method_context working_directory="/usr/local/www">
      <method_credential user="php" group="webservd" privileges="basic,net_privaddr"/>
      <!--method_credential user="root" group="root" /-->
       <method_environment>
         <envvar name="PATH" value="/usr/php/5.2/bin:/usr/local/sbin:/usr/bin:/bin" />
       </method_environment>
     </method_context>
   </exec_method>

    <exec_method name='stop' type='method' exec=':kill' timeout_seconds='60'>
      <method_context/>
    </exec_method>

 </service>
</service_bundle> 

この xml も同じように svccfg コマンドで登録します。

起動用の shell スクリプトはこちらのサイトのものを、ほぼそのまま使っています。

#!/bin/bash

LC_ALL=ja_JP.UTF-8

#FastCGI Webserver path
FCGI_WEB_SERVER_ADDRS="127.0.0.1"

## ABSOLUTE path to the PHP binary
PHPFCGI="/usr/php/bin/php-cgi"

## tcp-port to bind on
FCGIPORT="9000"

## IP to bind on
FCGIADDR="127.0.0.1"

## number of PHP children to spawn
PHP_FCGI_CHILDREN=5

## number of request before php-process will be restarted
PHP_FCGI_MAX_REQUESTS=1000

# allowed environment variables sperated by spaces
ALLOWED_ENV="PATH"

## if this script is run as root switch to the following user
USERID=webservd

################## no config below this line

ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_CHILDREN"
ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS"
ALLOWED_ENV="$ALLOWED_ENV FCGI_WEB_SERVER_ADDRS"

if test x$UID = x0; then
  EX="/bin/su -m -c \"$PHPFCGI -q -b $FCGIADDR:$FCGIPORT\" $USERID"
else
  EX="$PHPFCGI -b $FCGIADDR:$FCGIPORT"
fi

echo $EX

# copy the allowed environment variables
E=

for i in $ALLOWED_ENV; do
  E="$E $i=${!i}"
done

# clean environment and set up a new one
nohup env - $E sh -c "$EX" &

サービスが SMF に登録できれば、svcadm コマンドで起動停止を切り替える事ができます。

起動

# svcadm enable nginx
# svcadm enable php-fastcgi

停止

# svcadm disable nginx
# svcadm disable php-fastcgi

「動かない」と言われた時は「後で書いておくよ」と軽い気持ちで答えてしまっていましたが、よく考えると XCache の管理ページなんてインストールした時に表示させただけで、その後はすぐに munin での監視を始めてしまったので、あまり記憶に残っていません。nginx 側で BASIC 認証を設定していたのが原因だったかで、うまく動かなくて苦労した記憶はあるのですが。（munin の設定については後述）

前に書いた記事で php.ini の設定を載せましたが、管理者の設定が抜けていました。

[xcache.admin]
xcache.admin.auth = On
xcache.admin.user = "admin"
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = "d41d8cd98f00b204e9800998ecf8427e"

パスワードは MD5 でハッシュを計算しておく必要があります。
コードとしては下のような簡単なものですが、このURLでハッシュを計算するものを作ってみました。

<!--
http://blog.bluegold.me/pass.php?password=XXXX 
XXX の部分にパスワードを入力します
-->
xcache.admin.pass = "<?php echo md5($REQUEST["password"]); ?>"

php.ini に管理者の設定を行った後で XCaxhe に付属の管理ページ(xcache.php)を開くと、パスワード認証をした後で管理ページが表示されると思います。

XCacheに付属の管理ページではキャッシュされているスクリプトや、使用メモリ、キャッシュヒットやキャッシュミスの回数などの基本的な情報を調べることはできますが、得られる情報はあくまでも「その時点」での情報でしかないので、キャッシュミスが増えているか等は分かりません。

このサイトでは munin を利用して XCache のキャッシュ状況をモニターしています。munin はサーバなどをモニタリングして統計画像を作るためのソフトで、この種のソフトとしては非常に簡単に設定を行うことができます。監視用のプラグインは比較的用意に作ることができ、既に多くのソフトウェアに対応しています。

XCache用のプラグインは標準ではインストールされていないので、ここから munin_xcache-0.2.tar.bz2 をダウンロードします。インストールは他のプラグインと同様に出来ますが、このプラグインは少し変わっていて「監視される側の php ファイル(munin_xcache.php)」 も一緒に入っています。こちらはウェブサーバーから見える場所においておく必要があります。

しばらくすると、このようなグラフが出来てきます。

6/16 の晩に WordPress 2.8 にアップグレードしたので、そこからキャッシュミスが多くなってきています。

PHPアクセラレータにはeAcceleratorやAPCなどいろいろとあるようですが、今回は使った事のないXCacheを使ってみます。XCacheはバイトコードのキャッシュの他にPHPの変数をキャッシュする機能があるので、この機能をWordPressで使うように設定も行います。

XCacheのビルドは以下の通り簡単に行うことができます。

wget http://xcache.lighttpd.net/pub/Releases/1.2.2/xcache-1.2.2.tar.gz
gzip -dc xcache-1.2.2.tar.gz | tar xvf -
cd xcache-1.2.2
./configure --enable-xcache
make
make install

php.ini ファイルにXCacheの設定を記述します。
ソースに付属しているサンプルの xcache.ini からあまり変えていません。

[xcache-common]
zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20060613/xcache.so

[xcache]
xcache.shm_scheme =        "mmap"
xcache.size  =               22M
xcache.count =                 1
xcache.slots =                8K
xcache.ttl   =             86400
xcache.gc_interval =         600

xcache.var_size  =            2M
xcache.var_count =             1
xcache.var_slots =            8K
xcache.var_ttl   =             0
xcache.var_maxttl   =          0
xcache.var_gc_interval =     300

xcache.test =                Off
xcache.readonly_protection = Off
xcache.mmap_path =    "/dev/zero"
xcache.coredump_directory =   ""
xcache.cacher =               On
xcache.stat   =               On
xcache.optimizer =            On

xcache.size は使用するアプリケーションの種類によって調整した方がよいと思います。XCacheはeAcceleratorなどと違い、キャッシュは全てメモリ上に持つようなので大きめに設定しておいた方が良いかもしれません。

バイトコードのキャッシュは以上の設定でphpのFastCGIを再起動するだけで使用出来ますが、変数のキャッシュを利用するにはアプリケーション側で対応する必要があります。WordPressにはXCache for WordPressというプラグインがあるようですが、最近のバージョンのWordPressでは動作しないようなので、XCache Object Cache Plugin for WordPress 2.5+を使用する事にしました。

インストールは簡単ですが、XCache Object Cache Plugin for WordPressは通常のWordPressのプラグインとはインストールするパスが異なるので注意が必要です。プラグインのファイルは object-cache.php １つだけで、これをWordPressのコンテントディレクトリ（通常は xp-content ディレクトリ）に置きます。私も最初は説明を読まずに他のプラグインと同じように xp-content/plugins ディレクトリに置いて、しばらく悩みました。

このようにバイトコードと変数の双方がキャッシュされている事を確認出来ます。これだけで体感出来る程度には速度が向上するので、導入する価値はあると思います。

nginxからphpを利用するには、FastCGIを有効にしてphpをビルドしておく必要があります。
php-5.2.6 を以下のようにビルドしました。

./configure  
    --with-curl=/usr --enable-fastcgi 
    --enable-mbstring --enable-zend-multibyte 
    --enable-mbregex --with-mysql 
    --with-mcrypt --with-mhash 
    --with-openssl --with-gd 
    --enable-gd-native-ttf --enable-gd-jis-conv 
    --with-jpeg-dir=/usr --with-xpm-dir=/usr 
    --with-freetype-dir=/usr
make
make install

メールで記事を投稿する為に openssl と gd の関係のオプションを追加してます。
openssl は gmail に対して POP で接続する為に、gd はKtai Entryで画像を添付したメールを処理するのに必要でした。

FastCGIのプロセスを以下のように起動します。

/usr/local/bin/php-cgi -q -b 127.0.0.1:9000

127.0.0.1:9000 は FastCGI の接続を待ち受ける IPアドレスとポート番号です。
この値は環境に合わせて別の物に変更する事が可能です。

続いて nginx 側の設定ファイルを作成します。

前回の記事で基本的な設定は nginx.conf に書いてあるので、ここでは VirtualHost の設定だけを記述します。

phpをFastCGIで実行するのに最低限必要な設定はこれだけです。

server {
    listen       80;
    server_name  bluegold.me blog.bluegold.me;
    root   /var/www/blog;
    index  index.php index.html index.htm;
<p>    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/www/blog/$fastcgi_script_name;
        include        fastcgi_params;
    }
}

127.0.0.1:9000 の部分は FastCGI のプロセスのオプションと同じ値を設定します。