データベース接続のチューニング

Jira は Apache Commons DBCP に基づく DBCP (データベース接続プール) によって、基盤となるデータベースへの Jira のアクセスを管理します。

Jira の以前のバージョンでは、データベース コネクション プールは Jira を実行している Apache Tomcat アプリケーション サーバー経由でのみ処理されていました。

Jira バージョン 4.4 以降では Jira の dbconfig.xml ファイルが一連のデータベース接続プール設定を Tomcat に渡して、Tomcat がそれを利用して Jira のデータベース接続プールを管理するようになっています。

Jira バージョン 5.1 以降では、Jira の dbconfig.xml ファイルで定義できるデータベース接続プールの設定数が大幅に増えました。

このページでは、Jira のデータベース接続プールを調整する方法を説明します。Jira 設定ツールを使用する方法と、Jira の dbconfig.xml ファイルを直接編集する方法があります (以降のセクション参照)。

Jira のデータベース接続プールの設定と管理には、Jira 設定ツール詳細タブを使用することをお勧めします。データベース監視ページ (Jira システム管理者がアクセス可能) には、Jira のデータベース接続の使用状況を視覚的に監視するツールが用意されています。

On this page:

接続プールアーキテクチャー

Jira がデータベースにアクセスする (読み込みまたは書き込みを行う) 必要がある際は、データベース接続が必要になります。

データベース接続は複雑で大規模なオブジェクトで、JIRA とそのデータベース間のすべての通信を処理します。したがって、データベース接続の確立は時間のかかる処理であり、クライアント (Jira アプリケーション) とデータベース サーバーの両方で大量のメモリーを消費します。

Jira のデータベース アクセス リクエストに対して毎回新しいデータベース接続を確立すると発生する高負荷な処理を回避するために、事前に確立済みのテータベース接続プールが維持されます。Jira からの新たなデータベース アクセス リクエストのたびに、この事前に確立済みのテータベース接続プールからコネクションが使用されます。この結果、次のようになります。

  1. Jira の起動時にはプール内において Jira とデータベース間の最小限のデータベース コネクションが確立されます。
  2. Jira がデータベースにアクセスする必要がある際は、次のような処理が行われます。
    1. プールに対してデータベース接続を要求します
    2. そのデータベース接続を使用してデータベースの読み出しまたは書き込みを行います
    3. 処理が終了するとデータベース接続をプールに戻す

Jira のデータベース アクセス リクエストの頻度がプールで利用可能な接続数を超え始めた場合は、負荷を処理するために接続が自動で作成されます。

逆に、Jira のデータベース アクセス リクエストの頻度がプールで利用可能なデータベース接続数を下回り始めると、接続を自動で閉じてリソースをシステムに返すようにできます。

最近のデータベースは十分なメモリーさえあれば数百の接続を比較的簡単に処理できますが、クライアント側ではこれらの接続は大量のメモリーを消費します。そのため、最大接続数をそれよりずっと小さい数に制限して、接続する必要が生じたアプリケーションが待つことなく接続を利用できるようにするのが一般的です。

Jira のデータベース接続をチューニング

  1. Jira インストールをシャットダウンします。
  2. 次のいずれかのオプションを選択して進めます。

Jira 設定ツールによって Jira のデータベース接続を調整します。

  1. 次の手順で Jira 設定ツールを起動します。
    Jira 設定ツールを実行するには、JAVA_HOME 環境変数を設定する必要が生じる場合があります。詳細については「Java のインストール」をご参照ください。
  2. Jira 設定ツールが起動したら [詳細] タブをクリックします。
    Jira 設定ツール。
  3. このタブで利用可能なオプションの詳細については「接続プールの設定」をご参照ください。これらのオプションの値を指定するには、先にその一番左のチェックボックスをチェックする必要があります。

    前のスクリーンショットのいくつかのオプションは単純なチェックボックスです。これらのチェックボックスをチェックするとそれに関連するオプションの値が「true」に、逆にチェックを外すとそれに関連するオプションの値が「false」に設定されます。

  4. 変更を保存します。これらは要素として dbconfig.xml ファイルに保存されます。

dbconfig.xml ファイルを編集して Jira のデータベース接続を開始する

次の手順に従って、Jira ホーム ディレクトリのルートにある dbconfig.xml ファイルを編集します。

  1. Jira のデータベース接続微調整するために dbconfig.xml ファイルに追加できる要素の詳細については「接続プールの設定」をご参照ください。
  2. 編集済みの dbconfig.xml ファイルを保存します。
  3. Jira インストールを再起動します。

