Steps to determine the cause of a cache flush - Support and Troubleshooting

Steps to determine the cause of a cache flush Issue This article walks you through the process to determine the cause of the cache flush.

Release All Currently Supported Versions.

Cause Below are a few causes that will lead to the cache to be rebuilt:

1) Adding or updating system properties

2) Adding or updating dictionary entries

3) Committing update sets

4) Adding or updating translations

5) Activating a plugin

6) User triggered cache flush by accessing /cache.do

Resolution Below are the different ways to determine if a cache flush was triggered that lead to poor performance of the instance.

1) ServiceNow Performance Dashboard:

The ServiceNow Performance graphs will provide data upto 30 days and you have an option to view if any event was triggered within that time frame based on each of the nodes available.

There is an option to toggle the Diagnostic Events to on and off. Enabling this will provide you all the events that were triggered as follows. In the below picture, there was a plugin that was activated that lead to the cache flush and you can see the spikes in response time once the cache was flushed.

Below is the link to the documentation:

https://docs.servicenow.com/csh?topicname=c_PerformanceMetrics.html&version=latest

There are diagnostic events that are triggered by the platform when there are certain changes noticed in the instance. There will be entries made in 'diagnostic_event' table and in the log files. Data in the 'diagnostic_event' table is maintained for about 720 hours or 30 days.

When the cache is flushed, the entry in 'diagnostic_event' table will have name = cache.flush with detail ='Flushing entire system cache' is inserted.

Below is the snippet from the logs:

2019-07-24 09:14:00 (024) worker.0 worker.0 txid=28c8391edbb6 WARNING *** WARNING *** Starting cache flush 2019-07-24 09:14:00 (025) worker.0 worker.0 txid=28c8391edbb6 [DiagnosticEvent] c2c8b91edbb67340ac639ee5db96190d cache.flush Flushing entire system cache Warning Information 2019-07-24 16:14:00 app129019.sjc103.service-now.com:binghamtontest003 2019-07-24 09:14:00 (031) worker.0 worker.0 txid=28c8391edbb6 Flushing cache 2019-07-24 09:14:01 (244) worker.0 worker.0 txid=28c8391edbb6 Loading properties from DB 2019-07-24 09:14:01 (331) worker.0 worker.0 txid=28c8391edbb6 WARNING *** WARNING *** Cache flush complete 2019-07-24 09:14:01 (332) worker.0 worker.0 txid=28c8391edbb6 Loading properties from DB 2019-07-24 09:14:01 (409) worker.0 worker.0 txid=28c8391edbb6 GlideSession SuppressTextIndexWhenSessionWorkflowOff is set to previous value true for plugin x_70091_first_sugg 2019-07-24 09:14:01 (490) worker.0 worker.0 txid=28c8391edbb6 [DiagnosticEvent] 5ec8b91edbb67340ac639ee5db961910 plugin.activation Plugin ID: First Suggestion Box Information Closed 2019-07-24 16:14:01 app129019.sjc103.service-now.com:binghamtontest003

2) Cache Flush details:

When the cache is flushed, there is an entry made in the 'sys_cache_flush' table with catalog set to 'syscache_everything'. Keep in mind that this table is cleaned up every hour by the Table Cleaner job, so you will have only the past 60 minutes of data available.

3) Log files:

Starting London release, there is a parameter 'Cache build time' that is captured at the end of every user transaction as follows. This will give you an idea where the time was spent either on the query (which will show as high 'SQL time') and if it is due to the cache being rebuild (this will result in high 'Cache build time').

2019-07-24 09:51:06 (716) Default-thread-11 3D304296DBF67340AC639EE5DB961908 txid=5931461adbf6 EXCESSIVE *** End #283140 /sys_email.do, user: abc, total time: 0:00:17.444, processing time: 0:00:17.444, SQL time: 0:00:05.287 (count: 10,579), ACL time: 0:00:00.030, UI Action time: 0:00:00.016, Cache build time: 0:00:15.677, source: 128.226.31.110 null