バージョン 0.20.x のコーパスの破損

これはPOPFile 0.20.xだけが該当します。 もしあなたが0.20.xからのアップグレードに問題を抱えているなら役に立つかもしれません。ただし、ここで説明されている問題は、現在のバージョンのPOPFileではもう発生しません。

POPFileのコーパスはBerkeleyDB テーブルファイルに格納されます。 それは、コーパスを構成するそれぞれのバケツに対応するtable.dbファイルのことです。 ある状況下において、table.dbファイルが破損する可能性があります。たとえば、システムがクラッシュしたり、重要なテーブル情報がディスクに書き込まれる前に強制的にPOPFileが終了されたりした場合です。table.db ファイルには下記の情報が含まれています:

  • バケツに含まれる単語リストとそれに対応する単語数、
  • バケツに含まれる固有単語数
  • バケツに含まれる単語の総数

コーパスが破損する原因はなんですか?

コーパスの破損には、2つの異なった原因があると考えています:

  • POPFileのプログラムを強制終了させ、コーパスの構造をディスクに中途半端な状態で残してしまったとき。
  • 設定タブでPOP3 同時接続の許可 オプションが「はい」に設定された状態で、下記の条件でメッセージを再分類した場合:
    1. メールを再分類している間に、メールクライアントからメールを取り込んで、
    2. 再分類の結果、コーパスのデータベースがオーバーフローして、データベースの拡張が起こり、
    3. 並行して動作している子プロセスがPOP3のメールの取込を終える前に、再分類が終わってしまった場合。

破損をさけるために

  • つねにPOPFileをUIのshutdownリンクから終了させてください。もし、他のやり方で終了させなければいけない場合は、まずメールクライアントを完全に終了させてください。
  • メールクライアントがメールを取り込んでいる間に、メールの再分類をしないでください。

コーパスが破損したときの症状

コーパスが破損したときの症状は下記のようなものがあります。

  • UIのページのバケツタブで、単語数か、固有単語数が空白になる。
  • POPFileが起動しない。起動中に破損したコーパスにぶつかったところで落ちてしまう。
  • バケツの固有単語数が突然減ってしまう。
  • コーパスのいくつかのバケツに含まれた情報が消失することで、急激に分類エラーが増加してしまう。
  • もし、フォアグラウンドモードで起動していた場合、下記のようなエラーが現れます:
    POPFile Engine v0.20.1 running
    Illegal division by zero at C:\Program Files\POPFile/Classifier/Bayes.pm line 37
    4, <GEN3> line 642.
    
  • 同様に、コーパスが破損した場合にだけ、このような症状が現れることがあります。
  • メールクライアントがメールを取り込もうとしても、つねに タイムアウトします。これは上記のエラーによって再分類が妨げられ、POP3のセッションがすぐに異常終了してしまうためです。

本当にコーパスが破損しているかどうかを確認する

[[:dbverify | dbverify]] というユーティリティーで、コーパスが破損しているかどうか確認することができます。もし、ユーティリティーが何も破損をレポートしなければ、コーパスに問題はありません。

破損したコーパスの取り扱い

いったん table.db が破損してしまったら、この状況を修正するために下記の選択肢があります。

  • POPFileを終了し、破損している table.dbファイルを削除します。POPFileを再起動したとき、新しく table.db ファイルが作成されます。 これは現在のコーパスを失い、POPFileを再トレーニングしなければならないことを意味します。
  • コーパスのバックアップを使って元に戻す。バックアップしてます、よね?
  • もし、それより前のバージョンのPOPFileからバージョン0.20.xへアップグレードしたなら、Windowsのインストーラーが作成するバックアップを使ってもとに戻します。このバックアップは、backup ディレクトリに保存されています。それぞれのバケツは 'table' ファイルを含むサブディレクトリを持っています。
    1. コーパスのフォルダ内にあるtable.db ファイルを削除する(それぞれのバケツの名前が付いたサブディレクトリの中にあります)。
    2. 'table' ファイルをバックアップからコーパスのフォルダ内のサブディレクトリの中にコピーします。
    3. POPFileを再起動すると、自動的に0.20.x以前のバージョンのコーパスを自動的に新しいtable.dbファイルに変換します。
  • もしあなたが技術的に解決したいと思うなら、サポートされないユーティリティーcurloadを使って、破損したコーパスの内容の復元を試してみてもいいでしょう。
    1. cunloadユーティリティーをPOPFileをインストールしたディレクトリにダウンロードします。このリンクを右クリックして、対象をファイルに保存します。 http://www.geocities.com/helphand1/popfile/0_20/cunload.pl
    2. POPFileを停止します。
    3. DOS窓を開き、ユーティリティーを実行します。
      cd "\program files\popfile"
      perl cunload.pl
      
    4. もし、破損したコーパスがあるなら、ユーティリティーは壊れたバケツをこのようなエラーメッセージで知らせてくれるでしょう:
      C:\program files\popfile>perl cunload.pl
      Checking corpus/magnet/table.db
      Checking corpus/normal/table.db
      Checking corpus/spam/table.db
          *ERROR** bucket corpus/spam has a corrupt corpus,
      db_verify returns: DB_VERIFY_BAD: Database verification failed
      Bucket corpus/spam is likely corrupt, word count is 10882 versus 12687
      Bucket corpus/spam is likely corrupt, unique count is 3148 versus 3912
      
    5. ここで、壊れたバケツを完全に削除するか、cunloadユーティリティーによって回復できたバケツの単語でどうにかやっていくかを、あなたは選ぶことができます。どちらが正しい答えというものはありません。どちらを選ぶかに関わらず、単語の消失という損害を被ることになるため、どちらの選択肢も魅力的ではありません。あなたにとって何が最善かを考えて決断するとよいでしょう。 決断するときには、以下の事実を考慮しましょう。もし、バケツから多くのデータが失われた場合に、はじめからやり直して、POPFileを再トレーニングするのではなく、回復可能なものを保持するという判断をした場合、分類精度に悪い影響を与える結果となるバランスの悪いコーパスを作ってしまうかもしれないのです。多くの場合、バランスの悪いコーパスから回復するより、再トレーニングする方が簡単で迅速です。
      1. バケツを完全に削除することを選択した場合、次のコマンドを実行してください。(この例ではバケツの名前をspam としています。実際のバケツの名前に置き換えてください):
        del corpus\spam\table
        del corpus\spam\table.db
        
      2. cunloadユーティリティーが回復したものを保持する場合、次のコマンドを実行してください。 (しつこいけれど、この例ではバケツのな名前をspamにしています。本当のバケツの名前を使ってくださいね。):
        del corpus\spam\table.db
        
    6. DOS窓を終了して、POPFileを再起動します。 (重要な項目: POPFileは起動時に、再びフラットファイルをBerkeleyDBフォーマットに変換しようとします。これはコーパスのサイズに依存して時間がかかる処理ですから、POPFileを強制終了したり、killしたりしないで辛抱してください。さもないとまた破損したコーパスを作ってしまうことになります。)

原文

 
jp/troubleshooting/corruptcorpus020.txt · Last modified: 2008/02/08 19:49 (external edit)

Should you find anything in the documentation that is incomplete, unclear, outdated or just plain wrong, please let us know and leave a note in the Documentation Forum.

Recent changes RSS feed Donate Driven by DokuWiki
The content of this wiki is protected by the GNU Fee Documentation License