Sunday, January 23, 2022

Sitecore Cleanup Monitor - Proactively keeping an eye on your Event Queue, History and Publish Queue tables



There are several horror stories floating around the web about the Event Queue bringing Sitecore down to its knees.

Brian Pedersen

Andy Cohen

I have experienced trouble myself

The Last Straw 

There is a bug in pre 8.1 U3 releases (I am on 8.1 U2) that will cause the Event Queue table in the Core database to be flooded with timestamp data from your Sitecore servers in a scaled environment.

The issue was related to the property:changed event that was being added into the Event Queue. Every 10 seconds each Sitecore Instance would use the SetTimestampForLastProcessing method.

There was no need to inform other instances about the update in last processed stamp of local instance, and Sitecore Support provided me with a patch where they simply used the event disabler to fix the issue.

Here is a copy of the patch for download if you are having this problem:

After experiencing this and other problems in the past, I decided to take action.

Sitecore Cleanup Monitor Module 

The Event Queue was my initial focus, but per Sitecore's Performance Tuning Guide, in order to keep Sitecore running optimally, we need to keep the Event Queue, History and Publish Queue tables below 1000 rows: The reason behind this is due to SQL deadlocking:

With all this being said, I decided to put together a module that would keep an eye on these key tables.

The module consists of 3 agents that will monitor the Event Queue, Publish Queue and History tables to ensure that they don't exceed a set threshold.

Why would you use it?

In many cases, Sitecore's default cleanup agents just aren't efficient enough in cleaning up these key Sitecore tables.

This module allows you to be proactive instead of reactive, so that you don't have to log into your SQL instance to manually run queries to clean up your tables, usually after the $#!,$h has hit the fan.

How does it work? 

When due, the agent will check the row count of the target table in each database (core, master and web), and if the count is above the set threshold, it will remove the oldest rows, bringing the row count down to the threshold. It won't do anything to tables with row counts that are below the threshold.

You can set how often you want each agent to run, and what you want your threshold / table row count to be. You also don't need to use all three agents. If you only want to monitor the Event Queue for example, simply comment or remove the other agents from the module's config file.

You can monitor it's activity be examining your Sitecore logs. Here is a snapshot example:

Installation and Configuration

Documentation, full source code and package download is available from my GitHub repository:

The module is available on the Sitecore Marketplace:


Andy said...

We had a similar issue with Sitecore 8.1 Update 3 site

CPU and network traffic went through the roof and it only stopped when I truncated the 3 tables. But they didn't have huge amount of rows in beforehand.

Sitecore support sent us link to this

Which fixes a similar problem which affects 8.1 update 2 and 3, and is fixed in 8.2 initial release.

In case this helps anyone.

Martin English said...

Appreciate the comment Andy. Good to know.

Kamruz Jaman said...

A couple of new admin pages where added in 8.1 u2 for Event and Publish queues. This will give you a summary of the count as well as allow you to cleanup the tables:

Unknown said...

Thanks for the comment Kamruz!

With the module in place, hopefully you won't ever need to do event and publish queue maintenance using the admin pages :)

Hope you are keeping well man!

Post a Comment