Dashboard loads slowly after upgrade to Jira server 7.1 and up

お困りですか?

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

コミュニティに質問

プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Fisheye および Crucible は除く

問題

  1. Jira 7.1 以降でダッシュボードへのアクセスに時間がかかる。
  2. ダッシュボードを使用したログインに時間がかかる。 

診断

類似の症状

You may be experiencing the symptoms described in this knowledgebase article as well: https://confluence.atlassian.com/jirakb/how-to-fix-gadget-titles-showing-as-__msg_gadget-813697086.html

環境

  • Jira 7.1 以降。
  • 新規インストールまたはアップグレード済みのインストール。

Diagnostic Steps

  • ダッシュボードのロード時の HAR ファイルを生成して HAR ファイルを http://www.softwareishard.com/har/viewer/ で開くと、ダッシュボードのロードの HTTP リクエストの受け取りで長い時間がかかっていることを確認できます。

 

  • 上記の例では、ダッシュボードのロードに 36 秒かかり、所要時間の全体が "Receiving" 状態で消費されています。
  • 遅いダッシュボードのロード中にスレッド ダンプを生成 (5 秒ごとの生成から開始することをおすすめします)し、Thread Dump Analyzer (TDA) で長期実行スレッドの分析を行うと、次のスレッドが Jira のベース URL に接続してガジェットのレンダリング データを取得する段階でスタックしていることがわかります。 

    "http-nio-8080-exec-XX uri:/secure/Dashboard.jspa username:XXXXXXX" #152 daemon prio=5 tid=0x00007f34cc408000 nid=0x63f7 runnable [0x00007f34ab8cd000]
       java.lang.Thread.State: RUNNABLE
    	at java.net.PlainSocketImpl.socketConnect(Native Method)
    	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
    	- locked <0x00000007a40a5db0> (a java.net.SocksSocketImpl)
    	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
    	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
    	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
    	at java.net.Socket.connect(Socket.java:589)
    	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:337)
    	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
    	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
    	at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
    	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
    	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
    	at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
    	at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
    	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
    	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
    	...
    	at com.atlassian.gadgets.renderer.internal.http.HttpClientFetcher.fetch(HttpClientFetcher.java:85)
    	at org.apache.shindig.gadgets.DefaultMessageBundleFactory.fetchBundle(DefaultMessageBundleFactory.java:138)
    	at org.apache.shindig.gadgets.DefaultMessageBundleFactory.getNestedBundle(DefaultMessageBundleFactory.java:111)
    	...
    	at org.apache.shindig.gadgets.DefaultMessageBundleFactory.getBundle(DefaultMessageBundleFactory.java:79)
    	at org.apache.shindig.gadgets.variables.VariableSubstituter.substitute(VariableSubstituter.java:47)
    	at com.atlassian.gadgets.renderer.internal.GadgetSpecFactoryImpl.getGadgetSpec(GadgetSpecFactoryImpl.java:127)
    	at com.atlassian.gadgets.renderer.internal.GadgetSpecFactoryImpl.getGadgetSpec(GadgetSpecFactoryImpl.java:79)
    	at sun.reflect.GeneratedMethodAccessor1358.invoke(Unknown Source)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	...
    	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)
    	at com.sun.proxy.$Proxy2003.getGadgetSpec(Unknown Source)
    	at com.atlassian.gadgets.dashboard.internal.impl.GadgetFactoryImpl.createSpecificationBasedGadget(GadgetFactoryImpl.java:120)
    	at com.atlassian.gadgets.dashboard.internal.impl.GadgetFactoryImpl.access$000(GadgetFactoryImpl.java:40)
    	at com.atlassian.gadgets.dashboard.internal.impl.GadgetFactoryImpl$1.visit(GadgetFactoryImpl.java:72)
    	at com.atlassian.gadgets.dashboard.internal.impl.GadgetFactoryImpl$1.visit(GadgetFactoryImpl.java:69)
    	at com.atlassian.gadgets.GadgetState.accept(GadgetState.java:132)
    	at com.atlassian.gadgets.dashboard.internal.impl.GadgetFactoryImpl.createDashboardItem(GadgetFactoryImpl.java:69)
    	at com.atlassian.gadgets.dashboard.internal.impl.StateConverterImpl.convertStateToGadget(StateConverterImpl.java:28)
            ...
    	at com.atlassian.gadgets.dashboard.internal.rest.representations.RepresentationFactoryImpl.createDashboardRepresentation(RepresentationFactoryImpl.java:48)
    	at com.atlassian.gadgets.dashboard.internal.velocity.DashboardEmbedder.dashboardToJsonObject(DashboardEmbedder.java:47)
    	at com.atlassian.gadgets.dashboard.internal.velocity.DashboardView.getLayoutsJson(DashboardView.java:164)
    	at com.atlassian.gadgets.dashboard.internal.velocity.DashboardView.writeTo(DashboardView.java:77)
    	at com.atlassian.jira.web.action.Dashboard$1.render(Dashboard.java:231)
    	at com.atlassian.jira.web.tags.RenderTag.doStartTag(RenderTag.java:37)

原因

Jira でダッシュボードをレンダリングするために Jira 自体 (自身のベース URL) に接続してガジェット データを取得する際に、ネットワークの問題が発生しています。

The reason for JIRA needing to connect to itself to get gadget data is for performance improvements. By offloading the processing to browsers instead of doing the rendering on the JIRA server, this effectively reduces load on the JIRA server itself. More details in https://confluence.atlassian.com/jirakb/how-to-fix-gadget-titles-showing-as-__msg_gadget-813697086.html

Jira がリバース プロキシの背後でホストされているなどの理由によって、Jira サーバーが自身のベース URL に接続する際に問題が発生し、ネットワークの問題がある場合、ダッシュボードのロードが遅延する場合があります。

他の原因として、setenv.sh ファイルで次のパラメータが構成されている可能性が考えられます。

JVM_SUPPORT_RECOMMENDED_ARGS="-Dcom.atlassian.gadgets.dashboard.ignoreCache=true"

 

ソリューション

Jira サーバーが自身のベース URL に接続可能で、setenv.sh ファイルにガジェット ダッシュボードのキャッシュ用の JVM パラメータが構成されていないことを確認します。 

(warning) In case JIRA is able to connect to its IPv6 address but the problem persists, ensure that JIRA is able to connect to its IPv4 address as well. This is because IPv6 is currently not supported:  JRA-36676 - Getting issue details... STATUS

適切に動作しているかどうかを確認するには、Jira サーバーからベース URL に ping コマンドを実行します。 

(info) この作業を行ううえで問題が発生している場合、ご利用のネットワークの管理者にお問い合わせください。アトラシアン サポートは、お客様の環境に固有のネットワークの問題に対して完全なサポートを提供することはできません。

 

 

最終更新日 2019 年 9 月 25 日

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

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