Oracle OpenWorld Tokyo 2012 と JavaOne Tokyo 2012 のお申込み受付が始まりました。Oracle OpenWorld Tokyo 2012 は4月4日から6日まで、JavaOne Tokyo 2012 は4月4日から5日まで、それぞれ六本木ヒルズなどで開催されます。参加費は Oracle OpenWorld Tokyo 2012 が無料で、JavaOne Tokyo 2012 が5,250円です。

以下のバナーからお申込みいただき、招待コードに「2715」を入力していただくと、Oracle OpenWorld Tokyo 2012 では Leaders Club メンバーとして招待者限定セッションに参加できるようになります。JavaOne Tokyo 2012 では招待コードを入れるメリットは参加者の皆さまには特にないのですが……、私がほんの少し上司にほめられるかもしれません。

ボクが Scientific Linux 6 を使う始めるときに、必ず設定やインストールしている項目をここでまとめておく。

rootユーザーのメールアドレスの設定

Scientific Linux から管理者であるroot宛に様々なメールが届くが、そのままではrootで当該マシンにログインしないと読めないので、いつも使っているメールアドレスに届くように変更する。ボクの場合、rewse.jpのメールアドレスをメインに使っているけど、そのメール・サーバーに障害が起きたときにそれを通知するメールが受け取れないので、Gmailのアドレスを設定している。

# Person who should get root's mail
#root:          marc
root:           example@gmail.com

/etc/aliasesを編集しただけでは設定は有効にならないので、忘れずにnewaliasesを実行する。

[root@charlie ~]# newaliases

ボクの自宅サーバーで使っている固定IPアドレスは逆引き設定できず、逆引きすると契約ISPのドメインが戻ってしまうため、Gmailに直接メール送信すると The IP you’re using to send mail is not authorized to 550-5.7.1 send email directly to our servers. で受信拒否されてしまう。対策方法は Gmail: The IP you’re using to send email is not authorized… に載っているとおりなので、契約ISPのSMTPサーバーに中継するように設定変更する。

Postfixに中継サーバーを設定する。SMTPサーバー名を指定する場合には必ず [ ] をつけることを忘れずに。

#relayhost = $mydomain
#relayhost = [gateway.my.domain]
#relayhost = [mailserver.isp.tld]
#relayhost = uucphost
#relayhost = [an.ip.add.ress]
relayhost = [mail.asahi-net.or.jp]

また、Postfixのデフォルト設定では送信元メールアドレスのドメイン部分はホスト名になっているが、このままだと Sender address rejected: Domain not found エラーで受信拒否される場合があるので、ドメイン部分を変更する。

#myorigin = $myhostname
#myorigin = $mydomain
myorigin = $mydomain

設定ファイルを再読み込みする。

[root@charlie ~]# service postfix reload
Reloading postfix:                                         [  OK  ]

このように受信側メール・サーバーのいろいろなポリシーで拒否される場合があるので、必ずテスト・メールを送ってみよう。mailでは本文を書き終えたら.（ピリオド）だけの行を入力すると本文終了の意味になる。

[root@charlie ~]# mail -s "Test Mail" root
This is a test mail.
.
EOT

NTPの設定

パッケージを絞ってインストールしたためか、ボクの環境ではNTPが入っていなかったので、まずはインストール。

[root@charlie ~]# yum install ntp
......
================================================================================
 Package        Arch          Version                           Repository
                                                                           Size
================================================================================
Installing:
 ntp            x86_64        4.2.4p8-2.el6                     sl        444 k
Installing for dependencies:
 libedit        x86_64        2.11-4.20080712cvs.1.el6          sl         73 k
 ntpdate        x86_64        4.2.4p8-2.el6                     sl         57 k
......

海外NTPサーバーだとレイテンシーが大きいので、国内NTPサーバーを追加する。ボクは 情報通信研究機構 (NICT) / INTERNET MULTIFEED の定番に加えて、契約ISPのASAHIネットを追加した。なお、ntp.nict.jpはIPv6でも接続可能なため、なお、強制的にIPv4で通信するように-4をすべて追加している。

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server -4 0.rhel.pool.ntp.org
server -4 1.rhel.pool.ntp.org
server -4 2.rhel.pool.ntp.org
server -4 ntp.nict.jp
server -4 ntp.jst.mfeed.ad.jp
server -4 ntp.asahi-net.or.jp

NTPサーバーとの時刻が違いすぎると自動調整が利かないので、一度、手動で合わせてしまう。

[root@charlie ~]# ntpdate ntp.nict.jp
28 May 22:45:46 ntpdate[5030]: step time server 133.243.238.244 offset -18.324051 sec

NTPサービスを起動時から有効になるように設定変更し、サービスを開始する。

[root@charlie ~]# chkconfig ntpd on
[root@charlie ~]# service ntpd start
ntpd を起動中:                                             [  OK  ]

