追加の SLA 設定を行う
Jira 管理者は以下の追加 SLA 設定を構成できます。
- プロジェクト管理者が SLA の新しい名前を作成できるようにする
- 時刻形式の表示方法を選択する
- デバッグ・ログ・イベントの処理方法を指定する
「管理」>「アプリ」>「SLA 設定」に移動し、変更する設定に対して「設定」を選択します。
SLA デバッグ ログ イベントをクリーンアップする
Jira Service Management 課題イベントがトリガーされるか、SLA が作成または削除されるたびに、Jira Service Management では対応する SLA が更新されます。SLA デバッグ ログ機能では、その変更を反映するエントリがデータベース (AO_54307 E_SLAAUDITLOG テーブルと AO_54307E_SLAUDITLOGDATAテーブル) に作成されます。
Jira 管理者は、SLA デバッグ ログのクリーンアップ方法を決定できます。また、データベースからイベントが削除される頻度を選択できます。
スレッド処理を設定する
Jira Service Management のパフォーマンスを向上させるため、SLA 計算はバックグラウンド タスクで実行します。このコンテキストでは、これらのタスクは並行実行のスレッドによって実行されます。
SLA 計算の処理方法とスレッド数を設定できます。
処理方法 | 説明 |
|---|---|
マルチスレッドのシリアライズ処理 (スレッド数は設定可能) | この処理方法を使用することをお勧めします。 バージョン 4.21.0 で導入されたこの新しい処理方法は自己修復に対応して、特に Jira がマルチノード クラスタ モードで実行されている際にクラスター効率と信頼性が高くなります。 この方法では、どの Jira ノードでも保存されているすべてのイベントを処理できます。インメモリ処理モードとは異なり、この方法ではアプリケーションを再起動しても SLA 処理に影響しません。クラスターにノードが 1 つしかなくても、中断が発生した場合に SLA 計算は中断された場所から再開されます。 データベースに保存されている履歴イベント データに基づいて、課題に対してイベントが発生した順序で SLA が計算されます。この方法におけるスレッド プールは 1-20 個のスレッドの範囲で設定できます。 |
マルチスレッドのインメモリ処理 (スレッド数は設定可能) | この方法は従来の処理モードと見なされます。この方法におけるスレッド プールは、シリアライズ処理方法と同様に 1-20 個のスレッドの範囲で設定できます。 このモードでは、処理されたすべてのイベントがそれらの発生元ノードにバインドされます。アプリケーションが 1 つのノードで停止すると未処理のイベントはすべて失われて (5.0 より前のバージョンでは) 手動で再構築されるまで、(5.0 以降のバージョンでは) 同じ課題に対して別のイベントが発生するまで、SLA 履歴に追加されません。 |
バックグラウンド処理なし (スレッド数は設定不可) | この方法では、すべての処理がリクエスト スレッドで実行されて、SLA 計算が終了するまで応答 (ユーザー フィードバック) がロックされます。この処理モードを選択すると、課題の作成、コメントの作成、課題のトランジションなどのアクションの体感的なパフォーマンスが大幅に低下する可能性があります。 |
SLA 計算の結果として、情報をフェッチするためにデータベースに対してクエリが実行されます。データベースでは、同時にアクティブにする接続を制限するために接続プールが使用されます。バックグラウンド処理がない場合は HTTP スレッドで動作するため、プール数は制御されません。そのため、負荷がかかるとデータベース接続プールが急速に枯渇する可能性があります。データベース接続の詳細についてご確認ください。
SLA スレッド数を設定する
マルチスレッドのシリアライズ処理またはマルチスレッドのインメモリ処理のいずれかの方法を選択した場合は、SLA 計算のスレッド プール数を 1-20 個の範囲で設定できます。スレッド数の値は、プロセッサーを再起動しなくてもすべてのノード全体で同期されます。
ノードあたりの SLA スレッドの既定数は 5 に設定されています。ただし、SLA 計算が課題の更新に追いついていない場合は、推奨されたマルチスレッドのシリアライズ処理方法によって SLA スレッド数を少しずつ増やしながらシステム応答を確認することをお勧めします。