AppFabric Purge

Damir Dobric Posts

Next talks:

 

    

Follow me on Twitter: #ddobric



 

 

Archives

AppFabric Server has a feature called “automatic purge”. The purpose of this feature is to automatically and regularly check the growth of an AppFabric monitoring database on disk and reduce its disk footprint when needed. This ensures that a monitoring database does not grow uncontrollably and consume too much space on disk.

The automatic purge operations are driven by a SQL Server stored procedure that AppFabric installs when it initializes the ApplicationServerMonitoring database during setup. There is one table in the AppFabric database called ASJobsTable.
This table contains the list of several jobs which are scheduled by AppFabric Server. Here you can see if the purge operation has been started at all. The picture below shows that purge operation has been successfully  completed.

image

There is also another table ASConfigurationPropertiesTable which contains configuration parameters purging-stored procedure.

image

Each value in this table defines the behavior of purge operation. Following table (copied from MSDN site) describes all of them.

Column Name Column Type Default Description

ArchiveServer

Nvarchar(128)

NULL

The name of a SQL server that is hosting a monitoring database.  This database will be used for archiving monitoring data.

ArchiveDatabase

Nvarchar(128)

NULL

The name of a monitoring database.  This database will be used for archiving monitoring data.

APEnabled

bit

1

Enables or disabled automatic purging of monitoring data.  When set to 1, the database will automatically purge data based on the other auto-purge configuration properties.

APThreshold

int

1500

This property is only read if APEnabled is set to 1.  When the size of the database exceeds this threshold (approximated in megabytes), the automatic purge is engaged and monitoring data will be deleted in accordance with the APTrimPercentage configuration property.

APMaxEventAge

float

NULL

This property is only read if APEnabled is set to 1.  Any monitoring event in the database that is older than this property’s value (in days) will be deleted.

APTrimPercentage

int

10

This property is only read if APEnabled is set to 1.  When the APThreshold purge mechanism engages, approximately APTrimPercantage percent of the oldest monitoring data will be deleted, making room for new data. The default value of this is 10 percent.

Why the Purge does not work?

The problem with this great feature is that purge removes events from monitoring tables (ASWcfEventsTable, ASWfEventsTable), but it doesn’t rebuild indexes.
Unfortunately this is required, because indexes can take lot of space. To illustrate this, take a look on a real data at the picture below. The picture below shows that the largest table is ASWcfEventsTables.
This is as expected, because the system consists majorly of WCF services. The WCF events take 13.5 GB in the table, after the purge has been successfully completed. 
I noticed that last purge-operation has been successfully finished one hour before I created the report shown on the picture.

image

To workaround this issue you will have to manually rebuild indexes of largest tables. Following picture shows how to do this within SQL Management Studio:

image

After you have selected “Rebuild All” one dialog will appear (not shown here). Just confirm with OK and rebuild process will be started. In a case of ASWcfEventsTable (13.5 GB), this has taken 2-3 minutes at my server.
The result looks now like shown at the next picture.

image

You will notice that the ASWcfEventsTable is no more the critical one. It  takes now just about 10MB. In my case I have rebuild indexes for ASWfEventsTable too.

Recap:

If the purge does not shrink size of monitoring tables as you would expect, rebuild indexes of ASWcfEventsTable and ASWfEventsTable manually.

 

Hope this helps.

Damir


Posted Dec 29 2010, 03:40 PM by Damir Dobric
Filed under:

Comments

Frank Szendzielarz wrote re: AppFabric Purge
on 02-27-2013 10:20

Thanks!! This really helped.

developers.de is a .Net Community Blog powered by daenet GmbH.