目次
経緯
新しい勤務先では、LAN内でファイルサーバーを使っていて、ユーザーが自由奔放にフォルダを作成して資料を置いてるようで、カオス状態。
資料の発掘作業のための時間がもったいないので、Fessを導入することを検討。(運用している機器は全般的にWindows)
結果
かなりてこずったものの、無事に稼働までこぎつけた。
デフォルト設定値でクロール実行すると40時間かかっていたのが、6時間にまで短縮できたので、忘れないうちにここに吐き出しておく。
こんな感じで試行錯誤しました。
Fess+組み込みElasticsearchをインストール
- インストール、クローラーの設定、サービス化は問題なくできた。
- 初回のクロール実行も問題なくできた。ただし、40時間かかった。
(対象ファイルが多いのかもしれない。管理者用の画面にダッシュボードという機能があり、そこには”105万docs”と表示されている。目安になるのか分からないけれども)
チューニング
- 1回のクロールに40時間もかかったら使いものにならないので、いろいろ変更。
- 変更した内容をしっかり覚えてない。メモによるとこんな作業をしたらしい。
- 使用するメモリサイズの変更(最小128MB、最大256MBを両方8GBへ)
- クロール対象ファイルの最大サイズを変更(10MBを40MBへ)
- 2回目のクロールを実行するも途中で異常終了。
原因がどうしてもわからない。
Fess+外部Elasticsearchをインストール
- あまりに原因が分からなさすぎて、1回環境を捨てる暴挙に出る。
といっても、アンインストールはフォルダを削除するだけ。 - 最初の環境と同じく、インストール~初回のクロール実行はできた。
待っている間に調べてたら、サービス化した後にチューニングのために設定変更したのが悪かったらしいことが判明。あぁ。
どうやら、サービス化する際に設定値も含めて保存されるらしく、「2回目の実行時の設定値 ≠ サービス化する際に保存された設定値」状態になり、異常終了した様子。 - なんとなくの原因は分かった。まだクロール実行は終わらない。ひたすら待つ。35時間かかった。少し早くなってるのは、1回目のチューニング内容を反映後にサービス化したからなのかも。
チューニング
- サービス化のタイミングが悪かったのね、という推測のもと再チャレンジ。
サービス化の設定は削除し、2回目の実行からは「設定変更 → コマンドプロンプトからバッチファイル実行による起動」を繰り返しながらチューニング。
- このとき、Elasticsearch → Fessの順に起動させる必要がある。終了は逆の順。バッチファイル実行を終わらせるのは”Ctl+C”。
- 起動バッチは、それぞれインストールしたフォルダのなかのbinフォルダ内にある、”elasticsearch.bat” と ”fess.bat”。
- 変更したのは、Fessの管理者画面メニューで「クローラ > ファイルシステム」と進むと、既に作成済みのクロール設定が一覧で並んでいるので目当ての行を選択。
「ファイルクロールの設定」で、”スレッド数” と ”間隔” の値を変えて試した。
- デフォルト値は、「スレッド数:5、間隔:1000ミリ秒」⇒ 35時間
- 最終的には、「スレッド数:30、間隔:500ミリ秒」⇒ 6時間
もっとよい方法があるかもしれないけど、とりあえず夜のうちに終わるので、これでよしとした。
【参考にしたサイト】
Qiita(さくらのにえ さんの記事)
この記事で、大まかなインストールの流れをイメージできました。
ポート番号の変更、サービスとして登録する方法、ひととおりできるようになりました。
ポート番号の変更、サービスとして登録する方法、ひととおりできるようになりました。
Qiita(ろぐ さんの記事)
試行錯誤中に1回構築した環境を捨てて、外部Elasticsearchを使った環境を作る際に参考にしました。プラグインのインストール方法など具体的な手順が書かれていて、この記事を見つけていなかったら作り直そうという気にはならなかったと思います。
40代ヘタレプログラマ(組込系)のブログ
メモリ使用量の最小、最大値。クロール対象の最大ファイルサイズ。の変更方法を参考にさせていただきました。
GitHub
サービス化したことが、クロール処理が異常終了する原因かも?と思うきっかけとなった記事です。正直これが原因かどうか分かりませんが、うまくクロールできるようになりました。Google翻訳のチカラでなんとなく雰囲気は読み解けました。
バージョン
※ともにWindows版
- elasticsearch: 7.4.2
- fess: 13.4.3
コメント