Memory and performance issues in Jira Server while using EazyBI integration
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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.
*Except Fisheye and Crucible
Summary
Jira is experiencing routine performance issues and heap usage spikes which can be identified through monitoring tools and/or garbage collection logs.
You may also see spikes in database reads that are occurring at the same time each day.
Environment
Jira 8.x with eazyBI Reports and Charts for Jira installed.
Diagnosis
The following symptoms may be present:
In the
<jira-install>/log/catalina.out
– there are long-running threads serving cube queries:
1
2
3
4
5
6
7
8
9
10
11
12
/plugins/servlet/eazybi/eazy/accounts/3/cubes/Issues/query] and may be stuck (configured threshold for this StuckThreadDetectionValve is [120] seconds). There is/are [1] thread(s) in total that are monitored by this Valve and may be stuck.
java.lang.Throwable
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at mondrian.rolap.RolapResultShepherd.shepherdExecution(RolapResultShepherd.java:150)
at mondrian.rolap.RolapConnection.execute(RolapConnection.java:597)
at mondrian.olap4j.MondrianOlap4jCellSet.execute(MondrianOlap4jCellSet.java:88)
at mondrian.olap4j.MondrianOlap4jStatement.executeOlapQueryInternal(MondrianOlap4jStatement.java:415)
at mondrian.olap4j.MondrianOlap4jPreparedStatement.executeQuery(MondrianOlap4jPreparedStatement.java:72)
at sun.reflect.GeneratedMethodAccessor2987.invoke(Unknown Source)
There may also be
OutOfMemory
errors showing in the eazyBI logs:
1
ERROR: [:] [Mondrian::OLAP::Error] org.olap4j.OlapException: mondrian gave exception while executing query / OutOfMemory
You may also see from the EazyBI logs, scheduled / background job running in an exact time-frame, as the example below, which is running every 20 minutes after the hour, and later again every 50 minutes after the hour, this pattern could also matches with Database Reads Spikes.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2022-02-08 05:20:00 -0500 INFO: [regular_import 10] *** SourceApplication id=10 perform_import start ***
2022-02-08 05:20:00 -0500 INFO: [regular_import 10] account 11 : get_custom_fields
2022-02-08 05:20:05 -0500 INFO: [regular_import 10] Dwh::OlapConnectionPool flush_unused_olap_schemas flushed 0 schemas from total 0 schemas (0.000 sec)
2022-02-08 05:20:05 -0500 INFO: [regular_import 10] account 11 : get_jira_server_info
2022-02-08 05:20:05 -0500 INFO: [regular_import 10] account 11 : import_projects DSO
2022-02-08 05:20:05 -0500 INFO: [regular_import 10] account 11 : import_all_components
2022-02-08 05:20:05 -0500 INFO: [regular_import 10] account 11 : import_issues
2022-02-08 05:20:05 -0500 INFO: [regular_import 10] account 11 : check_import_issues_options 2 previously changed sprints added
2022-02-08 05:20:05 -0500 INFO: [regular_import 10] account 11 : check_sprint_date_changes will check 2 sprints
2022-02-08 05:20:06 -0500 INFO: [regular_import 10] account 11 : import_issues using importer max size 4, available cores 4
2022-02-08 05:20:06 -0500 INFO: [regular_import 10] account 11 : each_search_result (jira_search 0.005 sec)
2022-02-08 05:20:06 -0500 INFO: [regular_import 10] account 11 : check_not_updated_issues
2022-02-08 05:20:06 -0500 INFO: [regular_import 10] account 11 : import_issues using importer max size 4, available cores 4
2022-02-08 05:20:09 -0500 INFO: [regular_import 10] account 11 : each_search_result (jira_search 0.325 sec, issue_as_json 0.179 sec, yield_issue 2.548 sec)
2022-02-08 05:20:10 -0500 INFO: [regular_import 10] account 11 : check_issues_for_reimport re-importing 168 issues:
2022-02-08 05:20:10 -0500 INFO: [regular_import 10] DSO-5195,DSO-5466,DSO-5467,DSO-5468,DSO-5469,DSO-5470,DSO-5471,DSO-5472,DSO-5473,DSO-5474,DSO-5475,DSO-5476,DSO-5477,DSO-5478,DSO-5479,DSO-5480,DSO-5481,DSO-5482,DSO-5483,DSO-5484,DSO-5485,DSO-5767,DSO-5846,DSO-5852,DSO-5853,DSO-5854,DSO-5949,DSO-5952,DSO-5953,DSO-5955,DSO-6595,DSO-6596,DSO-6597,DSO-6598,DSO-6599,DSO-6726,DSO-6727,DSO-6848,DSO-6849,DSO-6850,DSO-6851,DSO-7033,DSO-7034,DSO-7037,DSO-7038,DSO-7039,DSO-7041,DSO-7052,DSO-7054,DSO-7058,DSO-7086,DSO-7107,DSO-7108,DSO-7109,DSO-7110,DSO-7111,DSO-7112,DSO-7113,DSO-7114,DSO-7115,DSO-7126,DSO-7127,DSO-7128,DSO-7129,DSO-7130,DSO-7132,DSO-7133,DSO-7134,DSO-7135,DSO-7136,DSO-7137,DSO-7138,DSO-7139,DSO-7140,DSO-7146,DSO-7147,DSO-7148,DSO-7155,DSO-7156,DSO-7157,DSO-7159,DSO-7160,DSO-7162,DSO-7163,DSO-7164,DSO-7165,DSO-7166,DSO-7169,DSO-7170,DSO-7171,DSO-7173,DSO-7174,DSO-7175,DSO-7176,DSO-7178,DSO-7179,DSO-7180,DSO-7181,DSO-7182,DSO-7183,DSO-7184,DSO-7186,DSO-7197,DSO-7199,DSO-7200,DSO-7201,DSO-7202,DSO-7203,DSO-7204,DSO-7205,DSO-7206,DSO-7207,DSO-7208,DSO-7209,DSO-7210,DSO-7212,DSO-7213,DSO-7214,DSO-7215,DSO-7216,DSO-7217,DSO-7218,DSO-7219,DSO-7220,DSO-7221,DSO-7222,DSO-7223,DSO-7224,DSO-7225,DSO-7226,DSO-7227,DSO-7228,DSO-7229,DSO-7230,DSO-7235,DSO-7236,DSO-7237,DSO-7238,DSO-7239,DSO-7240,DSO-7241,DSO-7242,DSO-7244,DSO-7245,DSO-7246,DSO-7248,DSO-7249,DSO-7250,DSO-7251,DSO-7252,DSO-7253,DSO-7254,DSO-7255,DSO-7256,DSO-7257,DSO-7258,DSO-7259,DSO-7260,DSO-7261,DSO-7262,DSO-7263,DSO-7264,DSO-7265,DSO-7267,DSO-7268,DSO-7269,DSO-7270,DSO-7271
2022-02-08 05:20:10 -0500 INFO: [regular_import 10] account 11 : import_issues using importer max size 4, available cores 4
You can also locate that the plugin starts to perform an import of issues at some exact time-frame, as the example below:
1
2
3
4
5
6
7
8
9
10
11
2022-02-08 05:50:01 -0500 INFO: [regular_import 9] *** SourceApplication id=9 perform_import start ***
2022-02-08 06:20:02 -0500 INFO: [regular_import 10] *** SourceApplication id=10 perform_import start ***
2022-02-08 06:50:00 -0500 INFO: [regular_import 9] *** SourceApplication id=9 perform_import start ***
2022-02-08 07:20:01 -0500 INFO: [regular_import 2] *** SourceApplication id=2 perform_import start ***
2022-02-08 07:50:02 -0500 INFO: [regular_import 9] *** SourceApplication id=9 perform_import start ***
2022-02-08 08:20:00 -0500 INFO: [regular_import 10] *** SourceApplication id=10 perform_import start ***
2022-02-08 08:50:01 -0500 INFO: [regular_import 9] *** SourceApplication id=9 perform_import start ***
2022-02-08 09:20:02 -0500 INFO: [regular_import 2] *** SourceApplication id=2 perform_import start ***
2022-02-08 09:50:00 -0500 INFO: [regular_import 9] *** SourceApplication id=9 perform_import start ***
2022-02-08 10:20:01 -0500 INFO: [regular_import 2] *** SourceApplication id=2 perform_import start ***
2022-02-08 10:50:02 -0500 INFO: [regular_import 9] *** SourceApplication id=9 perform_import start ***
Cause
As outlined in the documentation from Eazy-Bi at Eazy-bi Documentation:
-------------------------
Background job queues
There are several background job queues in eazyBI:
regular_import – for source application imports that are scheduled at a regular frequency.
application_import – for source application imports that are started manually.
file_import – for uploaded source file imports.
dashboard_email – sending emails for dashboard email subscriptions.
You can see the status of background job queues from the eazyBI System administration / Background jobs page.
-------------------------
This behavior is related to the eazyBI app which is outside of the Atlassian Support Offerings and expertise.
Solution
You to check the eazyBI System administration console to see if you can modify or stop these background job queues from running and check if the DB CPU spikes will cease. If they do cease, we can confirm the DB spikes is from this plugin.
Please try upgrading the app to the latest available version for your Jira version.
Otherwise, you can reach out to the eazyBI Support team for suggestions on how to improve the performance of these queries:
Was this helpful?