Jira Service Management Support

If you're using Jira Service Management Data Center 4.15 or later, Assets is already included and there's no need to download anything. You can find it by selecting Assets in the top Jira navigation.

If you're using Jira Service Management Data Center 4.14 or earlier, you can install the Assets app for free from the Atlassian Marketplace.

Assets is available also for Jira Software Data Center users, but some restrictions apply depending on your Jira version. See our FAQ for details

Install the app

To install the Assets app from Atlassian Marketplace:

Log in to Jira as an admin.
Select Administration > Manage apps.
Select Find new apps, and search for Assets.
The appropriate app version appears in the results.
Follow the instructions to install the app. If you're on Data Center, this version won't need any license.
You’ll be prompted to log into MyAtlassian and Assets will begin to download.
Once downloaded, you'll see Assets in the top Jira navigation.

System requirements

We strongly believe that your Data Center instance will pull it off, but here's some system requirements, just in case.

System requirements

Make sure that Jira is configured to handle the amount of data you plan to import into Assets. If you plan to use a lot of scheduling tasks and import a large amount of data we recommend that you follow the table below.

Remember to always test the memory consumption in a test environment for a huge data set, because it's not always the number of objects, but the content of the object attributes as well at play.

Objects in Assets	JVM memory (minimum)	JVM memory (recommended)
~ 1,000,000	16 GB	20 GB
~ 2,000,000	20 GB	25 GB
~ 5,000,000	40 GB	50 GB
~ 6,000,000 + 700k issues with connections	50 GB	60 GB
~ 8,000,000 + 800k issues with connections	70 GB	90 GB

Performance tuning

On large installations of Assets, there are some options you can tweak to increase performance.

Garbage collection

To decrease the pause time we recommend that you switch the garbage collection (GC) algorithm to G1 from the default. You can configure it by adding the following JVM argument to your Jira setenv script.

-XX:+UseG1GC

Assets parallelism

Based on your environment, other options to tune the G1 may be required. Check out the information from Oracle (http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html) and tune your JVM based on your requirements.

Assets executes tasks in parallel (e.g. reindex, imports). On a large instance, you can increase the number of threads that perform the tasks. You can see this here: Configuring global Jira settings. By default, the parallelism is configured to be equal to the amount of cores available to the JVM.

Database pool

If you have increased the number of threads (Assets parallelism), it is recommended to check the database connection pool monitor and determine if an increased connection pool is required as well.

Jira shutdown

On Jira shutdown Assets persists the index on disk for faster startup. In large instances, the index file fails to be saved on disk in time before the force shutdown command is sent. This will cause Assets to do a database reindex on each startup. To prevent this change, you need to change the timeout on force shutdown in the stop-jira script.

Change the value 20 (the unit is seconds) to a value that is more reasonable based on the amount of data in your installation. Below is a snippet from the standard Jira stop-jira.sh and it is the value 20 that should be changed at two places.

if [ -z "$JIRA_USER" ] || [ $(id -un) == "$JIRA_USER" ]; then
    echo executing as current user
  
    exec $PRGDIR/shutdown.sh 20 -force $@
  
elif [ $UID -ne 0 ]; then
  
    echo JIRA has been installed to run as $JIRA_USER so please sudo run this to enable switching to that user
    exit 1
  
else
  
    echo executing using dedicated user
    if [ -x "/sbin/runuser" ]; then
        sucmd="/sbin/runuser"
    else
        sucmd="su"
    fi
    $sucmd -m $JIRA_USER -c "$PRGDIR/shutdown.sh 20 -force $@"
  
fi

Tomcat considerations

If you have configured your heap with the CATALINA_OPTS in setenv, make sure that the JVM configuration (JVM_MAXIMUM_MEMORY) is not the same value as the max heap configured in CATALINA_OPTS.

Importing large number of objects

If you are using Assets to accommodate millions of objects and plan to use importers heavily, (e.g, with the Asset Discovery product), then we recommend that you move to Data Center version if you're not already using it. This will offer you the possibility to isolate the importers to only one import node with the other nodes being the user nodes. With one import node, the import process will have less impact on user interaction . It will also be more robust since any failing import or any over consumption of memory will only affect the import node and not any of your user nodes.

It is difficult for us to set any exact object size or import size recommendation since it's about the data stored on your objects, as well as how often the imports occur. But in general, when reaching millions of objects or memory usage over 32 Gb or if you don't ever want to impact any user interaction, then you should consider using the Data Center version of Assets.

During imports and re-index with Data Center, we need to send messages to other nodes to update the index. This is done through provided Atlassian functionality and the clustermessage table is the DB table where all nodes push and pull. The problem we have seen is that Atlassian have a retention period of 30 days for this table. We think this is a bit too much and recommend that you should remove all Assets related data rows which are older than 24 hours with your own retention scripts.

Next steps

Head on right into Administering Assets.

Jira Service Management Support

Products

Jira Software