C# SQL Server日志文件随Hangfire增长了40GB

我已经使用运行在IIS中的MVC开发了一个Hangfire应用程序，它工作得非常好，直到我看到我的SQL Server日志文件的大小，它一夜之间增长了40 GB

根据我们DBA提供的信息，有一个长时间运行的事务，使用以下SQL语句（我有两个hangfire队列）——

（@queues1-nvarchar（4000），@queues2-nvarchar（4000），@timeout-float）
从[HangFire]中删除顶部（1）。作业队列具有（readpast、updlock、rowlock）
输出DELETED.Id，DELETED.JobId，DELETED.Queue
其中（FetchedAt为null或FetchedAt

在探索Hangfire库时，我发现它用于将作业排出来，并执行一项非常简单的任务，不需要花费任何时间。 我找不到任何可能导致此错误的内容。事务与

using

语句一起正确使用，对象在异常情况下被

处理

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

我已经手动终止了挂起的事务以回收日志文件空间，但几个小时后它又出现了。我一直在观察它

这种行为的原因是什么？如何预防

该问题似乎是间歇性的，在生产中部署可能具有极高的风险：（
从Hangfire 1.5.0开始，
Hangfire.SqlServer
实现将后台作业的整个处理过程包装为一个事务。以前的实现使用不可见性超时来提供至少一次处理保证，而不需要事务，以防进程意外关闭

我已经实现了一个队列处理的新模型，因为对于新用户来说有很多困惑，特别是那些刚刚安装了Hangfire并在调试会话中使用它的用户。有很多问题，比如“为什么我的作业仍处于处理状态？”。我曾考虑过事务日志增长可能会出现问题，但我不知道即使使用简单的恢复模型也会出现这种情况（请参阅了解原因）

看起来应该有一个开关，使用什么队列模型，基于事务（默认情况下）或基于不可见性超时。但该功能仅在1.6版本中可用，我还不知道任何ETA

目前，您可以使用或任何其他非RDBMS队列实现（请参见页面）.Hangfire的单独数据库也可能有帮助，尤其是当应用程序更改了大量数据时。
您是否为
SqlServerStorageOptions.QueuePollInterval
属性设置了自定义值？使用了什么值？@odinserj:没有。它应该使用默认的15秒间隔。您总共有多少工作人员？@odinserj-我在中国有20名工人total@odinserj-如果我错了，请纠正我，我观察到事务在作业执行之前保持打开状态。因此，对于需要数小时才能完成的长时间运行的作业，事务是打开的，并且它会不断增加日志大小。如果这是正确的，如何修复它。@odinserj.否w我知道关于hangfire的官方信息。我将在这个问题上做更多的工作，并尝试找出解决方案。我想到的一件事是，应用程序和hangfire DBs现在是一样的。可能是这导致了问题。我将再次尝试分离数据库进行测试。您的工具非常棒：）考虑使用MSMQ扩展，这将完全删除长时间运行的事务，并且由于在获取作业时阻塞调用而延迟最小。后台工作信息将保留在SQLServer中，但在这种情况下，队列将由MSMQ驱动。现在很顺利。尽管如此，为了获得最佳性能，最好使用msmq或redis等存储设备。
(@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)