Confluence のインデックス作成のトラブルシューティング ガイド

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: サーバーと Data Center のみ。この記事は、サーバーおよび Data Center プラットフォームのアトラシアン製品にのみ適用されます。

Confluence Data Center および Server のインデックス機能は、Confluence 内の検索、ダッシュボード、一部のマクロ、ユーザー メンションなど、コンテンツについての情報や参照が必要な場所で利用されます。Confluence Data Center および Server のインデックス機能は Apache Lucene エンジン上で実行されており、次の要素で構成されます。

  • ページ、ブログ投稿、コメントのテキストなどのコンテンツを含むコンテンツ インデックス 
  • ページが最後に編集された日時など、各変更に関するデータを含む変更インデックス 


インデックスのトラブルシューティングのフローチャート

インデックスの問題に対応する際、問題の原因を判断するために次のフローチャートを利用できます。

インデックスのトラブルシューティングのワークフロー


用語

  • 「インデックスの再構築」または「再インデックス」は、 > [一般設定] > [コンテンツ インデックス] で既存のインデックス ファイルを利用してインデックスの再構築を行う操作を指します。
  • 「インデックスのゼロからの再構築」は、ファイル システムから既存のインデックス ファイルを削除し、新しいファイルを利用して新しいインデックスを構築する操作を指します。
  • 「インデックスの構築」または「インデックス作成」は、既存および新規コンテンツについてのインデックスの構築および維持を行う、Confluence の日次処理を指します。





ユーザーのメンション、プロフィール、インデックス

ユーザーのインデックス方法

Confluence は、Lucene エンジンの機能を利用した検索インデックスを保持しています。インデックスは各 Confluence ノードの <Confluence ホーム>/index ディレクトリ内部にローカルで保管され、各 DC ノードやサーバー インスタンスで実行される Confluence のジャーナル ジョブで最新に保たれます。

ユーザーが外部ディレクトリから同期されるかローカルで作成されると、そのユーザーの個人情報 (特に姓名) がインデックス キューに追加されます。メール アドレスやユーザー名はインデックスされず、アプリケーション コードによるリクエストに応じて DB から直接取得されます。

よくある問題やバグ

ユーザーが追加されたあとにインデックスされない、いくつかの既知の問題があります。これらのほとんどは「Confluence で特定のユーザーを @ メンションできない」ナレッジベースに記載されたいずれかの操作で対応できます。

  • Go to <Confluence URL>/confluence/display/~<不足しているユーザー> に移動してユーザー プロフィールを表示します

  • <Confluence URL>/admin/force-upgrade.action URL に移動して 'UserIndexingUpgradeTask' タスクを実行します

  • <Confluence URL>/confluence/admin/users/edituser.action?username=<不足しているユーザー> に移動し、自己紹介や他の任意の情報を更新します

  • 新しいユーザーが単純に未インデックスである可能性があるため、 > [一般設定] > [コンテンツ インデックス] に移動し、そこからインデックスを再構築します
  • 可能であればインデックスをゼロから再構築します。この方法でほとんどの問題を解決できます

ブラウザのローカル ストレージやキャッシュもユーザー メンションに影響します。これらはユーザーが頻繁にメンションする人を素早く表示できるよう保管しています。このため、別のブラウザでのテストも重要です。

便利なナレッジベース記事

バグ

ユーザー メンション機能に影響する可能性がある、現在確認されているバグをいくつかご紹介します。

キー 要約 P ステータス ソリューション 修正バージョン
Loading...
Refresh

さらなるトラブルシューティング

トラブルシューティング

ユーザー メンションやインデックスの問題のトラブルシューティングを行う際は、検索可能なユーザーと検索不可能なユーザーを比較するために DB からユーザー情報を収集することをおすすめします。

select cu.*
from CWD_USER cu
where cu.EMAIL_ADDRESS in ('non-working-user-email', 'working-user-email')
;

select cua.*
from CWD_USER cu
join CWD_USER_ATTRIBUTE cua on cua.USER_ID=cu.id
where cu.EMAIL_ADDRESS in ('non-working-user-email', 'working-user-email')
;

select um.*
from CWD_USER cu
join USER_MAPPING um on um.LOWER_USERNAME=cu.LOWER_USER_NAME
where cu.EMAIL_ADDRESS in ('non-working-user-email', 'working-user-email')
;

また、@ メンションしたいユーザーに対する USERINFO レコードが存在するかどうかを確認します。

SELECT user_mapping.username,
       content.contenttype
FROM content
INNER JOIN user_mapping ON content.username = user_mapping.user_key
WHERE contenttype = 'USERINFO'
  AND lower_username = 'username-here'
