使用Hangfire,SQL Server日志文件增长了40GB

Question

我一直在使用MVC在IIS中运行开发的迟发型应用程序,它工作绝对没问题,直到我看到了我的SQL Server日志文件的大小,其增长高达40 GB一夜!

根据我们DBA的信息,有一个长时间运行的事务,有以下SQL语句(我有2个hangfire队列) -

(@queues1 nvarchar(4000),@queues2 nvarchar(4000),@timeout float)
delete top (1) from [HangFire].JobQueue with (readpast, updlock, rowlock)
output DELETED.Id, DELETED.JobId, DELETED.Queue
where (FetchedAt is null or FetchedAt < DATEADD(second, @timeout, GETUTCDATE()))
and Queue in (@queues1,@queues2)

在探索Hangfire库时,我发现它用于将作业出列,并执行一项非常简单的任务,不应该占用任何重要的时间.我找不到任何可能导致此错误的内容.事务与using语句正确使用,对象Disposed发生异常.

正如一些帖子中所建议的,我已经检查了我的数据库的恢复模式,并验证它很简单.

我已手动杀死挂起的事务以回收日志文件空间,但几小时后它再次出现.我一直在观察它.

这种行为可能是什么原因？以及如何预防？

这个问题似乎是间歇性的,并且在生产中部署可能具有极高的风险:(

Answer 1

从Hangfire 1.5.0开始，Hangfire.SqlServer实现将事务处理后台作业的整个过程包装起来。先前的实现使用了可见性超时，以防进程意外关闭而至少提供一次处理保证，而无需事务。

我为队列处理实现了一个新模型，因为对于新用户，尤其是刚安装了Hangfire并在调试会话中使用Hangfire的用户，他们存在很多困惑。有很多问题，例如“为什么我的工作仍处于处理状态？” 。我已经考虑到事务日志增长可能存在问题，但是我不知道即使使用简单恢复模型也可能发生这种情况（请查看此答案以了解原因）。

看起来应该有一个开关，基于事务（默认情况下）或基于隐形超时，使用哪种队列模型。但是此功能仅在1.6中可用，我尚不知道任何ETA。

当前，您可以使用Hangfire.SqlServer.MSMQ或任何其他非RDBMS队列实现（请参阅“ 扩展”页面）。用于Hangfire的单独数据库也可能会有所帮助，尤其是在您的应用程序更改大量数据的情况下。