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.
There is also another table ASConfigurationPropertiesTable which contains configuration parameters purging-stored procedure.
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.
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:
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.
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