DBCP 設定

  • 設定の既定値は、次のいずれかが実行された後に dbconfig.xml ファイルに書き込まれます。
    • Jira セットアップ ウィザードを実行した。
    • すべてのオプションで左端のチェックボックスをチェックしていない場合でも、Jira 設定ツールの [詳細設定] タブによってデータベース接続を設定した
  • 設定の既定値で注記「dbconfig.xml で指定されていない場合」が表示された場合は、次のいずれかを意味します。 
    • Jira セットアップ ウィザードを実行した後、関連要素が dbconfig.xml ファイルに書き込まれなかった
    • 次のいずれかの方法で、関連要素が dbconfig.xml ファイルに書き込まれた。
      • 担当ユーザーが手動で書き込んだ。
      • 左端のチェックボックスをチェックしてこれらのオプションの値を設定することで、[詳細設定] タブのオプションに従って指定された。
  • 設定の既定値で注記「dbconfig.xml で指定されていない場合」が表示された場合は、dbconfig.xml ファイルに存在しなくてもシステムはこの値を考慮します。

次の表に、すべての接続プール設定とその構成を示します。

Jira 設定ツール[詳細] タブのオプション

 dbconfig.xml の要素

既定値

説明

最大サイズ

pool-max-size

20

いつでもオープンできるデータベース接続の最大数。

ヒント

この値は、Jira がデータベース接続要求を出したときにほぼ待つことなくそれを利用できるように、十分大きくなければなりません。

このパラメーターの設定方法は「接続プールの監視」セクションをご参照ください。

最大アイドル状態

pool-max-idle

Maximum Size の値

プール内でアイドル状態のまま保持可能なデータベース接続の最大数。

ヒント
  • この値を負に設定すると、プール内でアイドル状態のまま存在可能なデータベース接続の最大数は無制限になります。
  • 既定では、最小アイドル状態最小サイズの設定の値は、最大サイズの値と同じです。そのため、最大アイドル状態の効果はありません。
最小サイズ

pool-min-size

(min-idle)

Maximum Size の値

いつでもオープンできるアイドル状態のデータベース接続の最小数。

最小サイズと最大サイズの既定値が同じなのはなぜか

最小サイズの既定値は、最大サイズのデフォルト値と同じです。つまり、プールの接続数は常に固定され、アイドル接続がクローズされることはありません。

Jira インストール環境が大規模な場合は、最小サイズの値を小さく設定するとリソースの節約に役立ちます。

最小アイドル状態

pool-min-idle

最小サイズの値プール内でアイドル状態のまま保持可能なデータベース接続の最小数。
初期サイズ

pool-initial-size

0
(dbconfig.xml で指定されていない場合)

プール内でオープンされるデータベース接続の初期値。

Jira が起動されるとデータベース接続が迅速に作成されるため、通常この値を既定値以外に設定する必要はありません。

最大待機時間

pool-max-wait

30000

プールに空きデータベース接続がない場合に、データベース接続が利用可能になるまでに Jira が待機する最大時間 (ミリ秒単位)。これを過ぎるとエラーが返されます。

ヒント
  • -1 を指定すると、Tomcat は無期限に待機します。
  • この値は競合が発生してもそれに対応できるほど長い時間にする必要があると同時に、無応答やブラウザー タイムアウトになる前にユーザーに対して有意義なエラー情報を提供できるほど短い時間にする必要があります。

高度な設定

通常、次の設定は変更不要です。必要に応じて Apache DBCP ドキュメントをご参照ください。

プールステートメント

pool-prepared-statements

false
(dbconfig.xml で指定されていない場合)

データベース接続プールにおいてプリペアドステートメントのプーリングを有効にします。

例外が発生するため、既定値を変更しないでください。詳細については、JRA-44908 - 課題情報を取得中... ステータスを参照してください。

最大オープンステートメント

max-open-prepared-statements

0
(dbconfig.xml で指定されていない場合)

ステートメントプールから同時に割り当て可能な空きステートメントの最大数。

例外の原因となるため、既定値は変更しないでください

バリデーションクエリ

validation-query

select 1
(MySQL の場合)

(または、dbconfig.xml で指定なし)

接続プールから取り出された接続の検証を行う SQL クエリです。指定する場合、クエリは少なくとも1つの行を返す SQL SELECT 文でなければなりません。

どのデータベースにどのような検証クエリが推奨されるか

MySQL – select 1

Microsoft SQL Server – select 1

Oracle – select 1 from dual

PostgreSQL – select version();

詳細については、 コネクション切断の問題を乗り越える方法 を参照してください。

バリデーションクエリのタイムアウト

validation-query-timeout

3
(MySQL の場合)

(または、dbconfig.xml で指定なし)

