NARU
#1
FESS、インストールはうまくいき動作確認ができた段階です。
ただ、クロール開始すると2日ぐらいでoutofMemory等で止まったりします。
種々ググッてヒープメモリサイズを上げたり（1ｇ→2ｇ→4ｇ）、クロール間隔を延ばしたりしましたが、それでもjavaコンソールで見ていると、結局はクローラのヒープメモリは増減しながらも外観としてはほぼ単調増加していき限界に達します。
そこで「最大アクセス数」で制限して限界に達する前にJOBを終わらせようと考えました。
そこで質問ですが、fessサイトに書かれている「1つのクロール設定を数万件以下にすることを推奨」の意味は、以下のどれでしょうか？
1．クロール設定の「最大アクセス数」を数万件以下にしておけばよい。
2．クロール設定が10個あった場合、トータルで数万件以下にする必要がある。
（→「最大アクセス数」は数千件に設定要）
3．同時クローラー設定が「5」だった場合、5個分のトータルで数万件にする必要がある。（→こうなら「最大アクセス数」は1万件程度にする必要あり）
初歩的質問で、また前置きが長くなり恐縮ですがよろしくお願いします。
fessサイトに書かれている「1つのクロール設定を数万件以下にすることを推奨」の意味は、以下のどれでしょうか？
どこのドキュメントに記述されているでしょうか？旧バージョンのドキュメントには書いてある気もしますが…。
NARU
#3
コメントありがとうございます。
以下urlです。
が、確かにurl見るとv9.1に特化した説明のようにも思えます。
ググッて辿り着いたため古いドキュメントを見てしまったようです。
今のVerでは最大アクセス数が大きくてもパフォーマンス低下は無くなったのかもしれないですね。
となると、逆にヒープメモリが積み上がってしまう要因が不明になってしまいますが・・。
なにか思い当たるフシはないものでしょうか？
Fessに限らず、Javaアプリケーションではmxで指定した分までは積み上がるとは思いますが、普通はGCされてOOMにならずに済みます。OOMになっているということは、クロールのスレッド数と間隔が想定されているヒープの量より多いのだと思います。そのような問題に対して、要件に合わせた設定のチューニングを商用サポートではしているのですが、スレッド数や間隔を減らすなど、クロール設定を見直していただくのが良いと思います。
NARU
#5
回答ありがとうございます。
mx というのは-Xmx4g などの設定、GCはガベージコレクション、OOMはOutOfMemory のことと理解しましたが、これでいいでしょうか？
また、スレッド数や間隔を減らすことでOOMは回避できるということですね？
ならば、再度このへんの調整をトライしてみます。
「1クロールあたり数万件」の制約があると思い込んだのですが、
なにせ、総ファイル数は1億ぐらいあって、フォルダでクローラを分けたりするのはとっても面倒だし、最大アクセス数で終了させて差分クロールを繰り返すのも非効率にもなるので困ったなと悩んでいたところです。
「1クロールあたり数万件」の制約が無いのであれば、1クロール5百万件ぐらいには分けてあとはひたすら完了を待つことを考えます。
はい、その理解で正しいです。
1億ドキュメントをインデックスするためには、Java、Fess、Elasticsearchを熟知していないと厳しいかと思います。数百万ドキュメントを超えるくらいからは、Elasticsearchを含めて、理解していないと運用できないように思います。
NARU
#7
ありがとうございます。
Javaは名前を知っているだけ、言語は使ったこと無し。
Fess、Elasticsearchに至っては今年になって始めて聞いた単語です・・。
つまりド素人です。
あれこれググッていたらjavaConsoleなるものがあることを知り、
Javaの様子を眺めていると、「同時に動くクロール数」が5の場合、5個分が1つのJavaヒープでまとめられていそうに感じました。
スケジューラジョブを分けるとJavaも分かれる印象。
となると、「同時に動くクロール数」「スレッド数」「間隔」「デフォルトクローラを使うかクローラ毎にジョブを作るかの選択」が調整要素になりそうですね。
まずは、以下でやってみます。
クローラ毎のスケジューラジョブ（＝同時に動くクロール数：1 と同等）
スレッド数：5
間隔：2000ｍｓ