nlog(n)

再構築が耐えられないくらい遅いので，データベースを MySQL に変換した。それでも全体の再構築に1時間もかかってしまう。

これまでデータベースとして Berkeley DB を使ってきた。しかし，記事数が増えるにつれ再構築に時間がかかるようになってきてしまった。現在の記事数は，この記事を含めて 536 ある。このサイトの全体の再構築に1時間30分かかっている(nlog(n): 日付別アーカイブの再構築に失敗する)。

Berkeley DB より MySQL の方が高速だと言われているので，マニュアル(Berkeley DBデータベースをSQLデータベースに変換する手順)にしたがって Berkeley DB を MySQL に変換して運用することにした。以前試したのと同じ手順を踏むことにする(nlog(n): Berkeley DB から MySQL への移行を試す)。

変換後，サイト全体の再構築を行ない時間を計測した。

再構築にかかる時間は 2/3 になったが，それでも1時間かかっている。

この記事からは MySQL にしか登録されない。MySQL をやめるには Berkeley DB に逆変換する必要がある。その時は Ogawa::Memoranda: mt-db-convert.cgi: MTデータベースの相互変換CGIスクリプト さんの配布されているスクリプトのお世話になるだろう。

2005年8月25日追記:
根本的な原因は，システムのパフォーマンスが十分に出ていないことだということが分かりました(nlog(n): CPU の動作周波数が低過ぎる)。調整したところ，動作がかなり改善されています(nlog(n): Vine 3.1 でカーネルの再構築)。

2005年8月29日追記:
記事が長くて容量が大きい場合，Berkeley DB から MySQL に変換すると，記事が途中で切れてしまうことが分かりました(nlog(n): cpufreq は未対応だった)。大きい記事がある場合は，あらかじめ MySQL のテーブルを大きくとっておく必要があります。具体的には schemas/mysql.dump ファイルを編集して entry_text の宣言を text から mediumtext あるいは longtext に変更してから mt-db2sql.cgi を実行します(小粋空間: MySQLでエントリーのフィールドサイズを拡張する)。

2005年12月27日追記:
上記の問題は解決しました (nlog(n): 記事の長さの制限値を変更する)。

• Tweet