When executing the task, in middle of nothing the log message says Aggregating records in ‘Counter’ table… The take does not perform any actions as there are no logging after this message? This message repeats for almost 5-6 times. Does any body here knows about this? What is actually does and why it is required?
Just as the message says, it is aggregating records in Counter table 
Statistical records (counters for succeeded/failed jobs etc.) are saved into Counter table. As the number of records grows with each performed job, it would eventually increase database size and affect queries’ performance.
To avoid this, the records are occasionally aggregated into AggregatedCounter table, so queries can use pre-calculated values instead of computing them across a lot of rows every single time.
Hey,
Thanks for the reply!
We are experiencing some unique situations where current recurring job executes certain instructions (two functions out of three) and then Hangfire kind of start cleaning up the database and aggregate the records and pause the current execution. At some point, after cleaning done it resume the job and complete it. For the record, the cleaning process is taking almost an hour. We are using Azure SQL Database (if it matters). Here are few logs:
2017-08-22 05:22:44.1898 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 05:27:44.2369 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 05:32:44.2848 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 05:37:44.3425 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 05:37:45.4988 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘AggregatedCounter’ table…
2017-08-22 05:37:45.5930 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘Job’ table…
2017-08-22 05:37:45.7175 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘List’ table…
2017-08-22 05:37:45.8582 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘Set’ table…
2017-08-22 05:37:45.9676 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘Hash’ table…
2017-08-22 05:42:44.3877 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 05:47:44.8303 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 05:52:44.8799 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 05:57:44.9252 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 06:02:44.9823 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 06:07:45.0564 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 06:07:46.1972 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘AggregatedCounter’ table…
2017-08-22 06:07:46.2909 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘Job’ table…
2017-08-22 06:07:46.4003 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘List’ table…
2017-08-22 06:07:46.5096 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘Set’ table…
2017-08-22 06:07:46.6190 Hangfire.SqlServer.ExpirationManager Removing outdated records from the ‘Hash’ table…
2017-08-22 06:12:45.1194 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
2017-08-22 06:17:45.2493 Hangfire.SqlServer.CountersAggregator Aggregating records in ‘Counter’ table…
By any chance can you tell me why the job is getting paused for no reasons and Hangfire internal cleaning job take over?
Hangfire actually cannot pause (and then resume) a job, and there’s also no correlation between the running job and cleanup process. They’re running in different threads and don’t interact with each other.
From your log I can see that CountersAggregator runs every 5 minutes, and ExpirationManager run every 30 minutes. This is perfectly fine, and matches default run intervals for Sql Server job storage provider.
So it is unlikely there’s something wrong with that. I’d rather suggest to take a closer look at the job itself and/or Azure server configuration/logs.