再構築時のパフォーマンスで頂いたコメント・トラックバック等の情報より、再構築時に500エラーが発生する原因と対処方法です。メモリ消費が大きい」ということらしいです。具体的な内容につきましては下記に引用させて頂いた通りです。3.2でrecently_commented_onとBerkeleyDBに嵌っている人が多い件についてrecently_commented_onはlastnやdaysオプションと一緒に指定することはできませんでしたが(中略)?3.2では指定された範囲のエントリーを対象に最近コメントされたエントリーをリストアップする機能となりました。(中略)これを実現するために追加されたMTへのナイーブなコード追加が甚大な影響を及ぼしています。(中略)指定された範囲のMT::Entryオブジェクトをすべてメモリ上に読み込んだ後、それら個々のエントリーに付けられた最終コメント時刻の降順にソートし、recently_commented_onオプションで指定した数だけ先頭から取り出すということを行っています。悪いことには、lastnなどで範囲指定することなく使用すると、上記の操作がすべてのエントリーを対象に行われることになります。いうことで、同エントリーにて対処用パッチも提供されております(3日付で最新版が出ています)。それを該当のスクリプトに適用させることでインデックステンプレートの再構築は問題なく実行できることを確認できました。等が正常に動作しない問題の対処も含まれています。スクリプトを任意のエディタで開き、パッチの行頭左に「+」マークがある行を追加(「+」は除く)し、「-」マークの行を削除します。作業前に予めバックアップをとってください。500エラーになりますのでご注意ください(元に戻せば良いので慌てることはありません)。追記:勝手ながら下記にパッチの変更箇所を挙げさせて頂きました。赤色を削除して青色を追加します。これはパッチの修正方法が分からない方のための補助的な位置付けです。パッチの内容は適宜変更される可能性がありますので、基本的には原本を参照してください。正規のパッチ適用方法はAzrael:Tagwire、MT-XSearch、Cygwin導入メモに詳しく書かれています。return($obj);アーカイブテンプレートについては再構築時のメモリ問題が引き続き発生しています。再構築時のメモリ量増加についてではサブカテゴリーが原因と書きましたが、カテゴリーリスト・月別アーカイブリストも影響を及ぼしているようです。日別アーカイブおよびエントリーアーカイブの再構築時の最大メモリ量について計測してみました。結果は下表の通りです。計測は、例えば日別アーカイブの「カレンダー」は、他の(疑いのある)4つのリストはテンプレートに設定せず、中央カラムのエントリーは公開テンプレートと同じ状態で再構築したものです。再構築時のメモリ量増加についてと同様です。500エラーにならず正常に完了しています。カテゴリーリスト・サブカテゴリーリスト・月別アーカイブリストのメモリ量が増加しています(赤色)。その3つのリストについて、日別アーカイブがエントリーアーカイブの倍近い値になっているのは、再構築数(エントリーアーカイブ:40/日別アーカイブ:80)の違いでしょうか。青色の個別エントリーアーカイブのコメントリストはやや高めの値ですが、パッチによって劇的に改善されたものです(パッチ適用前は数百MB上昇して500エラー)。3.2にアップグレードしてから、再構築に異常に時間がかかるようになっていた件で、やはり同じ問題に悩む方が多いようです。ちはろぐ目立つ不具合はBerkeleyDB上の事なので他のDBを使えるヒトはMT3.2への移行を控えなくても良いと思います。3.2へバージョンアップ。Logがちょくちょく起こり初めました。つまらん日記エントリーの再作成で失敗する件について、「小粋空間」さんでも、いろいろ書いてありました。PMコメントこんばんわ、harryです。Trackbacksだけでなくカレンダー、日別アーカイブおよびカテゴリーアーカイブ、エントリーアーカイブとすべてを削除すると何とか再構築できるようになりました。勉強不足で申し訳ございませんが、ご教授いただければ幸いです。MySQL化はレンタルーサーバ(ロリポップ)でできるようですのでいずれトライしてみます。AMベンチマーク、お疲れ様です。3.2ではDBからロードしたデータをメモリー上にキャッシュしておき、後で再利用するようになっています。その分メモリー消費量が大きくなる反面、高速化されるのですが、BerkeleyDBの場合にはそのキャッシュが作りっぱなしになっています。このあたりの対処を加えた新しいパッチを作りました。メモリ消費が抑えられるのでは、と思っています。これである程度うまく行けばSixApartに改変を要求する予定です。AM>harryさんこんにちは。ご質問の件ですが、エントリーに追記しましたのでご参考になれば幸いです。>(o)さんこんにちは。パッチ提供くださりありがとうございます。先ほど試してみたのですがメモリ量増加に変化はありませんでした。設定誤りでしたらご指摘ください。ものに入れ替えて再構築してみたところ、やはり事象は変わりませんでした。メモリ量増加の補足ですが、再構築開始時のメモリ量は約20MB(3.1x並)で、毎秒2?3MB上昇しています。それではどうぞよろしくお願い致します。アーカイブ(これは目次のみ作成)作成、カテゴリーアーカイブは不作成。最近のエントリーやコメント(0......)やトラックバックなどの部分はアーカイブとは分離して作成し、古めの手法でSSIでIncludeで合成して表示。シェルにログインしてメモリー使用量を確認しながら再構築していたところ、いずれも大体最大120MBほど使用。「インデックステンプレートを再構築」を行ったら500MBを超えてサーバーエラーになりました(苦笑)......よくこの状態で「インデックステンプレートを再構築」+αの処理をしていると思われる、新規エントリーの投稿やトラックバック受信が出来るなぁ......と言う感想です(投稿も未公開トラックバックの公開処理も、どちらの処理も時間はかからないです)SixApart社にはBerekelyDB用ObjectDriverの改良と、このメモリー使用量関連の改良を行ったMT3.2のマイナーチェンジバージョンを出して欲しいところですね。ご丁寧にありがとうございました。試してみたいと思います。PM>ちはさんこんばんは。ご無沙汰しております。苦労されたようで、お疲れ様です。メモリ使用量の改善については(o)さんのおかげで改善されましたね。Apartの改良版を待ちたいと思います。>harryさんこんばんは。ご連絡ありがとうございました。AMyujiroさん、どうもです。追記レポートをお届けに?新規にMT3.2jaを設置して、データファイルを(o)さんが最初に指摘していたように現行の日記BlogのBerekelyDBのデータベースをSQLiteにmt-db2sql.cgiで変換(Webサーバ上で実行するとタイムアウトして500サーバエラーになるとの話があるのでシェル上で実行)して、再構築を行ったところメモリー使用量30?40MB程度で推移しました。MySQLサーバが使えなくても、SQLiteが使えるPerl環境の場合はそっちに移行してしまうのも、(o)さんの指摘通りに良い手かもしれません。......ちなみにうちのレンタルサーバでPerlライブラリのDBD-SQLiteが使えるようになったのは2005/9/3......ぎりぎりセーフ。AM>ちはさんこんばんは。追加情報ありがとうございます。アップグレードに苦戦して、コチラを参考にサイドバーに設置していた「最近のコメント」と「最近のトラックバック」を外して何とかしのいでいます。テンプレートが崩れてしまっています、トホホ。PM>kojyoさんこんばんは。記事参照ありがとうございます。3.2の改善版をお待ちになるのも良いですが、他のDBへの移行も選択肢として考えられてはいかがでしょうか。Cygwin導入を導入して、Oさんのpatchを当ててみたのですが、状況改善されず、また500エラーの出方が日々ひどくなるので、本日思い切ってMYSQLに変えてみました。なんとか苦労して再セットアップしたのですが、やはり貴テンプレートに変えると再構築に時間がかかりやはり500エラーが発生します。MT標準のテンプレートでもすべて再構築時に500エラーが発生することがあります。これで様子を見たいと思います。最初に送ったトラックバックのエントリーを削除してしまったので、当方のトラックバックは削除しておいて戴きたく。今後ともよろしくお願い致します。AM>harryさんこんばんは。MySQLでの500エラーはレンタルサーバに依存した問題かも知れません(以前そういう話題があがってました)。トラックバックは別途削除しておきます。ご連絡ありがとうございました。