日頃より、弊社をご愛顧いただきまして誠にありがとうございます。この度、弊社は商号を「ゴーツーグループ 株式会社」から「ゴーツーラボ 株式会社」に変更いたしました。詳細については、「商号変更のお知らせ」をご参照ください。
2010-09-27 (Mon) • By 伊藤 • ドキュメント • Jira 翻訳
パフォーマンスの問題を計測するために、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 を高速なローカル ディスク アクセスで稼動してください。
組織によっては JIRA を SSL や HTTPS 上で稼動する必要があるかもしれませんが、これはパフォーマンスに影響を及ぼす可能性があることに留意してください。
JDBC ドライバーごとにパフォーマンス特性は異なります。お使いのデータベースに対して、最新のパッチ バージョンの JDBC ドライバーを必ず使用してください。
JIRA スタンドアロン版 (および多くのアプリケーション サーバー) は HSQLDB といったインメモリ データベースが同梱されています。通常、他のデータベース (MySQL、PostgreSQL、または Oracle) を使用することでパフォーマンスの改善につながります。
データベース サーバーと JIRA をホストしているサーバー間の待ち時間がパフォーマンスの問題の原因になる可能性があります。データベースが JIRA とは別のサーバー上にホストされている場合、そのサーバー間の Ping 時間を確認してください。
JIRA 3.0 以降では、データベースを最初に作成した際に自動的にそのデータベースのインデックスが作成されます。しかし、以前のバージョンからの JIRA のインプレース アップグレードを行った場合 (データベース テーブルのドロップや再作成をしない場合)、データベースのインデックス処理は行われません。XML の完全バックアップを作成し、空のデータベースに復元すると、これが修正されます。追加のインデックスを手動で作成可能ですが、たいていの場合、この作業は必要ありません。
最新の JDK には、JIRA のパフォーマンスを向上させるパフォーマンス最適化が含まれています。JIRA は数多くのリフレクションを使用していますが、これらはリリース 1.4 で大幅に改善されたものです。
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 圧縮が有効になっているかの確認は、管理 -> グローバル設定 -> 一般設定で行えます (ただし、mod_proxy
を使用していない場合)。
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
) を含めてください。