日頃より、弊社をご愛顧いただきまして誠にありがとうございます。この度、ゴーツーラボ 株式会社が営むアトラシアン製品ライセンスの販売および SI サービスの提供事業をリックソフト 株式会社に譲渡することで合意し、事業譲渡契約を締結する運びとなりました。詳細については、「事業譲渡に関するお知らせ」をご参照ください。

JIRA のパフォーマンス最適化

2010-09-27 (Mon)  •  By 伊藤  •  ドキュメント  •  Jira 翻訳

今回の記事は、JIRA 4.1 管理ドキュメント「Optimising Performance 」の弊社翻訳版です。原文と差異がある場合は、原文の内容が優先されます。

プロファイリング

パフォーマンスの問題を計測するために、JIRA のプロファイリング機能を有効にしてください。次に、ログで必要な各 URL に関するプロファイルを取得します。

[Filter: profiling] Turning filter on [jira_profile=on]
[116ms] - /secure/Dashboard.jspa
  [5ms] - IssueManager.execute()
    [5ms] - IssueManager.execute()
      [5ms] - Searching Issues
  [29ms] - IssueManager.execute()
    [29ms] - IssueManager.execute()
      [29ms] - Searching Issues
        [28ms] - Lucene Query
          [23ms] - Lucene Search

JIRA におけるパフォーマンスの問題のひとつは、稼動中のアプリケーション サーバーにある場合があります。データベース接続プール、JSP コンパイル時間、およびリソースの割り当てはアプリケーション サーバーによって異なります。遅いサーバーとしては JBoss 3.x、Tomcat 4.0 および Tomcat 4.1.24 が知られています。現時点で JIRA にとって最速のサーバーは、これらより新しいバージョンの Tomcat、Resin、および Orion です。

データベースもパフォーマンスに大きな影響を与える場合があります。特にネットワーク経由でデータベースにアクセスしている場合、または正しくインデックス処理がなされていない場合はなおさらです。

アプリケーション サーバーを変更できない場合、パフォーマンス改善策としてサーバーおよびデータベースの調整が考えられます。また、特定の JIRA オプションの設定変更もあげられます。

環境オプション

ウィルス チェック

JIRA の速度低下が発生している場合、ウィルス チェックを無効にした状態で JIRA を起動してみてください。JIRA は数多くの一時ファイルを作成するので、ウィルス チェック ソフトウェアは JIRA の速度を大幅に低下させる可能性があります。特に McAfee の NetShield 4.5 ではスキャンするフォルダーを除外できると明記されていますが、実際にはそうではありません。これを修正するには 7.0.0 へのアップグレードが必要です。Symantec はアンインストールする必要があります。サービスを停止しても JIRA の速度低下を招くことが確認されています。

ネットワーク共有

JIRA はローカルのファイル システムへの高速なアクセスが必要です。JIRA またはそのインデックス ディレクトリを (SMB や NFS など) ネットワーク共有上にホストしている場合、パフォーマンスの大幅な低下の原因になります。JIRA を高速なローカル ディスク アクセスで稼動してください。

SSL や HTTPS

組織によっては JIRA を SSL や HTTPS 上で稼動する必要があるかもしれませんが、これはパフォーマンスに影響を及ぼす可能性があることに留意してください。

データベース オプション

JDBC ドライバー

JDBC ドライバーごとにパフォーマンス特性は異なります。お使いのデータベースに対して、最新のパッチ バージョンの JDBC ドライバーを必ず使用してください。

データベース

JIRA スタンドアロン版 (および多くのアプリケーション サーバー) は HSQLDB といったインメモリ データベースが同梱されています。通常、他のデータベース (MySQL、PostgreSQL、または Oracle) を使用することでパフォーマンスの改善につながります。

ネットワーク待ち時間

データベース サーバーと JIRA をホストしているサーバー間の待ち時間がパフォーマンスの問題の原因になる可能性があります。データベースが JIRA とは別のサーバー上にホストされている場合、そのサーバー間の Ping 時間を確認してください。

データベースのインデックス作成

JIRA 3.0 以降では、データベースを最初に作成した際に自動的にそのデータベースのインデックスが作成されます。しかし、以前のバージョンからの JIRA のインプレース アップグレードを行った場合 (データベース テーブルのドロップや再作成をしない場合)、データベースのインデックス処理は行われません。XML の完全バックアップを作成し、空のデータベースに復元すると、これが修正されます。追加のインデックスを手動で作成可能ですが、たいていの場合、この作業は必要ありません。

JDK オプション

最新の JDK バージョンの選択

最新の JDK には、JIRA のパフォーマンスを向上させるパフォーマンス最適化が含まれています。JIRA は数多くのリフレクションを使用していますが、これらはリリース 1.4 で大幅に改善されたものです。

サーバー JVM の使用

Sun は、クライアント バージョンとサーバー バージョンの 2 種類の JDK をリリースしています。これらは、メモリ管理やインライン最適化などで異なる特性を持っています。"java -server -jar <app-server-jar>.jar" といっ具合にアプリケーション サーバーを明示的に起動する必要がある場合があります。ただし、JDK 1.5 の場合はこれを設定しないのが最適です。