;

CONFSERVER-58937 のバグは LDAP ユーザーに影響することが確認されており、LDAP ディレクトリの同期前に新規ユーザー アカウントでログインを行うとプロフィールが作成されますが、そこでプロフィールの編集日と作成日が同じになり、このユーザーがインデックスされません。

CONFSERVER-38569 のバグは LDAP および Crowd ユーザーに影響することが確認されており、ユーザー ディレクトリの再作成と過去の USERINFO レコードの存在により、ユーザーがインデックスされなくなります。

デバッグ ロギング

[管理] > [ロギングとプロファイル] に移動し、次のパッケージを追加して DEBUG に設定します。

com.atlassian.confluence.internal.index.AbstractBatchIndexer
com.atlassian.confluence.search.lucene
com.atlassian.bonnie.search.extractor

詳細については「インデックス用にデバッグを有効化する方法」ナレッジベースをご確認ください。

Confluence 7.11 以降では、インデックスに関連するログ エントリやデバッグ ログは専用の atlassian-confluence-index.log ファイルに格納されます。
Confluence 7.11 未満では、ログ エントリは atlassian-confluence.log に格納されます。

インデックス ジョブと DB

インデックス対象のすべての新規および更新コンテンツはインデックス キューに追加され、これは [管理] > [コンテンツ インデックス] > [キュー コンテンツ] で確認できます。

これらのリクエストの処理のために Flush Edge Index Queue ジョブが 30 秒ごとに実行されているため、確認時点ではエントリが処理済みで、キュー コンテンツの一覧が空に見えることがあります。

インデックス対象のすべてのレコードは JOURNALENTRY DB テーブル内にも格納されており、各 Confluence ノードまたはサーバー インスタンスでは最後に処理されたエントリが <Confluence ホーム>/journal/main_index ファイルに保管されています。JOURNALENTRY DB テーブル内の最後のレコードを確認し、それらを <Confluence ホーム>/journal/main_index ファイルと比較することで、処理済みのコンテンツ インデックス ジョブを判断できます。

Flush Edge Index Queue ジョブのほかに、Clean Journal Entries ジョブが日次で実行されます。これは JOURNALENTRY DB テーブルで 2 日よりも古いエントリをクリーンアップします。このため、特定のノードまたはサーバー インスタンスで数日間適切に実行されなかったジョブがある場合、main_index ファイルに記録されている最後のインデックス対象エントリが JOURNALENTRY DB に存在しなくなっている可能性があります。これに該当する場合はインデックスの再構築が必要です。


コンテンツのインデックス、検索、マクロ

コンテンツのインデックス方法

Confluence は追加されたすべてのコンテンツをインデックスします。これにはマクロ内のテキストや添付ファイル内のテキストも含まれます (抽出可能な場合)。

テキストのインデックスにおいては、選択されたインデックス言語が重要な役割を果たします。選択するインデックス言語は Confluence に保管されているコンテンツを代表するものである必要があり、次のような複数の理由のため、正確な検索に必要です。

  • インデックスに保管される言葉は「ステミング (語幹解釈)」(検索対象の言葉から言語学的に。たとえば wait は waited および waits の語幹であり、meet は meetingmet、および meets の語幹) されます。
  • 特定の単語は「ストップ ワード」と呼ばれ、インデックスされません。ご利用のインデックス言語が英語に設定されている場合、テキスト内の a“、“the“、および “it“ は、ノイズと見なされ、たとえば "the" と検索しても意味のある検索結果は得られないため、インデックスされません。

DB インデックスを利用しない理由

Confluence と Jira はいずれも大量のテキストを持っていますが、DB 検索はこれまでテキスト検索において最高の方法と呼べるものではありませんでした。さまざまな DB ベンダーが改善を行ってきていますが。それは DB バージョンに固有のものです。Lucene では上記のとおりいくつかの追加機能が提供されているほか、DB ベンダーに関わらない一貫したエクスペリエンスの提供を実現できます。

よくある問題やバグ

インデックスや検索の問題のほとんどは単純にインデックスを再構築することで解決できます。スタンドアロンのサーバー インスタンスと Data Center におけるすべての再構築のプロセスを次のガイドで説明しています。また、何らかの理由で Web UI へのアクセスをお持ちでない場合は REST API から再構築の進捗を監視できます。

ゼロからの再構築が必要な理由

