参考にしたのは、こちらの「WordPress を高速化する5つの方法」という記事。

まず、MySQLのテーブルを最適化してオーバヘッドを解消（これはphpMyAdminから実行）。次に、クエリキャッシュの有効化。これも、リンク先にあるクエリ結果のキャッシュを参考に実施。

PHPの高速化はAPCを有効にしてみることに。ここで軽くはまりました。参考にしたのは、こちらの「APC（Alternative PHP Cache）再び 」。まず、

# pecl install APC

をしてみると、phpizeでエラーが出るので確認したら、phpizeコマンド自体が存在しませんでした…。なもんで、phpizeが入っているPHPの開発パッケージをインストールするために、

# apt-get install php-devel

を実行（この際BINDやapacheなどのアップデートも一緒に実行し間接的に昨日のトラブルの原因となっていました）。php-devel（phpize）をインストール後は、先のpeclコマンドがそのまま通りました。それからphp.iniの最後に、

                  :
extension=apc.so
                  :

を追加して、apacheを再起動。

なんとなく早くなった気はしますが、気の性と言われるとそんな気もするレベルかな？根本的にはサーバをスペックアップアップしなくちゃいけないんだろうけど（いまのサーバはeeePC901-X）。自宅に19インチラックを置いて、1UのサーバやL3スイッチを弄り倒したいけど、お金も場所も厳しいです…。

MySQLでエラーが起きているということはすぐにわかったので、サーバからmysqlcheckをかけて見るとwordpressのDBのチェックが途中で止まる…。とりあえずいったんMySQLを落として再起動してみるかと思い、試してみたら落とせない。で、気が付いたらmysqlコマンドでもアクセス出来なくなってしまいました。これはサーバを再起動しても変わらず。初期化して再構築かなぁなんて思いがよぎりましたが、よくよく調べてみるとサーバのルートパーテションが使用量100%で空きがない。あわてて不要なファイルを削除し、使用量が80%くらいにして再起動したらMySQLが動きました。checkコマンドでwp_optionsが壊れていたのでrepairコマンドで修復。この状態でなぜかルートパーテションの使用量は30%になっていました…。う～ん、謎だ。wp_optionsが壊れたのが原因でmysqlのログが肥大化→ルートを圧迫ってことなのか？そういえば今回はMySQLのログを確認しなかったな…。

I can now reveal that we at the CCNC conference in Las Vegas in January, 2008 will demonstrate and release what we call the PAMP stack.

PAMP stands for Personal Apache, MySQL, PHP, so yes, the full LAMP stack will be made available for S60 smart phones. In addition, there will be PHP extension modules that provide access to the core functionality of the phone. And on top of PAMP you can basically install any LAMP based content management system. For instance, Drupal can be installed off the shelf.

Yes, a fair amount of memory is needed and it’s still pretty experimental stuff, but it runs quite nicely on E90.

Hot news: PHP and MySQL coming to S60!

NOKIA E90 Communicatorさんで知りましたが、S60で動くLAMP環境（PAMP:Personal Apache, MySQL, PHP）が来年1月にラスベガスで行われるCCNC conferenceで発表されるようです。Apacheが動いて、そのうえPHP、MySQLがE90上で動くとなれば、やれることが一気に広がりますね。Wikiをメモ帳代りにしたり、MySQLでDBを作ったり。来年1月は管理工学から+J for S60も出る予定なので、すごく待ち遠しいです。

事の発端はデザインを変えた後の再構築。再構築をかけてもまったく終わる気配がない。っていうか再構築されていない。一晩かけてもまったく終わらないのでいろいろいじってる内に完全におかしくなってしまったのでした（私が悪いんだけど）。

これとは別に、MT4に上げてから管理画面の記事一覧で、最初の20件は表示できるけど次の20件とかが表示できないという現象が発生していました。だけでもデフォルトの表示行数を100件とかにするとちゃんと表示できるのでDBが壊れているわけではなさそうだから、そのうち調べようと放置していました。

で、結果的には再構築できなかったのも記事一覧がちゃんと機能しなかったのも同じ原因でした。

再構築中のウィンドのソースを見ると、

mt.cgi?__mode=rebuild&blog_id=1&type=index&next=0&offset=&limit=～

という部分があり、このoffsetとlimitがあやしいんじゃないかとあたりをつけました。理由は、再構築したときも個別記事の最初の何件かはちゃんと再構築できていたから。

で、MovableTypeのソースからあやしそうな部分を探していったら、lib/MT/ObjectDriver/SQL.pmの263行目に

return sprintf "LIMIT %d%s\n", $n,
          ($o ? " OFFSET " . int($o) : "");

という部分がありました。SELECTの条件となるOFFSETの値を返すSQLを発行しているようですが、このサイトで使っているMySQLの書式では、

SELECT * FROM Table名 LIMIT offset値, 件数

だったはず（前にPHP＋MySQLでいろいろ作っていた時に調べました）。しかし上記の書き方では、

SELECT * FROM Table名 LIMIT 件数 OFFSET offset値

になってしまいます。

で、さらに調べたところ、PostgreSQLでは後者の書式になっていて、MySQL4.0以降では互換性の為に後者の書式もサポートしているとのこと。そういえば、MovableType4の動作環境ってMySQL4.0以上でしたね。でもうちのMySQLは前に4.0.～に上げたはず・・・っと思って調べたら3.23.53でしたよ。あれ～？

いまさらMySQLのバージョンアップはメンドクサイので、SQL.pmの問題の個所を

return sprintf "LIMIT %s%d\n",
          ($o ? int($o) ." , " : ""), $n;

と書き換えて、無理やり書式を合わせてみました。とりあえずこれでちゃんと動くようなりました。

だけども、MySQLをバージョンアップしたほうがいいんだろうなぁ。