This article walks you through the process to determine the cause of the cache flush.
All Currently Supported Versions.
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 transalations
5) Activating a plugin
6) User triggered cache flush by accessing /cache.do
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:
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] <event><id>c2c8b91edbb67340ac639ee5db96190d</id><name>cache.flush</name><detail>Flushing entire system cache</detail><severity>Warning</severity><status>Information</status><reported_on>2019-07-24 16:14:00</reported_on><system_id>app129019.sjc103.service-now.com:binghamtontest003</system_id></event>
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] <event><id>5ec8b91edbb67340ac639ee5db961910</id><name>plugin.activation</name><detail>Plugin ID: First Suggestion Box</detail><severity>Information</severity><status>Closed</status><reported_on>2019-07-24 16:14:01</reported_on><system_id>app129019.sjc103.service-now.com:binghamtontest003</system_id></event>
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: 220.127.116.11 null
1) Table Cleaner:
2) Log File Downloader: