カスタム フィールドの最適化
大量のカスタム フィールドがあると、Jira のパフォーマンス、インデックスのサイズ、インデックス化の時間に悪影響が及ぶ可能性があります。この影響の大部分は、特定のカスタム フィールドのインデックス化にかかる時間が原因です。影響を最小限に抑えるため、カスタム フィールドをインデックス化する方法を改善しました。
課題のインデックスを作成する際のフィールド インデクサの実行数を削減する
これまでは課題がインデックス化されるたびに、Jira が登録されているすべてのカスタム フィールド インデクサーを取得し、カスタム フィールドが課題に適用可能 (表示されてコンテキスト内にあること) かどうかにかかわらず、そのインデクサーを呼び出していました。これにより、追加のオーバーヘッドが発生し、インデックス化の時間に影響が及んでいました。
このオーバーヘッドを減らすため、2 つの改善を導入しました。
値が課題に割り当てられているカスタム フィールドのインデクサーだけが呼び出されるようになります。
注: 現在、この最適化は Jira の組み込みフィールドでのみ機能します。課題に適用可能なカスタム フィールドのインデクサーだけが呼び出されるようになります。「適用可能」とは、カスタム フィールドが特定の課題のコンテキストにあり、表示されているということを意味します。カスタム フィールドは、フィールド設定メニューで非表示になっていない場合、表示されていると見なされます。画面はフィールド表示の計算には使用されません。フィールドがどの画面にも割り当てられない場合がありますが、それでも表示されていると見なされます。
その結果、再インデックス時間の削減が期待されます。
ログでの表示
エントリの監視によって除外されているインデクサーなど、最適化の結果は atlassian-jira.log ファイルで確認できます。ログ エントリを使用して、カスタム フィールド検索で発生する可能性のある問題や、課題データがタイムリーに更新されない場合のトラブルシューティングを行うことができます。ログ エントリには、特定のプロセスに関与しているインデクサーが表示され、詳細な監視が可能になります。
これらのエントリを確認するには、log4j.properties でcom.atlassian.jira.issue.index.DefaultIssueDocumentFactory
のロギング レベルを直接 DEBUG (または TRACE) に変更するか、[トラブルシューティングとサポート] > [ログとプロファイル] に移動してこの変更を行います。ログ レベルとログ ファイルの場所の変更の詳細については、「ログとプロファイル」を参照してください。
ログ エントリの例
ログ ファイルに表示されるエントリを確認するには、以下の例を参照してください。
課題に該当するカスタム フィールド (非表示になっておらず、コンテキストに含まれる) の一覧を表示するエントリは、次のようになります。
DEBUG: Visible custom fields: [customfield_10104, customfield_10105, issuetype, customfield_10000, priority, customfield_10100]
新しい NonnullCustomFieldProvider API (現在は Jira システム フィールドにのみ適用可能) を使用するカスタム フィールドと課題の既存の値を含むエントリは、次のようになります。
DEBUG: Persisted custom fields: []
一致するインデクサの数を、課題のインデクサの合計数と比較して表示するエントリは、次のようになります。
DEBUG: Number of visible indexers 3 out of 8 custom field indexes
呼び出されたインデクサーの詳細と、課題で利用可能なすべてのインデクサーを含む、trace レベルのエントリの例です。
TRACE: Visible custom field indexers: [CustomFieldIndexerAdapter{delegate=FieldIndexerWithStats{delegate=com.atlassian.greenhopper.customfield.epiclink.EpicLinkCustomFieldIndexer@49d88503, isKnown=false, stats=com.atlassian.jira.issue.index.indexers.FieldIndexerWithStats$MutableFieldIndexerStats@4c3e7b67}, field=Epic Link}] TRACE: All custom field indexers: [CustomFieldIndexerAdapter{delegate=FieldIndexerWithStats{delegate=com.atlassian.jira.issue.index.indexers.impl.NumberCustomFieldIndexer@197d6f82, isKnown=false, stats=com.atlassian.jira.issue.index.indexers.FieldIndexerWithStats$MutableFieldIndexerStats@7e26c275}, field=Story Points}]
この機能を無効にするにはどうすればよいですか?
問題が発生した場合は、システム プロパティを使用してこれらの機能を無効化できます (再起動が必要です)。
jira.cfv.driven.indexing.disabled
=true: 値によるインデクサのフィルタリングを無効にするjira.local.context.indexing.disabled
=true: コンテキストによるインデクサのフィルタリングを無効にする
注: 並べ替えの最適化を無効化する場合を除き、完全な再インデックスは不要です (以下を参照)。
Lucene インデックスから冗長なデータを削除する
JQL では、"ORDER BY" 句を使用した、カスタム フィールド値による並べ替えがサポートされます。
project = MyProject ORDER BY MyCustomField
Jira 8 以前では、Lucene ではカスタム フィールドに値が割り当てられているかどうかにかかわらず、並べ替えを適切に処理するためにインデックスにデータを追加する必要がありました。新しい Lucene ではこれを排除し、フィールドに値が割り当てられている場合にのみデータを保存できるようになりました。
これにより、(値が割り当てられていないカスタム フィールドの数に応じて) インスタンス上のインデックスのサイズを縮小できます。
この機能を無効にするにはどうすればよいですか?
システム プロパティ jira.
skip.indexing.null.disabled=true
を使用してこの機能を無効化できます (再起動が必要です)。また、インデックスを元の状態に戻すために、インデックスの完全な再作成をトリガーする必要もあります。これにより、値によるフィールド インデクサーのフィルタリングもオフになることに注意してください。
技術的詳細
改善の詳細について関心がある場合や、この変更による自身のアプリへの影響について確認したい場合は、カスタム フィールドの最適化に関するブログ投稿をご覧ください。