Movable Type で再構築エラー(Internal Server Error)になってうっとしい！

Movable Type 3.2-ja-2 で再構築エラーに関する質問を頂くことが多いので、本エントリーにまとめました。

１．エラー現象

「再構築エラー」とは、主に下記の現象を指します。

• 500エラーが表示される
• テンプレート内で MTLink タグを使用していると、そこでエラーとなる（場合がある）

いわゆる「500エラー」とは、 Internal Server Error つまり内部サーバエラーのことで、CGI等のプログラムが何らかの理由で実行できない、あるいはプログラムにエラーがある場合に発生します。
MTLink タグのエラーも500エラーと同様で、MTLink タグのエラーに見えるのは、たまたまそこでエラーメッセージを表示できる実装になっているからではないかと推測しています。

２．再構築エラーの原因

Movable Type で再構築エラーが発生する原因としては、これまで頂いたご質問を集計すると、

• Movable Type の DB に BerkeleyDB を使用
  → BerkeleyDB はお手軽ですがパフォーマンスに難があります
• エントリー・アーカイブの再構築単位
  → デフォルトの再構築単位は40（エントリー）ですが、この値では再構築エラーになる確率が高いです
• エントリー・アーカイブの「最近のコメント」で recently_commented_on を利用している
  → lastn 属性を使用しない recently_commented_on 属性の使用はメモリ消費量が増大します

によるものがほとんどのようです。
そしてこれらを誘発する原因として下記が考えられます。

• サーバのパフォーマンス
• サーバのメモリ量

よくある例として、複数名で共有しているレンタルサーバが考えられます。このケースでは CPU やメモリ等の事実上のスペックは、マシンを占有する人数や使用頻度に反比例して低下していきます。故に再構築の成功率も同時に低下することになります。
また上記の要因が複合すれば再構築エラーが発生する確率はさらに高くなります。

３．エラー解消方法

とりあえず目前のエラーを回避する方法と、本格的な対処の2通りを紹介します。

３．１ とりあえず回避する

• デフォルトテンプレートに戻す
  デフォルトテンプレートの状態であれば再構築時のエラーはほぼ皆無という認識です。理由は次の内容をご覧ください。
• エントリー・アーカイブのサイドバーを削除してみる
  例えば、当サイトの公開テンプレートとデフォルトテンプレートとの大きな違いは、アーカイブページのサイドバーの有無です。公開テンプレートのアーカイブ・テンプレートにはサイドバーにリスト類（カレンダー・最近のエントリー/コメント/トラックバック・カテゴリーリスト・月別アーカイブリスト）を色々と表示しており、その分、MTタグからHTMLマークアップを生成する時間が増加し、結果的に再構築時間に影響を与えることになります。つまりサイドバーにリスト類を表示している場合、それらを全てなくすことで再構築時間を短縮することができます。

なお、再構築エラーは前述の通り複合的な要因で発生します。公開テンプレートでアーカイブテンプレートのサイドバーに情報を表示すること自体についてはテンプレートのバグではありません。その点誤解なきようお願い致します。

３．２ 本格的な対処

対処しやすい順番に並べています。

• 再構築単位を少なくする
  mt-config.cgi の下記の部分を

  # EntriesPerRebuild 40

  から

  EntriesPerRebuild 10

  に書き換えます。10でもエラーになる場合は値をさらに小さくしてください。かなりの方がこれで解消されています。
  3.3 では mt-config.cgi にこの設定自体がなくなっていますので新たに追加してください。

• rebuild支援ツールを利用する
  再構築を部分的に行うためのツールです（プラグインではありません）。
  
  rebuild支援ツール for MovableType

• DB を MySQL または SQLite または PostgreSQL に移行する
  パフォーマンスに問題のある BerkeleyDB の使用をおやめになることを強く推奨します。SQLite の移行方法については、Movable Type + SQLite を参照ください。
  MySQL自体の性能は高いのですが、ひとつのDBを多くのユーザでシェアしている場合は解消されないかもしれません。心配な場合はレンタルサーバのサポートに確認してください（自宅サーバ+MySQLはかなり快適です）。PostgreSQL については MySQL と同等とお考えください。
  ロリポップの場合は SQLite への移行をお勧めします。

• PHPモジュール化を行う
  サイドバーのリスト類をモジュール化（部品化）することで再構築時のパフォーマンスが向上します。ただし、ページ閲覧時に PHP が起動するため、アクセスの多いサイトでの CGI版 PHP の利用は 503 エラーを誘発する可能性があります。PHP モジュール化を行う場合は「条件付きGET」を有効にしてください。

  関連記事：
  Movable Type の PHP化（その1）
  PHPモジュール化の仕組みについて
  HTTP/1.1 の「条件付きGET」を利用して PHP ファイルアクセスによるサーバ負荷を削減する
  PHP における「モジュール版」と「CGI 版」の比較 + WordPress の適用例

• ダイナミックパブリッシングにする
  ページを毎回動的に生成する方法です。静的なファイルを作らないため再構築時間が劇的に縮小します。

  関連記事：
  Movable Type の再構築を不要にする「ダイナミック・パブリッシング」（その1：概要）
  Movable Type の再構築を不要にする「ダイナミック・パブリッシング」（その2：設定方法）

• サーバを変更する
  レンタルサーバもピンキリで、最終的にはサーバや DB のパフォーマンスに依存します。何をやっても事象が好転しない場合はこれをお勧めします。