Hi everyone,
Thank you for your interest in this issue.
Jira Service Management 4.22 will include a new SLA configuration interface. This includes settings for SLA debug log events. As a Jira administrator, you can decide how you want the SLA debug log to be cleaned up. You can also select how often the events will be deleted from the database, and whether or not you want SLA logging to be enabled.
Kind regards,
Charlie Marriott
Jira Service Management, Data Center & Server
Problem Definition
In Jira Service Desk Server 3.4.1 an SLA Audit Log was introduced for troubleshooting SLAs. This audit log can grow to huge sizes in the database, so a cleanup job was introduced(https://jira.atlassian.com/browse/JSDSERVER-5266). This cleanup job helps to keep the size of the database tables smaller, but can still allow the audit log to grow to large sizes and the job itself can become very resource intensive and long running. This leads to a performance impact due to the SQL query used and a stability impact because the query can become long running(over 30 hours has been seen) and can block other database calls.
Suggested Solution
Provide a dark feature, or other configurable parameter, to completely disable the SLA Audit Log.
Why this is important
The tradeoff between the benefits of the SLA Audit Log and the impact it can create is something that may vary from instance to instance and should be configurable to best fit the use case for that instance.
This is important because admins should be given the choice of whether to use the audit log feature or not.
Workaround
The closest thing to a workaround is to set a configuration setting in the database to reduce the number of days before an audit event is cleaned up. The default is 30 days and this can allow the tables to get too large, slowing down the cleanup job. If we reduce this to 1 day the tables will be kept much smaller and because they are smaller the cleanup job is able to complete much more quickly.
The database property is:
sd.sla.audit.log.cleanup.days
Run the SQL query to determine the ID of the property in the database:
SELECT * FROM propertyentry JOIN propertynumber ON propertyentry.ID=propertynumber.ID WHERE PROPERTY_KEY = "sd.sla.audit.log.cleanup.days";
Then to modify this parameter from 30 to 1:
UPDATE propertynumber SET propertyvalue=1 WHERE ID = <ID from above>;
Related tickets:
- is caused by
-
JSDSERVER-5719 com.atlassian.servicedesk.internal.sla.audit.SlaAuditLogCleanupJobScheduler job running for several hours
-
- Closed
-
-
-
- Closed
-
- is related to
-
JSDSERVER-6843 Provide Java API for SlaAuditLogCleanupJobScheduler
- Closed
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-5871] As a Service Desk Admin I would like to be able to disable the SLA Audit Log so that I can improve performance and stability of Jira Service Desk Server
We have been facing the same issue for quite some time now and it is particularly unpleasant as the Jira Oracle database is managed by a different support team and not the Jira Administrators. It would be nice to see this suggestion move to "under consideration". Thanks Brian. Kind regards, Alessandro
Thanks for creating this request Brian. As discussed in our support ticket, this functionality is very critical for us to have as we have seen that the SLA Audit log tables can easily grow more than 190,000+ rows just for a small SLA change. And so, the chances of impact to the instance stability is very high when few more SLA changes are done (even with the workaround in place). It would be great if this gets prioritized and implemented as soon as possible.
Thanks,
Kesava.
That will be nice small feature-bug!