インデックスが Confluence の管理メニューから再構築されると、そのプロセスがコンテンツ情報を Lucene DB から取り除き、Confluence から取得して、Lucene DB 内に新しいレコード/ドキュメントを作成します。しかしながら、Lucene DB が破損していると、Confluence の管理メニューからの再構築は適切に動作しません。ゼロからの再構築のプロセスはインデックス用の DB ファイルを削除するよう設計されており、Lucene では新しい DB の作成と Confluence から取得したレコードのそこへの挿入が強制されます。Lucene DB の破損を特定したり修正したりする安全な方法はなく、再構築はご利用いただける唯一の方法です。

インデックスのゼロからの再構築プロセスでは、発生した問題はスキップされるため、このプロセス中に発生するほとんどのエラーは無視できます。しかしながら、エラーが無くならない場合や調査が必要な場合は、次のナレッジベースをご確認ください。

便利なナレッジベース記事

添付ファイルのインデックス

特定のテキスト ファイル タイプでは添付ファイルの抽出およびインデックスが発生し、Confluence は 100 MB 未満のファイルでのみこれを試行します。詳細情報やデフォルトの抽出ファイル サイズの変更については「添付ファイルのサイズの構成」ガイドをご確認ください。

この機能をまとめて無効化することもできます。

バグ

全般的なインデックスや検索機能に影響する可能性がある、現在確認されているバグをいくつかご紹介します。

キー 要約 P ステータス ソリューション 修正バージョン
Loading...
Refresh


さらなるトラブルシューティング

再構築、ロギング、内部

インデックスと Confluence 検索はコンテンツの権限に依存します。Confluence で特定のキーワードを検索すると、 Confluence のインデックス全体が検索され、コンテンツの権限に基づいて検索結果に制限が適用されます。このため、ancestor テーブルの問題はインデックスやインデックスの再構築に影響します。再構築の問題が発生している場合はこれらをご確認ください。

インデックスに関連するほとんどのエラーや警告は通常記録されますが、デバッグ ロギングを有効化し、検索、インデックスの構築、または再構築中の記録内容を確認すると、調査に非常に役立つ場合があります。

デバッグ ロギング

[管理] > [ロギングとプロファイル] に移動し、次のパッケージを追加して DEBUG に設定します。

com.atlassian.confluence.internal.index.AbstractBatchIndexer
com.atlassian.confluence.search.lucene
com.atlassian.bonnie.search.extractor

詳細については「インデックス用にデバッグを有効化する方法」ナレッジベースをご確認ください。

Confluence 7.11 以降では、インデックスに関連するログ エントリやデバッグ ログは専用の atlassian-confluence-index.log ファイルに格納されます。
Confluence 7.11 未満では、ログ エントリは atlassian-confluence.log に格納されます。

インデックス ジョブと DB

インデックス対象のすべての新規および更新コンテンツはインデックス キューに追加され、これは [管理] > [コンテンツ インデックス] > [キュー コンテンツ] で確認できます。

これらのリクエストの処理のために Flush Edge Index Queue ジョブが 30 秒ごとに実行されているため、確認時点ではエントリが処理済みで、キュー コンテンツの一覧が空に見えることがあります。

インデックス対象のすべてのレコードは JOURNALENTRY DB テーブル内にも格納されており、各 Confluence ノードまたはサーバー インスタンスでは最後に処理されたエントリが <Confluence ホーム>/journal/main_index ファイルに保管されています。JOURNALENTRY DB テーブル内の最後のレコードを確認し、それらを <Confluence ホーム>/journal/main_index ファイルと比較することで、処理済みのコンテンツ インデックス ジョブを判断できます。

Flush Edge Index Queue ジョブのほかに、Clean Journal Entries ジョブが日次で実行されます。これは JOURNALENTRY DB テーブルで 2 日よりも古いエントリをクリーンアップします。このため、特定のノードまたはサーバー インスタンスで数日間適切に実行されなかったジョブがある場合、main_index ファイルに記録されている最後のインデックス対象エントリが JOURNALENTRY DB に存在しなくなっている可能性があります。これに該当する場合はインデックスの再構築が必要です。

インデックスの再構築タスクでは、 "Indexer: <n>" という名前のスレッドが最大 6 つ起動されます。このタスクの実行中に発生したすべてのエラーがこのスレッドのいずれかによって記録されます。

ERROR java.io.IOException: No space left on device でインデクサーが停止する」ナレッジベースの例です。

ERROR [Indexer: 1] [internal.index.lucene.LuceneBatchIndexer] doIndex Exception indexing document with id: 12345678
│java.io.IOException: No space left on device                                

インデックスの構築は Flush Edge Index Queue ジョブで実行されますが、これは Confluence のジョブ スケジューラーで処理されます。このため、これらのジョブの実行中に発生したすべての関連エラーや警告は基本的に "scheduler_Worker-<n>" スレッドで記録されます。同じナレッジベース内の次の例にあるように、メッセージを確認して警告/エラーの性質を判断する必要があります。

