ファイルクロールの設定 最大アクセス数に設定した値は2回目以降の起動時にどのように適用されますか?

■ファイルクロールの設定
・ファイルシステム
パス:smbで別途ファイルサーバー指定
クロール対象から除外するパス:exe等もろもろ
深さ:指定なし
→指定先のディレクトリの階層はかなり上位
ディレクトリの深さはかなり深い
ファイル数、数十万件
最大アクセス数:6000
間隔:1000 ミリ秒

クローラーの実行間隔:30分毎に実行

上記設定の場合、クローラー初回実行時は6000件ファイルをちゃんとクロールしてインデックスを作成してくれますが、2回目以降は20~200程度しかインデックスが作成?されていません。
0件の時もありました。

クローラーが起動する度に、6000件ずつ新しくクロールしたいのですが、上記設定は誤りでしょうか。

ちなみにログには以下の警告が出ておりました。
こちらが原因の場合、解決策をご存知でしたらご教授ください。

■fess.log

2020-05-13 08:10:15,599 [pool-6-thread-1] WARN Failed to process a task.
org.elasticsearch.ElasticsearchStatusException: Elasticsearch exception [type=circuit_breaking_exception, reason=[parent] Data too large, data for [<http_request>] would be [1065807384/1016.4mb], which is larger than the limit of [1020054732/972.7mb], real usage: [1065806824/1016.4mb], new bytes reserved: [560/560b], usages [request=0/0b, fielddata=506084/494.2kb, in_flight_requests=560/560b, accounting=1281113/1.2mb]]
at org.elasticsearch.rest.BytesRestResponse.errorFromXContent(BytesRestResponse.java:177) ~[elasticsearch-7.6.2.jar:7.6.2]
at org.codelibs.elasticsearch.client.action.HttpAction.toElasticsearchException(HttpAction.java:138) ~[elasticsearch-httpclient-7.6.2.jar:?]
at org.codelibs.elasticsearch.client.action.HttpSearchAction.lambda$execute$0(HttpSearchAction.java:48) ~[elasticsearch-httpclient-7.6.2.jar:?]
at org.codelibs.curl.CurlRequest.lambda$execute$4(CurlRequest.java:220) ~[curl4j-1.2.4.jar:?]
at org.codelibs.curl.CurlRequest.lambda$connect$3(CurlRequest.java:199) ~[curl4j-1.2.4.jar:?]
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1429) ~[?:?]
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) ~[?:?]
at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016) ~[?:?]
at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665) ~[?:?]
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598) ~[?:?]
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177) ~[?:?]
Suppressed: org.elasticsearch.ElasticsearchException: hits is null.
at org.codelibs.elasticsearch.client.action.HttpSearchAction.lambda$execute$0(HttpSearchAction.java:48) ~[elasticsearch-httpclient-7.6.2.jar:?]
at org.codelibs.curl.CurlRequest.lambda$execute$4(CurlRequest.java:220) ~[curl4j-1.2.4.jar:?]
at org.codelibs.curl.CurlRequest.lambda$connect$3(CurlRequest.java:199) ~[curl4j-1.2.4.jar:?]
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1429) ~[?:?]
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) ~[?:?]
at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016) ~[?:?]
at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665) ~[?:?]
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598) ~[?:?]
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177) ~[?:?]
Suppressed: org.codelibs.elasticsearch.client.action.HttpAction$CurlResponseException: {“error”:{“root_cause”:[{“type”:“circuit_breaking_exception”,“reason”:“[parent] Data too large, data for [<http_request>] would be [1065807384/1016.4mb], which is larger than the limit of [1020054732/972.7mb], real usage: [1065806824/1016.4mb], new bytes reserved: [560/560b], usages [request=0/0b, fielddata=506084/494.2kb, in_flight_requests=560/560b, accounting=1281113/1.2mb]”,“bytes_wanted”:1065807384,“bytes_limit”:1020054732,“durability”:“PERMANENT”}],“type”:“circuit_breaking_exception”,“reason”:“[parent] Data too large, data for [<http_request>] would be [1065807384/1016.4mb], which is larger than the limit of [1020054732/972.7mb], real usage: [1065806824/1016.4mb], new bytes reserved: [560/560b], usages [request=0/0b, fielddata=506084/494.2kb, in_flight_requests=560/560b, accounting=1281113/1.2mb]”,“bytes_wanted”:1065807384,“bytes_limit”:1020054732,“durability”:“PERMANENT”},“status”:429}