MySQL に対してのみ設定してください。他のデータベースで検証クエリ タイムアウトの設定を使用すると、Jira インスタンスのパフォーマンスに悪影響を及ぼします。

検証クエリは処理量を最小限に抑えるように設計する必要があるため、この時間は非常に短くしてください。

ヒント

検証クエリを指定した場合は、検証クエリ タイムアウトの値も指定する必要があります。

指定しない場合は、値 -1 が既定で使用されます。その結果、システムは、切断されたデータベース接続に対して検証クエリが成功するまで無期限に待機することになります。

借りるときにテスト

pool-test-on-borrow

true (dbconfig.xml で指定されていない場合)

(info) 検証クエリが明示的に指定されていない限り、これは有効になりません。既定の検証クエリがある MySQL については、例外で有効になります。

Jira がデータベース接続プールからデータベース接続を借りたときに、それが正しく機能するかどうかをテストします。

ヒント
  • そのデータベース接続が切断されている場合はプールから削除されます。
  • Jira がデータベース操作ごとに接続を借りるようにするには、値を false に設定します。
  • テータベース接続のクローズ時に問題が発生する場合は、このオプションを true に設定してみてください。ただし、この方法は、"追い出し実行間の時間" の値を小さくしてもデータベース接続のクローズ時の問題発生を防ぐことも軽減することもできない場合の最終手段としてください。
返却時にテスト

pool-test-on-return

false
(dbconfig.xml で指定されていない場合)

Jira がデータベース接続プールにデータベース接続を返却したときに、それが正しく機能するかどうかをテストします

ヒント
  • そのデータベース接続が切断されている場合はプールから削除されます。
  • Jira がデータベース操作ごとに接続を借りるようにするには、値を false に設定します。
アイドル状態にテスト

pool-test-while-idle

  • true (MySQL の場合)
  • false (dbconfig.xml で指定されていない場合)

データベース接続がアイドル状態のときに正しく機能しているかどうかを定期的にテストします。

ヒント
  • "アイドル状態にテスト" は、検証クエリを設定した場合にのみ設定してください。
  • そのデータベース接続が切断されている場合はプールから削除されます。
MySQL に関するメモ

既定では、MySQL データベース サーバーは、データベース接続が長期間使用されていなければデータベース接続をクローズします。

MySQL データベースを利用し、アクティブに動作しない時間が長時間 (一晩など) に及ぶことが多い Jira 環境では、このことが問題となります。この動作の回避策は "アイドル状態にテスト" を true に設定することです。

追い出し実行間の時間

time-between-eviction-runs-millis

  • 300000 (MySQL の場合)
  • 5000 (HSQLDB の場合)

(または、dbconfig.xml で指定なし)

アイドル オブジェクトのエビクション スレッド実行間隔 (ミリ秒単位)。ゼロまたは負の値を指定すると、アイドル オブジェクトのエビクション スレッドは実行されません。

エビクション スレッドでは、アイドル状態にあるデータベース接続数が "最小アイドル状態" または "最大サイズ" の値を超えた場合にそれらの接続が削除されます。

ヒント
  • MySQL の場合、接続のエビクションとテストを正常に行うためにはこの値を大きめの正の値に設定します。妥当な値は 300000 (5 分) です。
  • データベース接続をクローズしても問題が解決しない場合は、小さい値を設定してみてください。
追い出し可能な最小限のアイドル時間

min-evictable-idle-time-millis

  • 60000 (MySQL の場合)
  • 4000 (HSQLDB の場合)

(または、dbconfig.xml で指定なし)

データベース接続プールでオブジェクトがアイドル状態になってから、エビクションの対象になるまでの最小時間。
クローズ漏れの削除

pool-remove-abandoned

true

データベース接続のクローズ漏れ状態が "クローズ漏れの削除のタイムアウト" の値を超えた場合にそれらのデータベース接続を削除するかどうかを示すフラグ。

既定値を変更しないでください。その結果、プールでクローズ漏れ状態の接続を復旧し、システム パフォーマンスの低下を防止できるようになります。

ヒント

内部エラーが発生した場合、Jira が借りた接続が返却されないことがあります。これが頻繁に起こると、プール内のデータベース接続が不足し、結果として Jira のパフォーマンスの低下や動作停止を引き起こす恐れがあります。

クローズ漏れの削除のタイムアウト

pool-remove-abandoned-timeout

300

データベース接続がクローズ漏れと判定されるまでのアイドル状態継続時間 (秒単位)。

接続プールの監視

Jira ではデータベース接続の使用状況を [データベース監視] ページで確認できます。詳細は「データベース接続使用率の監視」をご参照ください。

Last modified on Mar 14, 2023

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

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.