ERROR [scheduler_Worker-10] [org.quartz.core.ErrorLogger] schedulerError Job (DEFAULT.IndexQueueFlusher threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: com.atlassian.bonnie.LuceneException: com.atlassian.confluence.api.service.exceptions.ServiceException: Failed to process entries]
WARN [scheduler_Worker-10] [search.lucene.tasks.AddDocumentIndexTask] perform Error getting document from searchable
java.io.IOException: No space left on device
WARN [scheduler_Worker-1] [search.lucene.tasks.AddDocumentIndexTask] perform Error getting document from searchable
java.io.FileNotFoundException: /opt/confluence/confluence-home/index/_z8ey.fdx (No space left on device)               

インデックスの確認

稀に、Lucene インデックスそのものに格納されている情報を確認する必要がある場合があります。たとえばデバッグの一環として、コンテンツの特定の部分がインデックスされたかどうかを確認することがあります。この方法については次のガイドをご確認ください。
(warning) インデックスの問題や破損を内部から直すことはできず、破損したインデックスの再構築が最適かつ安全なオプションです。


パフォーマンスとインデックス

パフォーマンスの問題とリソース管理

当社で提供している一般的な Confluence 構成は、Confluence のパフォーマンスに影響を与えることなくインデックスを運用できるように最適化したものです。

デフォルト構成を変更してインデックスの消費リソースを増やせますが、このような変更を行うと Confluence でパフォーマンスの問題が発生したり Out of Memory 例外が発生したりすることがあります。

また、Confluence に十分なリソースが割り当てられていないと、Confluence インスタンスの通常のインデックス処理で OOM イベントが発生することがあります。このようなシナリオではインデックス処理ではなくリソース割り当てが原因です。

Confluence に十分なリソース (メモリ/CPU/ディスク) が割り当てられている状態でインデックス タスクへのリソースを増やすと、インデックスの再構築時間を軽減できます。ただし、再構築時間が実際に改善の余地があるものかどうかを事前に考慮する必要があります。大量のページや添付ファイルのインデックスの構築は、インデックス タスクに割り当てられたリソースにかかわらず、長い時間を要することが期待されます。

よくある問題やバグ

Confluence のパフォーマンスの問題

Confluence でインデックスの再構築処理中にパフォーマンスの問題が発生している場合、次のような点を確認できます。

添付ファイル

Confluence は添付ファイルからテキストを抽出し、検索用のインデックス構築を試みます。実現したい内容に応じ、この機能や潜在的な問題を取り上げたさまざまなナレッジベースを提供しています。

システム プロパティでインデックスを最適化する

再構築タスクの所要時間の短縮をご希望の場合や、日次のインデックス構築がコンテンツの新規作成率に追いついていない場合、次のパラメーターが役立つ可能性があります。
(info) 変更を追跡してシステム負荷を制御できるよう、一度に 1 つのパラメーターを変更することをおすすめします。

  • -Dreindex.thread.count システム プロパティを 6 に設定し、一定数ずつ (2) 増やしながら、再構築処理中のディスク、CPU、メモリ負荷を監視します。
    上記のパラメーターは、Lucene がインデックスの再構築タスク用に開放するスレッドの数を決定します。インデックスの再構築時間を短縮できるかどうかの確認に役立ちます。
  • -Dreindex.attachments.thread.count システム プロパティを 6 に設定し、一定数ずつ (2) 増やしながら、再構築処理中のディスク、CPU、メモリ負荷を監視します。
    上記のパラメーターは Lucene が添付ファイルのインデックスの再構築用に開放できるスレッドの数を決定します。たくさんの添付ファイル
    を持つシステムでインデックスの再構築時間を短縮できるかどうかの確認に役立ちます。
  • -Dindex.queue.batch.size システム プロパティを 1500 に設定し、一定数ずつ (500) 増やしながら、通常処理中のディスク、CPU、メモリ負荷を監視します。
    上記のパラメーターは Flush Edge Index Queue ジョブで毎回処理されるアイテムの数を決定します。ご利用のシステムで大量のコンテンツが生成されていて Lucene で追いつけず、キューが常に積み上がっているような場合に便利です。移行中や大量のコンテンツ生成が予測されるときに一時的に有効化できます。

バグ

インデックスやパフォーマンスに影響する可能性がある、現在確認されているバグをいくつかご紹介します。

キー 要約 P ステータス ソリューション 修正バージョン
Loading...
Refresh



最終更新日: 2021 年 1 月 14 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する

このセクションの項目

Powered by Confluence and Scroll Viewport.