同じ課題を頻繁に更新したときに Jira Service Management でデッドロックが発生する

お困りですか?

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

コミュニティに質問

If you have an automated process that keeps updating the same issue many times, it might lead to deadlocks after you upgrade to Jira Service Management 4.3 or later. Read on to identify whether your Jira Service Management instance is affected.

コンテキスト

In Jira Service Management 4.3, we’ve fixed two issues to improve the overall performance. One of the changes included bounding the thread pools, so limiting the number of concurrent threads:

Our tests have shown significant performance improvements across whole Jira Service Management. However, bounded thread pools can lead to problems in some cases.

問題

次のシナリオの場合に、バウンドされたスレッド プールがデッドロックを引き起こす可能性があります。

  1. インスタンスで OffThreadExecution が有効化されている

  2. インスタンスに同じ課題を更新し続ける自動化プロセスがある (1 分間に複数回)

Related ticket:  JSDSERVER-6717 - Getting issue details... STATUS

診断

To check if your Jira Service Management is affected, you can run the following query periodically during peak times: 

PostgreSQL

select p.pkey, i.issuenum, issueid, count(*) count_updated
from (
         SELECT g.issueid, g.created as date
         FROM changegroup g -- all issue edits
         UNION ALL
         SELECT a.issueid, a.updated as date
         FROM jiraaction a -- all comments
     ) as all_events
         join jiraissue i on i.id = issueid
         join project p on p.id = i.project
WHERE date > now() - interval '1 minute'
group by 1, 2, 3
order by 4 desc;

Oracle

select p.pkey, i.issuenum, issueid, count(*) count_updated
from (
         SELECT g.issueid, g.created as ddate
         FROM changegroup g -- all issue edits
         UNION ALL
         SELECT a.issueid, a.updated as ddate
         FROM jiraaction a -- all comments
     ) all_events
         join jiraissue i on i.id = issueid
         join project p on p.id = i.project
WHERE ddate > CURRENT_DATE - interval '1' minute
group by p.pkey, i.issuenum, issueid
order by 4 desc;


If the query shows that your Jira Service Management is updating any issue many times per minute, your instance may be affected by this issue. Tests have shown that up to 60 updates per minute on a single issue shouldn’t be a problem.

課題の更新の数に急激なスパイクがあり、それがスレッド プールのスレッドの数を超過した場合、同様にデッドロックが発生する可能性があります。このようなデッドロックは自動的に解消されますが、一部の課題の SLA が破損することがあります。

他の診断方法

Another query that may indicate your Jira Service Management is affected by this issue is the following:

select * 
from "AO_319474_MESSAGE"
where "CLAIMANT" = NULL and "CLAIM_COUNT" > 0;


このクエリで、少数のイベントが要求されていないが、要求数が大きいことが示される場合、ご利用のインスタンスはこの問題の影響を受けている可能性があります。

ソリューション

Jira Service Management 4.9 and above

In Jira Service Management 4.9, we've improved the reliability of SLA processing. These changes are hidden behind a feature flag, so if this problem occurs, enable the feature flag sd.internal.base.db.backed.completion.events as per the steps in this KB article https://confluence.atlassian.com/jirakb/enable-dark-feature-in-jira-959286331.html.

Jira Service Management 4.3 - 4.8

If you are on a Jira Service Management version between 4.3 and 4.8, you can fix this issue by making changes in the database.

  1. データベースに対して次のクエリを実行し、sd.event.processing.async.thread.pool.count プロパティが存在するかどうかを確認します。 

    select * from propertyentry where property_key='sd.event.processing.async.thread.pool.count'
  2. このプロパティがあるかどうかに応じ、次のいずれかのステップを完了します。


    1. If the property doesn’t exist, use this query.  Take into consideration that the default value is 5.

      //This gives the id to use in the next queries.
      select max(id) + 1 from propertyentry; 
      
      insert into propertyentry(id, entity_name, entity_id, property_key, propertytype) values (<id from previous query>, 'sd-internal-base-plugin', 1, 'sd.event.processing.async.thread.pool.count', 3);
      
      insert into propertynumber values (<id from the first query>, <new pool size value>);
    2. プロパティが存在する場合、次のクエリを使用します。 

      update propertynumber set propertyvalue=<new pool size value> where id=<id present in the propertyentry table>;
  3. sd.event.processing.async.thread.pool.count をノードで利用可能なスレッド数未満に更新することで、全体的なパフォーマンスを改善できます。大きい値にしても、パフォーマンスが改善されるわけではありません。


追加ステップ

OffThreadEventJobRunner を大きな値に設定した場合、当初解決しようとしていた問題の 1 つが再発する可能性があります。このため、利用可能なデータベース コネクションの数も同様に増やす必要があります。

JSDSERVER-5732 - 課題情報を取得中... ステータス

利用可能なデータベース コネクションを増やす方法については「データベース コネクションのチューニング」をご確認ください。

最終更新日 2021 年 7 月 12 日

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

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