クラウド
Data Center と Server 9.3
バージョン

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

Jira アプリケーションのデータベースへの接続

このページの内容

このセクションの項目

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

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

コミュニティに質問

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 configuration tool Advanced tab option

 dbconfig.xml の要素

既定値

説明

最大サイズ

pool-max-size

20

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

ヒント

This value should be large enough so that Jira rarely needs to wait for a database connection to become available when Jira requires one.

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

最大アイドル状態

pool-max-idle

Maximum Size の値

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

ヒント
  • この値を負に設定すると、プール内でアイドル状態のまま存在可能なデータベース接続の最大数は無制限になります。
  • By default, the value of the Minimum Idle and Minimum Size settings is the same as the value of Maximum Size. As a result, Maximum Idle has no effect.
最小サイズ

pool-min-size

(min-idle)

Maximum Size の値

The minimum number of idle database connections that can be open at any time.

Why are the default values of Minimum Size and Maximum Size the same?

The default value of Minimum Size is the same as of Maximum Size. This means that the pool will always have a fixed number of connections, and that idle connections will never be closed.

If your Jira installation is large, setting a smaller value for Minimum Size will help you conserve resources.

Minimum Idle

pool-min-idle

Value of Minimum SizeThe minimum number of database connections that are allowed to remain idle in the pool
初期サイズ

pool-initial-size

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

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

This setting is not usually configured to other values than the default one, because database connections are created fast when Jira starts up.

最大待機時間

pool-max-wait

30000

The length of time in milliseconds when Jira is allowed to wait for a database connection to become available before returning an error, while there are no free ones in the pool.

ヒント
  • Specifying the value -1 makes Tomcat wait indefinitely.
  • You should set the time that is long enough to allow any contention spikes and short enough so that users will receive a meaningful error rather than just getting no response or a browser timeout.

高度な設定

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

プールステートメント

pool-prepared-statements

false
(when not specified in dbconfig.xml)

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

Do not change the default value as it will cause exceptions. For more information, see JRA-44908 - Getting issue details... STATUS

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

max-open-prepared-statements

0
(when not specified in dbconfig.xml)

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

Do not change the default value as it will cause exceptions.

バリデーションクエリ

validation-query

select 1
(for MySQL)

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

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

What validation query is recommended for what database?

MySQL – select 1

Microsoft SQL Server – select 1

Oracle – select 1 from dual

PostgreSQL – select version();

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

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

validation-query-timeout

3
(for MySQL)

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

Set it only for MySQL. Using the Validation Query Timeout setting on any other database will negatively impact the performance of your Jira instance.

The length of time must be quite short because the Validation Query should be designed to do a minimum amount of work.

ヒント

If you specify the Validation Query, you must specify a value for the Validation Query Timeout too.

If not, the value of -1 is assumed by default. This results in the system waiting indefinitely until a validation query succeeds against a broken database connection.

借りるときにテスト

pool-test-on-borrow

true (when not specified in  dbconfig.xml )

(info) This doesn't take effect unless a Validation Query has been explicitly specified. The exception is MySQL that has a default Validation Query, and it will therefore have an effect.

Tests if a database connection is valid when it's borrowed from the database connection pool by Jira.

ヒント
  • If the database connection is broken, it's removed from the pool.
  • For Jira to borrow a connection for each database operation, set the value to false.
  • If you have issues with closing database connections, try setting this option to true. Note that this should only be used as the last resort and only in the case where decreasing the value of Time Between Eviction Runs hasn't reduced or prevented issues with closing database connections.
返却時にテスト

pool-test-on-return

false
(when not specified in dbconfig.xml)

Tests if a database connection is valid when it's returned to the database connection pool by Jira.

ヒント
  • If the database connection is broken, it's removed from the pool.
  • For Jira to borrow a connection for each database operation, set the value to false.
アイドル状態にテスト

pool-test-while-idle

  • true for MySQL
  • false when not specified in dbconfig.xml

Periodically tests if a database connection is valid when it's idle.

ヒント
  • Set Test While Idle only if you have set a Validation Query.
  • If the database connection is broken, it's removed from the pool.
A note on MySQL

By default, MySQL database servers close database connections if they aren't used for an extended period of time.

This causes problems with Jira installations that use MySQL databases and are largely inactive for long periods, for example overnight. Setting Test While Idle to true is a workaround for this behavior.

追い出し実行間の時間

time-between-eviction-runs-millis

  • 300000 for MySQL
  • 5000 for HSQLDB

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

The number of milliseconds to sleep between runs of an idle object eviction thread. When non-positive, no idle object eviction thread will be run.

The eviction thread will remove idle database connections when the number of idle connections exceeds Minimum Idle or Maximum Size.

ヒント
  • The value should be set to a positive but largish number for MySQL so the evictor runs and tests connections. A reasonable value should be 300000 (5 minutes).
  • If you continue having issues with closing database connections, try setting a lower value.
追い出し可能な最小限のアイドル時間

min-evictable-idle-time-millis

  • 60000 for MySQL
  • 4000 for HSQLDB

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

The minimum amount of time an object can sit idle in a database connection pool before it's eligible for eviction.
クローズ漏れの削除

pool-remove-abandoned

true

The flag to remove abandoned database connections if they exceed Removed Abandoned Timeout.

Do not change the default value. So, the pool will be able to recover any abandoned connections and prevent impact on the system performance.

ヒント

If an internal failure occurs, Jira can borrow a connection and never return it. If this happens too often, the pool will run short of database connections, causing Jira performance to degrade or Jira to fail.

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

pool-remove-abandoned-timeout

300

The length of time in seconds when a database connection can be idle before it's considered abandoned.

接続プールの監視

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

Last modified on Mar 14, 2023

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

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

このセクションの項目

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.