2006-06-06  ウィスパー2―その4―

DBに試験用のデータを挿入し終えました。ただいま運用時とほぼ同じ環境で，動作検証しています。いつものように，わけの分からない現象に遭遇しています。

運用サーバの性能に難点

実際に運用するサーバで動作試験してみました。思ったほど性能が出ないことが分かったので（開発環境の1.5倍速程度），高速化を図ることにしました。

• キャッシュ ― DBへのアクセスを減らす。DBにアクセスするということは，外部記憶装置（ここではHDD）にアクセスすることになるので性能を低下させる一因になる
• 状態空間の枝狩り ― 容量の削減。あってもなくても性能に影響のない情報を間引く

初回起動直後のクエリに時間が掛かる

DBの容量増大に比例し，DBファイルを開いた直後に発行するクエリに時間が掛かるようになりました。しかも悪いことに減速の度合いは，O(N)ではなくてO(N^2)のように感じます。どういうことかというと，だんだんと遅くなるのではなくて，坂道を転げ落ちるかのように急激に遅くなっていくのです。

遅いのは最初のクエリだけで，2回目以降のクエリは高速です。またDBファイルを開く回数が2回以上のときは，クエリの発行回数に係わらず，どのクエリも高速でした。

この問題は，ディスクキャッシュの影響で発生していると推測しています。回避する方法があるのかないのか，いまのところ不明です。

UNIQUE制約でエラー

DBのテーブルには，「諸条件を満たさないレコードが挿入されようとしたらエラーを返す」という制約をつけています。変なレコードが挿入されて，DBが壊れるのを防ぐためです。

ウィスパー2の一部のテーブル（のカラム）には，UNIQUE制約をつけているのだが，試験運用中に何度かこの制約に引っ掛かり強制停止してしまいました。

テーブルにつけている制約は，実際には未使用です。上位層（アプリケーション側）で重複を調べているので原理上，発生しないエラーのはずなのです。なぜ発生したのでしょうか。「レコードは存在しないけれど，その存在しないレコードのためのインデックスは存在する」みたいな状態になっていたらしい。（詳細な分析はしていないので正確な原因は不明。）

高速化のために同期機能を切っていたのが原因だったようです。DBアクセス中に何度かCTRL+Cで中断していたのだが，あれはやっぱりやってはいけないことだったようです。CTRL+Cを控えるようにしたら，エラーが出なくなりました。

ドキュメントには，同期を切った状態でアプリケーションがクラッシュしてもDBは壊れないと書かれていたのですが，どんな動作を「クラッシュ」としているのか細かく書かれていませんでした。CTRL+Cは想定外のクラッシュなのかもしれません。あるいはOSによって挙動が違うのかも。