しばらくすると以下のコマンドでNTPの同期状況が分かるようになる。上3つは NTP Pool Project のものなので自動的に選ばれたものだ。先頭に*（アスタリスク）がついているサーバーが現在同期中のサーバーで、ntp.nict.jpを使用しているようだ。ntp.nict.jpはストラタムが1なので（一次サーバーなので）選ばれやすい。

[root@charlie ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp.kiba.net    195.71.81.206    2 u   12   64  377   11.793  -34.807   2.153
 www.4koma.com   133.243.238.163  2 u   12   64  377   41.168  -15.576   4.411
-foneus.gimasyst 10.0.5.10        2 u   12   64  377    4.741  -40.622   5.522
*ntp-b2.nict.go. .NICT.           1 u   12   64  377    4.223  -35.788   2.374
+ntp3.jst.mfeed. 210.173.160.86   2 u    8   64  377    2.192  -34.882   2.264
+orion.asahi-net 133.243.238.244  2 u   11   64  377    1.900  -36.306   2.281
 LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.002

Yumの設定

デフォルトでは海外にある公式サイトの更新サーバーを見に行ってしまって遅いので、国内ミラーに設定変更する。変更方法は 複眼中心: 国内 Scientific Linux 6 サーバーのためのyum設定 を参照してほしい。

Cronの設定

何台かのマシンがあるとき、すべてが同じ時刻にCronを動かすとその瞬間だけ高負荷になってしまうので、個々のマシンで実行時刻をずらす。このマシンでは以下のように変更した。

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
#01 * * * * root run-parts /etc/cron.hourly
11 * * * * root run-parts /etc/cron.hourly

Scientific Linux 5 と違って、cron.daily / cron.weekly / cron.monthly はAnacron経由で実行される。AancronはSTART_HOURS_RANGEの時間帯のみ実行され、period in days の日数ごとにAnacronデーモンが起動してから delay in minutes + RANDOM_DELAYの間にcommandが実行される。つまり以下の設定がされた常に起動しているサーバーの場合、/etc/cron.dailyは1日ごと（毎日）の3時05分から3時50分の間に実行され、/etc/cron.weeklyは7日ごと（毎週）の3時25分から4時10分の間に実行される。

# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command 
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

デフォルトの値はワークステーションが前提なのか深夜以外の時間帯にCronを実行するようになっているので、これを深夜のみに変更する。Anacron自体は/etc/cron.hourly/0anacronから実行されるので、デーモンの再起動などは必要ない。

# the jobs will be started during the following hours only
#START_HOURS_RANGE=3-22
START_HOURS_RANGE=3-6

パフォーマンス関連パッケージのインストール

OSの統計情報を獲るためのdstatとsysstatをインストールする。

[root@zulu ~]# yum install dstat sysstat
......
================================================================================
 Package           Arch             Version                  Repository    Size
================================================================================
Installing:
 dstat             noarch           0.7.0-1.el6              sl           136 k
 sysstat           x86_64           9.0.4-11.el6             sl           214 k
......

不要なサービスの停止

この環境では必要ないサービスを自動起動しないように変更し、サービスを停止する。

[root@zulu ~]# chkconfig sysstat off
[root@zulu ~]# service sysstat stop

必要なサービスの開始

この環境に必要なサービスを自動起動するように変更し、サービスを開始する。

[root@zulu ~]# chkconfig ipmi start
[root@charlie proc]# service ipmi start
Starting ipmi drivers:                                     [  OK  ]

ディスクのチューニング

ext4ではデフォルト予約ファイルシステム・ブロックとして全容量の5%が割り当てられている。dfしたときに「使用」+「残り」の値が「サイズ」と違うのはこの予約ファイルシステム・ブロックがあるためで、この予約ファイルシステム・ブロックにはrootのみが書き込むことができる。そのため、例えば一般ユーザーが/tmpをあふれさせてしまっても、rootは予約ファイルシステム・ブロックを使って/tmpにまだ書き込むことができ、管理作業を行うことができる。ただ、最近の大容量ディスクではデフォルトの5%は大きすぎると思うので、これを容量に従って少し小さくする。仮想マシンのディスク・イメージを配置するパーティションなんかは大容量だけど不意の書込みはほとんどないので、予約ファイルシステム・ブロックは少なくできる代表例だろう。

また、ファイルシステムをチェックする最大マウント回数 (-c) とファイルシステムをチェックする最大時間間隔 (-i) も気をつけよう。デフォルトでは30回程度（ランダム）のマウントまたは180日目のマウントで自動的にfsckが実行される。OS起動時に予期せず巨大なパーティションに対してfsckが実行されてしまい、いつまで経ってもOSが起動しないというようなことが起きないように、ボクは -c 0 -i 0 にすべてのパーティションをしているし、GUIインストーラーであるAnacondaで自動フォーマットした場合は自動的に -c 0 -i 0 になっている。

[root@charlie ~]# tune2fs -m 1 -c 0 -i 0 /dev/sdd1
tune2fs 1.39 (29-May-2006)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds
Setting reserved blocks percentage to 1% (2441406 blocks)

smartdの設定

ディスクのS.M.A.R.Tを監視し、異常が発見された場合は告知してくれるsmartdはデフォルトの設定ではSATAディスクに対応していないので、それを修正する。

# The word DEVICESCAN will cause any remaining lines in this
# configuration file to be ignored: it tells smartd to scan for all
# ATA and SCSI devices.  DEVICESCAN may be followed by any of the
# Directives listed below, which will be applied to all devices that
# are found.  Most users should comment out DEVICESCAN and explicitly
# list the devices that they wish to monitor.
#DEVICESCAN -H -m root
DEVICESCAN -H -m root -d sat

99-raid-checkの設定

/etc/cron.weekly/99-raid-checkはRAIDの各ディスク間でデータ不一致がないかどうかを見つけてくれるのだけど、そのためにディスクを全走査するので2TBが3本のRAID5で5時間以上掛かってしまう一方、スワップ領域を含むディスクはデータ不一致を誤検知することがあって信用ならないので、スワップで使用しているLVMの論理ボリュームを含む2TBの領域はこのチェックを行なわないようにした。この問題の詳細は へびにっき: WARNING: mismatch_cnt is not 0 on /dev/md0 が詳しい。

......
# To check devs /dev/md0 and /dev/md3, use "md0 md3"
CHECK_DEVS=""
REPAIR_DEVS=""
#SKIP_DEVS=""
SKIP_DEVS="md1"

iptablesの設定

iptablesを使ってファイアウォールを構築する。構築方法は 複眼中心: iptablesによるファイアウォール設定 を参照してほしい。

Avira AntiVir Personal (UNIX) のインストール

ウイルス対策に Avira AntiVir Personal (UNIX) をインストールする。インストール方法は 複眼中心: Avira AntiVir Personal (UNIX) 3.1.3.5-0 インストール を参照してほしい。

chkrootkitのインストール

ルートキット対策にchkrootkitをインストールする。インストール方法は 複眼中心: Scientific Linux 6.1 に chkrootkit 0.49 をインストール を参照してほしい。

バックアップの設定

rsyncを使用してNFS経由で別マシンに日次バックアップを行うスクリプトを設置する。このスクリプトは Mac OS X の Time Machine にインスパイアされたもので、ハードリンクを使用した重複排除や、週次の間引きなども行うようになっている。スクリプトの詳細は GitHub: rewse: backup.cron を参照してほしい。

Zabbixエージェントのインストール

統合監視にZabbixを使用しているので、そのエージェントをインストールする。

LDAPとOSユーザーを連携

ボクの環境にはLDAPサーバーがあり、OSユーザーはローカル管理せずにこのLDAPサーバーを使うようにしているので、この連携を行う。連携方法については 複眼中心: LDAPとOSユーザーを連携 を参照してほしい。

各種の設定

/etc/profile.d, /etc/inputrc, /etc/screenrc, /etc/vimrc にいつもの設定を追加する。vimrcについては 複眼中心: 2011年5月のvimrc を参照してほしい。

小田急百貨店新宿店で「冬の北海道物産展」をやっていたので、小樽ミコマのミコマ弁当を購入。このボリュームだけど酢飯はすり切りしか入っておらず、山はカニのほぐし身で支えられている。

冬の北海道物産展は2012年1月17日から2012年1月31日まで。

お店でひいたコーヒーはどうも足が速くて苦手なもので、買おう買おうと思っていたコーヒー・ミルをついに購入した。KALITA セラミックミル C-90 である。

粉の大きさが均一にならない回転羽式（プロペラ式）は味の評判が悪いので臼歯式に絞って検討し、KALITA セラミックミル C-90 か Melitta パーフェクトタッチ II CG-5B の2つで悩んでいたんだけど、会社の共有品としてCG-5Bを使っていて自宅でC-90を使っている岡田有花さん（ゆかたん）がC-90をボクの家に持ってきてくれて実演レビューしてくれときの味がとても良かったので、ボクもC-90を選ぶことにした。カット式の KALITA ナイスカットミル が良いのは分かるんだけど、置き場所がないので……。ゆかたんもナイスカットミルが欲しいと言ってたけど。

セラミックミル C-90 でひくと雑味が出ずに味と香りが深まり、へたな喫茶店で飲むよりおいしいコーヒーが自宅で入れられるようになる。構造は単純なので100杯程度では壊れそうもないので、1杯あたりで考えたらお得な買い物だろう。ただ、油分の少ない豆だとC-90からコーヒー・ドリッパーに移すときに静電気で本体と周りに粉が飛び散りまくるのがちょっと気になるかなー。ハケが一応付属しているけど、水洗いしない限りはきれいにならないし。最後の1粒が飛び跳ねてなかなかひかれないこともあるけど、本体が小さくてそれほど重くないので軽く振れば問題ない。

合わせてコーヒー・ドリッパーもゆかたんが自宅で使っている HARIO カフェオールドリッパー02 CFOD-02 に変更。ペーパーを使わずに、さわってもさらさらしているくらい目の細かいステンレス・メッシュでできているドリッパーで、コーヒー・オイルが抽出されるので味に深みが出る。ペーパーを使わないことでのメンテナンス性は一長一短で、掃除機の紙パック方式とサイクロン方式の違いに近いかも。ペーパー型だと入れた後にそのままポイ捨てすればすむけど、CFOD-02だと水を入れてすぐに生ゴミ受けにひっくり返す作業を何回かする必要がある。ただし、ペーパーを買いに行く手間やコーヒーを飲もうとしたら自宅にペーパーの在庫がない！なんてアクシデントが起こらない。

電気ケトルには T-fal ニューヴィテスプラス を持っていたんだけど、この勢いで Russell Hobbs Cafe Kettle 7110JP を購入。ステンレス製なので本体がかなり熱くなるけど、これは普通のヤカンも同じだと思えば気にならない。それよりもドリップしやすい注ぎ口と安定した取っ手の形状、そして何よりもデザインの美しさがいいね。

Cafe Kettle 7110JP に水をセットしてから、食品庫から豆を出して セラミックミル C-90 でひいて、カフェオールドリッパー02 CFOD-02 に移し替えて、粉だらけのC-90をハケでざっと清掃したくらいの時間で、7110JPが沸騰してから数分経っているので90度以下になっててちょうど良い感じ。こんなにおいしいならさっさと買っておけば良かったよ。

本年も複眼中心をよろしくお願い申し上げます。

紙の年賀状が届くのより早く公開するのもあれかなと思っていたら、こんなタイミングでの公開となりました。今年こそは元旦に年賀状が届くように準備するぞ！

会社から歩いてすぐのところに明治神宮外苑のいちょう並木があるので、いちょう祭りの屋台でランチを取った。2011年のいちょう祭りは12月11日まで。

前回の記事でAPC (Alternative PHP Cache) を導入したものの、パフォーマンス・チューニングの目標値にまだ達していないので、WP Super Cache も導入する。

WordPressのページ・キャッシュには WP Super Cache のほかにも W3 Total Cache も有名だが、ゆっくりと…: WordPressキャッシュ系プラグインの比較とサイトに適した選び方 によるとボクのサイトには WP Super Cache のほうが良さそうだし、いろいろなキャッシュを同時に使うと古いデータがどこでキャッシュされているのかなどのデバッグが難しいので、まずはシンプルな WP Super Cache を試し、それでも目標に達せない場合 W3 Total Cache を検討することにした。

ページ・キャッシュを導入するに当たって気になるのは、左ペインにある「最近の人気記事」が正しくカウントされるかどうかだ。キャッシュから読み込むことで「最近の人気記事」のランキングがリアルタイムに更新されないことは気にならないが、キャッシュから読み込んだ場合にはカウントされないとなると、このウィジェットの意味をなさない。ありがいたいことに、ボクの使っている WordPress Populars Posts のChangelogの2.0.0に、Ajaxを使用することで WP Super Cache などのページ・キャッシュに対応したと書いてあるので問題なさそうだ。

WP Super Cache の設定はDescription の Recommend Settings を参考にして、以下のものをオンにした。

• キャッシュファイルの提供にPHPを利用する
• ページを圧縮し、訪問者により速くページを供給する
• 304 Not Modified ブラウザーキャッシング
• 既知のユーザー向けにはキャッシュしない
• キャッシュリビルド
• モバイル機器サポート
• 追加のホームページチェック
• 除外するユーザーエージェント: （なし）
• プリロード:
  • 1400分毎にリフレッシュ
  • 520件の投稿をプリロード
  • プリロードモード

ログインしていると（既知のユーザーだと）キャッシュされないのは編集作業には適しているけど、このままでは WP Super Cache が効いているかどうか分からないので、WordPressから一度ログアウトしよう。メインのWebブラウザーでログインして WP Super Cache の設定を行い、別のWebブラウザーでログインせずにページを表示すると作業しやすいだろう。WordPressのそれぞれのページのソースを表示して、最後に以下のような記述があり、再読込みしても日時が変わらなければ WP Super Cache は正しく動いている。

<!-- Dynamic page generated in 1.243 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2011-11-01 18:41:25 -->
<!-- Compression = gzip -->

ところが、ボクの環境では、個別投稿ページは問題なくキャッシュされるものの、http://rewse.jp/blog/ は再読込みするたびに日時が変わる、つまり再読込みのたびにキャッシュを再作成してキャッシュから読み込まないという問題が起きた。これは WP Super Cache のタブ「簡易」にあるキャッシュテスターを使うと、以下のように表示されることからも分かる。

キャッシュを準備するために http://rewse.jp/blog/ を取得: OK
http://rewse.jp/blog/ の最初のコピーを取得中: OK (1.html)
http://rewse.jp/blog/ の二つめのコピーを取得中: OK (2.html)
ページ 1: 2011-11-01 18:41:25
ページ 2: 2011-11-01 18:41:27
ページがマッチしません ! タイムスタンプが違うか見つかりません !

ソースコードを追ってみると、この問題は WP Super Cache 0.9.9.9 のバグであることが分かったので、フォーラムで報告しておいた。具体的には、WordPressの「設定 > 一般 > WordPressのアドレス (URL)」にディレクトリが含まれており、「設定 > パーマリンク設定 > 一般的な設定」が /（スラッシュ）で終わらないときに起きる。ボクの場合は以下のようになっていたのでこのバグを踏んだ。

ボクの環境では手っ取り早く以下のように直しているが、0.9.9.9以降のバージョンで開発者がきれいに直してくれることだろう。

if (
  (
    //$wp_cache_request_uri == '/' ||
    $wp_cache_request_uri == '/blog/' ||
    ( $wp_cache_slash_check && substr( $wp_cache_request_uri, -1 ) == '/' ) ||
    ( $wp_cache_slash_check == 0 && substr( $wp_cache_request_uri, -1 ) != '/' )
  ) &&
  ( wp_cache_get_cookies_values() == '' && empty( $_GET ) && $serving_supercache ) )

この修正により、キャッシュテスターも以下のような表示に変わった。

キャッシュを準備するために http://rewse.jp/blog/ を取得: OK
http://rewse.jp/blog/ の最初のコピーを取得中: OK (1.html)
http://rewse.jp/blog/ の二つめのコピーを取得中: OK (2.html)
ページ 1: 2011-11-01 18:41:25
ページ 2: 2011-11-01 18:41:25
両方のページのタイムスタンプがマッチしました !

また、キャッシュから返されている http://rewse.jp/blog/p/4165 にアクセスするたびに以下のSQLの結果が1ずつ増えるので、WordPress Populars Posts が正しく動いてるかも確認できた。なお、WordPress Populars Posts はログインしているユーザーのアクセスはそもそもカウントしないので、ログアウトしてから試す必要がある。

SELECT pageviews FROM wp_popularpostsdata WHERE postid = 4165;

それでは WP Super Cache によってどれだけ性能向上したかabを実行してみよう。

[root@oscar ~]# ab -c 2 -n 4000 http://rewse.jp/blog/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking rewse.jp (be patient)
Completed 400 requests
Completed 800 requests
Completed 1200 requests
Completed 1600 requests
Completed 2000 requests
Completed 2400 requests
Completed 2800 requests
Completed 3200 requests
Completed 3600 requests
Completed 4000 requests
Finished 4000 requests


Server Software:        Apache
Server Hostname:        rewse.jp
Server Port:            80

Document Path:          /blog/
Document Length:        64051 bytes

Concurrency Level:      2
Time taken for tests:   39.813 seconds
Complete requests:      4000
Failed requests:        0
Write errors:           0
Total transferred:      257536000 bytes
HTML transferred:       256204000 bytes
Requests per second:    100.47 [#/sec] (mean)
Time per request:       19.907 [ms] (mean)
Time per request:       9.953 [ms] (mean, across all concurrent requests)
Transfer rate:          6317.03 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    1   0.8      1      22
Processing:     9   18   5.9     18     123
Waiting:        6   11   4.6     11     114
Total:         10   20   6.0     19     123

Percentage of the requests served within a certain time (ms)
  50%     19
  66%     20
  75%     20
  80%     20
  90%     22
  95%     25
  98%     34
  99%     46
 100%    123 (longest request)

チューニング前の Requests per second が0.56#/secだったものが100.47#/secに達した。目標の20#/secも超えたので、これにて今回のチューニングは完了とする。

前回の記事でボクのブログが遅い理由はPHPであるところまでは切り分けできた。WordPressのキャッシュ・プラグインを使うのがすぐに思いつくけど、自宅サーバー監視に使っているZabbixもPHPアプリケーションで、こちらの速度もちょっと気になっていたので、まずはすべてのPHPアプリケーションに効果があるAPC (Alternative PHP Cache) を導入することにした。APCはアクセスのたびにPHPコードをコンパイルするのではなく、その中間コードをキャッシュ / 最適化することで高速にしている。

以下では CentOS 5.7 を使用しているが、Red Hat Enterprise Linux (RHEL) / Oracle Linux (OL) / Scientific Linux (SL) でも同様だろう。PHPはCentOSに含まれるパッケージではなく、IUS Community Project のphp53u.rpmを使用している。php53uのインストールについては 複眼中心: CentOS 5.6 で PHP 5.3.6 にアップグレード を参照してほしい。

IUS Community Project もAPCのパッケージを提供しているので、Yumから簡単にインストールできる。IUSを使っていない場合のパッケージ名はphp-pecl-apcになる。

[root@xray ~]# yum install php53u-pecl-apc
......
================================================================================
 Package                Arch          Version                  Repository  Size
================================================================================
Installing:
 php53u-pecl-apc        x86_64        3.1.9-4.ius.el5          ius        109 k
Installing for dependencies:
 php53u-pear            noarch        1:1.9.4-3.ius.el5        ius        425 k
...... 

httpdを再起動するとAPCモジュールが読み込まれる。

[root@xray ~]# service httpd restart

APCモジュールが読み込まれたかどうかはphpinfo()でも分かるが、APCには監視画面があるので、それを使ってみよう。

[root@xray ~]# rpm -ql php53u-pecl-apc | grep apc.php
/usr/share/doc/php53u-pecl-apc-3.1.9/apc.php
[root@xray ~]# cp -a /usr/share/doc/php53u-pecl-apc-3.1.9/apc.php /var/www/html/apc.php

http://hostname/apc.php にWebブラウザーからアクセスすると、以下のような監視画面が表示される。右側のグラフが表示されない場合はphp53u-gd.rpm (php-gd.rpm) をインストールしよう。

WordPressで何枚かのページを見てから監視画面のボタン「Refresh Data」を押すと Cached Files の値が増えており、APCがキャッシュしていることが分かる。

System Cache Entries のファイル・パスと User Cache Entries はログインしないと表示されないので、ログイン用ユーザーを設定しよう。apc.phpと同じディレクトリに以下のようなapc.conf.phpを作成し、ADMIN_USERNAMEとADMIN_PASSWORDを好きなもに設定する。

<?php
defaults('ADMIN_USERNAME','apc');
defaults('ADMIN_PASSWORD','password');
?>

ただ、このままでは一部のページは見られないものの情報の多くが誰でも見えてしまうため、ボクはBASIC認証を別にかけている。apc.php内の認証を使わない場合は以下のように設定する。

<?php
defaults('USE_AUTHENTICATION',0);
?>

監視画面をしばらく見てると Cache full count の値が増えていくかもしれない。これは割り当てたキャッシュ容量がすべて使われたために、キャッシュが一度すべて解放された回数を示す。つまり、この値が頻繁に増えるということはキャッシュしている意味がないので、そのような場合はapc.shm_sizeを増やそう。ボクのWordPress環境では最大で50MBくらいがキャッシュされるので、64MBに設定することで Cache full count は常にゼロになっている。

;  The size of each shared memory segment in MB. By default,
;  some systems (including most BSD variants) have very low limits on the size of a shared memory segment.
;apc.shm_size=32M
apc.shm_size=64M

APCによってどれだけ性能向上したかabを実行してみよう。APC導入前の Requests per second が0.56#/secだったので、0.92#/secということは1.5倍程度の性能向上が実現できたことになる。

[root@oscar ~]# ab -c 2 -n 40 http://rewse.jp/blog/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking rewse.jp (be patient).....done


Server Software:        Apache
Server Hostname:        rewse.jp
Server Port:            80

Document Path:          /blog/
Document Length:        63908 bytes

Concurrency Level:      2
Time taken for tests:   43.320 seconds
Complete requests:      40
Failed requests:        0
Write errors:           0
Total transferred:      2564720 bytes
HTML transferred:       2556320 bytes
Requests per second:    0.92 [#/sec] (mean)
Time per request:       2166.016 [ms] (mean)
Time per request:       1083.008 [ms] (mean, across all concurrent requests)
Transfer rate:          57.82 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    1   1.4      1      10
Processing:  1647 2156 275.8   2122    2764
Waiting:      929 1301 242.5   1307    1732
Total:       1648 2158 275.7   2123    2765

Percentage of the requests served within a certain time (ms)
  50%   2123
  66%   2238
  75%   2368
  80%   2396
  90%   2570
  95%   2682
  98%   2765
  99%   2765
 100%   2765 (longest request)

しかしまだこれでは目標の20#/secに達していないので、WP Super Cache も導入することにした。つづきは 複眼中心: WordPressチューニング: WP Super Cache 導入 で。

1カ月ぶりにブログを更新したら、ページ表示の遅さが気になってしまったので、今まで何もしてこなかったWordPressのパフォーマンス・チューニングを行うことにした。

WordPressチューニングの情報はWebにいろいろあるけれど、ほとんどが「この設定をこうしたらこんなに速くなった！」みたいな話ばかりで、パフォーマンス・エンジニアの端くれとしては「なんでそこがボトルネックだと判断したの？」という視点がないが気になった。そこで、この記事では原因分析から評価まできちんと記しておこうと思う。ただ、Webアプリケーション・パフォーマンス・チューニングのプロではないので、その辺はお手柔らかに……。

以下ではHTTPサーバーに Apache HTTP Server 2.2.3 + CentOS 5.7、データーベース・サーバーに MySQL Community Edition 5.1.52 + Scientific Linux 6.1 を使っているが、その他の環境でも応用できるだろう。

まず、どこで時間がかかっているのかの切り分けを行おう。Google Chrome 15 のメニュー「ツール > デベロッパー ツール」を開き、Networkタブを表示したら、Shiftキーを押しながら再読み込みボタンを押してWebブラウザーのキャッシュを使わずに再読み込みする。何度か試してみると4秒弱という結果が最頻値のようなので、以下の結果で分析することにした。

タイムラインを見ると、一番上のindex.php (/blog/) に1.83秒と最も時間がかかっている。特にindex.phpのwaitingが終わらないとそのほかのファイル読み込みも全く始まらないので、これが1.83秒もあるというのは何とかすべきだ。index.phpのwaitingに時間がかかっている理由は大きく分けると「ネットワークのレスポンスが悪い」「HTTPサーバーのレスポンスが悪い」「動的ページ生成が遅い」の3つが考えられるだろう。

とりあえず動的ページ生成が遅いのかどうかの切り分けのために、同じページの静的ページを作成する。Google Chrome のメニュー「名前を付けてページを保存…」でHTMLのみをtest.htmlとして保存し、動的に生成されるindex.phpの静的ページ版を作成する。このtest.htmlをindex.phpと同じ階層に置いて、今度はtest.htmlにWebブラウザーからアクセスしてみる。

index.phpに比べてtest.htmlの読込みが圧倒的に速い。つまり、動的生成に時間がかかっているということになる。動的生成が遅い理由は「PHPが遅い」「MySQLが遅い」の2つが考えられるので、そのどちらであるかを切り分けることにした。index.phpのチューニングにターゲットを絞ったので、Google Chrome のデベロッパーツールではなく、ab (Apache HTTP server benchmark tool) をここからは使うことにする。abはhttpd.rpmに含まれており、同じネットワーク内の別サーバーから実行した。

今のところ同時実行性は気にしないので-c (concurrentcy) は小さめで、1分程度負荷がかかるように-n (requests) を調整してindex.phpに対して実行した。以下がその結果であるが、Requests per second が0.56#/secということで、1秒間に1ページも応答できていないという結果となった。

[root@oscar ~]# ab -c 2 -n 40 http://rewse.jp/blog/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking rewse.jp (be patient).....done


Server Software:        Apache
Server Hostname:        rewse.jp
Server Port:            80

Document Path:          /blog/
Document Length:        63908 bytes

Concurrency Level:      2
Time taken for tests:   71.022 seconds
Complete requests:      40
Failed requests:        0
Write errors:           0
Total transferred:      2564720 bytes
HTML transferred:       2556320 bytes
Requests per second:    0.56 [#/sec] (mean)
Time per request:       3551.077 [ms] (mean)
Time per request:       1775.538 [ms] (mean, across all concurrent requests)
Transfer rate:          35.27 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    1   0.4      1       3
Processing:  2343 3523 794.2   3274    5342
Waiting:     1651 2518 644.6   2348    4603
Total:       2345 3524 794.1   3276    5343

Percentage of the requests served within a certain time (ms)
  50%   3276
  66%   3575
  75%   4090
  80%   4285
  90%   4888
  95%   5069
  98%   5343
  99%   5343
 100%   5343 (longest request)

このときのHTTPサーバー上で実行したdstatとiostatの結果をグラフ化したものが以下だ。CPUが100%使用されている。

[root@xray ~]# dstat --cpu --output cpu.csv 2
[root@xray ~]# iostat -x /dev/xvda 2 > io.dat

同様にデーターベース・サーバー上で実行したdstatとiostatの結果をグラフ化したものが以下だ。このデータベースはWordPress専用ではないにもかかわらず、CPU / ディスクともほとんど負荷はかかっていない。

データベースのワークロードはほぼSELECTなので、ロック待ちなどでDBサーバーのリソースが使えていない可能性は低いし、仮にそうであればHTTPサーバー側も待たされてリソースを使えないはずだろう。これによりボトルネックはMySQLではなく、PHPであると考えられる。ここから「PHPエンジン」「WordPressコード」のどちらが遅いのかを切り分けることもできるが、たとえばWordPressのコードをチューニングするとその後のメンテナンスが面倒なので、この2つは総合的に考えることにした。

合わせてtest.html（静的ページ）にも同様にabを実行しておく。そのままでは計測時間が短すぎたので-nを増やしている。test.htmlの Requests per second が204.13#/secなので、動的ページ生成を最大限までチューニングすればこの値になるということで、逆に言うと動的ページ生成のチューニングだけではこれより良い値にはならないということだ。よって、今回のチューニング目標はこれより1桁小さい20#/sec（現行の35.71倍）とした。

[root@oscar ~]# ab -c 2 -n 4000 http://rewse.jp/blog/test.html
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking rewse.jp (be patient)
Completed 400 requests
Completed 800 requests
Completed 1200 requests
Completed 1600 requests
Completed 2000 requests
Completed 2400 requests
Completed 2800 requests
Completed 3200 requests
Completed 3600 requests
Completed 4000 requests
Finished 4000 requests


Server Software:        Apache
Server Hostname:        rewse.jp
Server Port:            80

Document Path:          /blog/test.html
Document Length:        67699 bytes

Concurrency Level:      2
Time taken for tests:   19.595 seconds
Complete requests:      4000
Failed requests:        0
Write errors:           0
Total transferred:      272001800 bytes
HTML transferred:       270841510 bytes
Requests per second:    204.13 [#/sec] (mean)
Time per request:       9.798 [ms] (mean)
Time per request:       4.899 [ms] (mean, across all concurrent requests)
Transfer rate:          13555.52 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    1   0.9      1      28
Processing:     5    8   3.8      8      77
Waiting:        0    3   2.3      3      59
Total:          6   10   4.0      9      79

Percentage of the requests served within a certain time (ms)
  50%      9
  66%      9
  75%     10
  80%     10
  90%     11
  95%     12
  98%     17
  99%     26
 100%     79 (longest request)

このような「ボトルネックの特定」と「ゴールの設定」はパフォーマンス・チューニングにとって非常に重要で、これがチューニングの半分である。次回は実際のチューニングの一環として、APC (Alternative PHP Cache)を導入する。

内蔵BDXLスリム・ドライブ、Panasonic UJ-260 を購入した。UJ-260は1層/2層BD-R (BD-R SL/DL) 書込みに加えて4層BD-R BDXL (BD-R BDXL QL) 書込みにまで対応したスリム・ドライブだ。3層BD-R BDXL (BD-R BDXL TL) のメディアが1枚3,000円以上するどころか、4層BD-R BDXL にいたってはメディアが存在しないという時期尚早感はあるけど、BD-R BDXL メディアはBDXLドライブでないと読むことすらできないので、長く使うつもりならBDXLドライブにしておくのも悪くないだろう。

さて、そんなUJ-260をボクは Owltech Slim Drive Case for SATA OWL-ESODSAT(B) に入れて外付けドライブと使用することにした。というのも、ボクの Apple MacBook Pro (13-inch, Mid 2009) は テクノハウス東映 SlimBay9.5SA-HDD.SA を使ってSuperDriveをHDDにすでに換装してしまっているのでUJ-260を内蔵することができないのだが、外付けBDXLスリム・ドライブは13,000円以上するので、付属ソフトウェアがいらないのであればUJ-260とOWL-ESODSAT(B)を買ったほうが安いというわけだ。個人的にはBuffaloや I-O DATA などだとベアドライブの予想はできても確実ではないので、ベアドライブから組むほうが好きってのもある。

とは言っても、BD-R BDXL どころかBD-Rを使う予定すらないのが現状。今までDVDやCDを読む必要があるときは Buffalo DVM-RDM16U2 という6年以上昔の外付けDVD±RWドライブを使っていたんだけど、妻の Apple MacBook Pro (15-inch, Mid 2010) もSuperDriveをHDDに換装してしまったため、でかいDVM-RDM16U2を妻の机まで持って行くが面倒でポータブルDVD±RWドライブが欲しくなり、それなら価格差がそれほど大きくもないBDXLドライブを買ってしまおうかというのがことのいきさつである。

なお、Macで外付けドライブを使うと、Apple DVD プレーヤー が「初期化エラーが起きました。有効な DVD ドライブが見つかりませんでした。 [-70012]」というエラーで起動できず、外付けドライブのDVDを読みに行ってくれない。そのため /System/Library/Frameworks/DVDPlayback.framework/Versions/A/DVDPlayback をバイナリ・エディターで修正する必要がある。具体的には ktmtt: 外付けDVDドライブしか無い場合に、Apple DVDプレーヤーを使用する を参考に、以下のように行った。

まずバイナリ・エディターの一つである0xEDのメニュー「File > Open by Path…」で「/System/Library/Frameworks/DVDPlayback.framework/Versions/A/DVDPlayback」を開く。開いたら、メニュー「Edit > Find > Find…」でFind「internal」、Replace「external」にしてボタン「Replace All」を押して、すべて置換する。置換できたらメニュー「File > Save As…」でデスクトップなどに保存しよう。元の場所には権限の問題で上書き保存できない。

所有者や権限を元ファイルと合わせたいので、ターミナルを使用して元ファイルを新ファイルで置き換えた。

[tats@evian ~]$ cd /System/Library/Frameworks/DVDPlayback.framework/Versions/A
[tats@evian A]$ sudo mv ~/Desktop/DVDPlayback .
Password: password
[tats@evian A]$ sudo chown root:wheel DVDPlayback
[tats@evian A]$ sudo chmod 755 DVDPlayback
[tats@evian A]$ ls -l DVDPlayback
-rwxr-xr-x@ 1 root  wheel  4080800 11  1 16:24 DVDPlayback

これによって Apple DVD プレーヤー が外付けドライブ内のDVDを再生できるようになる。