十分なメモリの割り当て

既定では、多くのアプリケーション サーバーは JIRA が最適な速度で稼動するのに十分なメモリで起動していません。メモリが不足するとガベージ コレクションの時間が増大します。ガベージ コレクションがより頻繁に実行されなければならないためです。

メモリ不足が速度低下の原因となっているかを確認するには、以下のパラメーターを JIRA の起動コマンドに追加してください。

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc -Xloggc:${LOG}/gc.log

ただし、${LOG}/ はログ ディレクトリへのファイルシステム パスです。ガベージ コレクション タイムが gc.log に記録されます。

"java -server -Xms100m -Xmx300m <app-server-jar>.jar" のようにしてアプリケーション サーバーを起動する必要が場合があります。詳細については、「JIRA のメモリを増やす」 をご参照ください。

JIRA オプション

GZip 圧縮の有効化

JIRA はサーバーとブラウザー間でページ コンテンツを圧縮できます。その結果、特に接続速度が遅い場合などにパフォーマンスが改善されます。GZip 圧縮が有効になっているかの確認は、管理 -> グローバル設定 -> 一般設定で行えます (ただし、mod_proxy を使用していない場合)。

JIRA スタンドアロン版における HSQLDB パラメーターの削除

JIRA スタンドアロン版を使用しており、かつ外部データベースを使用している場合、conf/server.xml 内の minEvictableIdleTimeMillis="4000" および timeBetweenEvictionRunsMillis="5000" の行を削除することを忘れないでください。さもないと、パフォーマンスの低下につながります。

<Resource name="jdbc/JiraDS" auth="Container" type="javax.sql.DataSource"
   username="jirauser"
   password="jirapassword"
   driverClassName="com.mysql.jdbc.Driver"
   url="jdbc:mysql://localhost/jiradb?autoReconnect=true"
   minEvictableIdleTimeMillis="4000"
   timeBetweenEvictionRunsMillis="5000"
   />

外部ユーザー管理

外部ユーザー管理を有効にしている場合 (既定では無効になっています)、JIRA はユーザーおよびグループのキャッシュを作成しません。その結果、アクセスの速度低下につながる場合があります。

アプリケーション サーバー オプション

データベース接続プール

データベースへの接続は負荷のかかる操作であり、ほとんどのアプリケーション サーバーではこの負荷を減らすためにオープンな接続のプールを維持します。プールされた接続の数が十分か、期限切れの回数が理にかなっているかを確認することをお勧めします。

JIRA のスタンドアロン版または Apache Tomcat を使用している場合は、Tomcat の server.xml (または JIRA のセットアップ方法によっては jira.xml) の DBCP 接続プールを変更できます。 

<Resource name="jdbc/JiraDS" auth="Container" type="javax.sql.DataSource"
username="sa"
password=""
driverClassName="org.hsqldb.jdbcDriver"
url="jdbc:hsqldb:${catalina.home}/database/jiradb"
minEvictableIdleTimeMillis="4000"
timeBetweenEvictionRunsMillis="5000"
maxActive="20"
     minIdle="4"
     maxIdle="8"
/>

これらの値の意味についての詳細は、Apache DBCP のマニュアルを参照してください。

他のアプリケーション サーバーのチューニングも有効です。詳細については、お使いのアプリケーション サーバーのマニュアルを参照してください。

サーバーの仕様

JIRA のパフォーマンスは CPU および利用可能なメモリに大きく依存します。物理メモリの不足や大きすぎる最大ヒープ サイズの設定 (-Xmx フラグ) は JIRA のパフォーマンスに深刻な影響を与える可能性があります。メモリ アクセスは、メモリとディスク (仮想メモリ) 間での絶え間ないデータのスワップにつながるためです。

Windows の場合、タスク マネージャーを使用することでシステムが何を行っているかを確認できます。

Linux/Solaris の場合、vmstat 1 を実行することで仮想メモリおよび CPU 統計が出力されます。

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 9  0 520512  27132  15216 318944    3    2    65    40    0     3 10  3 85  2
12  0 520512  27004  15216 319080    0    0   104     0 2041 10992 88  8  3  0
20  0 520512  26764  15228 319068    0    0     0   436 2196 12869 85 13  2  0
11  0 520512  26700  15228 319068    0    0     0     0 1959  4041 88  9  4  0
20  0 520512  25724  15228 319068    0    0     0     4 2137  3307 84 14  2  0
17  0 520512  25724  15228 319068    0    0     4     0 2017 10488 89  8  3  0
 9  0 520512  25468  15228 319068    0    0     0     0 1886  7532 86 11  3  0
...

これは CPU 使用率 97% というかなりジビーなサーバーですが、幸いなことにスワッピングは起きていません。

vmstat -n 1 > vmstat.log と入力することで、このシステム情報を長期に渡って取得可能です。

Linux の場合、CPU およびメモリ情報はそれぞれ cat /proc/cpuinfo および cat /proc/meminfo で取得できます。

サポート リクエストを提出する場合は、この情報 (vmstat 1, /proc/cpuinfo,, /proc/meminfo) を含めてください。

  前の記事 次の記事  

関連記事