よろしくお願いいたします。

差分クロールが有効でなければ、開始パスからアクセスした6000ファイルでクロールは毎回完了します。
その例外は上記とは別な話だと思いますが、elasticsearchへのcircuit_breaking_exceptionになっているのでparentあたりが引っかかっていると思うので、elasticsearchの設定を確認してもらうのが良いと思います。

回答ありがとうございます。

差分クロールが有効になっていたので、解除して試してみたいと思います。

elasticsearchの確認の件も承知いたしました。

何度もすみません。

以下の私の考えが正しいかどうか回答いただけないでしょうか。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
①Fessの管理画面 → 全般の設定 → 「最終更新日時の確認」は差分クロールを意味している
よって、チェックを外すことにより、差分クロールは行われない

②差分クロールが行われない設定にした場合、本トピックに記載したクローラーの設定であれば
起動する度にまだインデックスを張っていないファイルに対して走査を開始する。
よって、時間はかかるが、数十万件のファイルをすべてをクロールすることは可能である。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

また、別の質問になりますが、すべてのファイルをクロールした後、追加/更新/削除があった事
を検知して同期させたい場合には、上記のままのクローラー設定だと実現はできないでしょうか。

よろしくお願いいたします。

最終更新日時の確認を有効=差分クロールで、クロール対象のドキュメントが正しく取得できていれば、インデックスされているものと比較して、更新されていなければ何もしないですし、更新されていれば新しいものに置き換えることになります。

差分クロールを向こうにすれば、更新日時を確認しないで、開始パスから辿りながらインデックスしていきます。なので、毎回、ほぼ同じものがインデックスされると思います。微妙に変わるのはマルチスレッドとかで取得の順番が若干変わったりとかがあるためです。

他の質問とかでも回答していますが、必要なものクロールしたいような場合は、CSVファイルリストのデータストアクロールを利用してください。

詳細な回答ありがとうございます。

理解いたしました。
データストアクロールを検討いたします。

今更ですが、1つ目の返信で「差分クロールが有効でなければ」と記載されているのに
「差分クロールが有効になっていたので、解除して試してみたいと思います。」
と逆のことを言ってしまっていたようです。

失礼いたしました。

ちなみに差分クロールが有効な場合は、
「いつも同じパスから辿っていくが、更新日時が同じものについてはスキップされ、
新規または更新があったものが6000に到達するまでクロールされる」認識で正しいでしょうか。
(例えば、更新が一切されない6万件ファイルがある場合、10回クローラーが起動することで、すべてのファイルのインデックスが作成される)

■質問の経緯
数十万件のファイルの走査を1つのクローラーで行いたいです。
理由は走査対象のディレクトリの階層構造が多く、一つ一つ指定していられないからです。
スペックの低い環境で動作させているからか、ファイル全件を対象にすると
FessのOutOfMemorryやElasticのエラーが多発し、チューニングに四苦八苦しています。
6000件程度に限定することで、エラーが発生しないことは確認できているため
この走査を複数回行うことで全網羅できるのであれば

・CSVファイルリストのデータストアクロール
・スペックの良い環境を用意する

よりも手間がかからないと考えたからです。

お手数ですが回答お願いします。

10回クローラーが起動することで、すべてのファイルのインデックスが作成される

そのような感じにはなると思いますが、ファイルをたどっていかなければならないので、そのように構築はしたことはないですね…。そのようなやり方をおすすめもしません…。

数十万件程度であれば、夜間でクロールとかのような対応にしてしまうと思いますが、数千万件くらいのときには、一度は普通にクロールしておいて、あとはファイルの更新イベントなどから更新ファイル一覧を自動で作り、CSVファイルリストで定期的にクロールして対応とかだと思います。

FessのOutOfMemorryやElasticのエラーが多発し、チューニングに四苦八苦しています。

商用サポートをご利用いただくのが良いかと思います :slight_smile:

回答ありがとうございます。

数十万件程度であれば、夜間でクロールとかのような対応にしてしまうと思いますが、数千万件くらいのときには、一度は普通にクロールしておいて、あとはファイルの更新イベントなどから更新ファイル一覧を自動で作り、CSVファイルリストで定期的にクロールして対応とかだと思います。

アドバイスありがとうございました。
本格的に導入がきまりましたら、商用サポートも検討させていただきます。