排队和处理后台作业时发生内存不足异常

时间:2016-11-01 17:52:49

标签: hangfire stackify

当使用Hangfire排队和处理后台作业时,我能够导致可重现的内存不足异常。

作业是简单的Console.WriteLine调用,所以我不希望堆内存增加它的工作方式。

我的配置是否错误,还是我应该考虑提交问题?

结果(VMMap

使用Redis作为Jobs的后备存储:

  • 开始时,总堆= 29,088K;
  • 经过5,000个工作岗位,938,672K;
  • 6,000个工作,1,056,004K;
  • 7,000个工作,1,219,296K;
  • 8,000个作业,堆值不存在;
  • 在100多个作业中,iisexpress.exe实例崩溃。

使用SQL存储,限制要高得多〜= 15,000个作业。

设置

  • 空ASP.NET项目;
  • 安装IIS主机和Hangfire的Owin包;
  • 启动类和控制器。

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Hangfire.Core" version="1.6.6" targetFramework="net452" />
  <package id="Hangfire.Pro" version="1.4.7" targetFramework="net452" />
  <package id="Hangfire.Pro.PerformanceCounters" version="1.4.7" targetFramework="net452" />
  <package id="Hangfire.Pro.Redis" version="2.0.2" targetFramework="net452" />
  <package id="Hangfire.SqlServer" version="1.6.6" targetFramework="net452" />
  <package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net452" />
  <package id="Microsoft.AspNet.WebApi.Core" version="5.2.3" targetFramework="net452" />
  <package id="Microsoft.AspNet.WebApi.Owin" version="5.2.3" targetFramework="net452" />
  <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.0" targetFramework="net452" />
  <package id="Microsoft.Net.Compilers" version="1.0.0" targetFramework="net452" developmentDependency="true" />
  <package id="Microsoft.Owin" version="3.0.1" targetFramework="net452" />
  <package id="Microsoft.Owin.Host.SystemWeb" version="3.0.1" targetFramework="net452" />
  <package id="Newtonsoft.Json" version="9.0.1" targetFramework="net452" />
  <package id="Owin" version="1.0" targetFramework="net452" />
  <package id="StackExchange.Redis" version="1.1.606" targetFramework="net452" />
</packages>

控制器

public class DefaultController : ApiController
{
    static int _;

    [HttpPost]
    public void Post(int count = 1000)
    {
        for (var i = 0; i < count; ++i)
        {
            BackgroundJob.Enqueue(() => Console.WriteLine(_));

            ++_;
        }
    }
}

启动

static class AppSettings
{
    internal static bool   HangfireUseRedis => true;
    internal static int    RedisDatabase    => 0;
    internal static string RedisConnection  => "localhost:6379";

    internal static string SqlConnection    => "Data Source=(localdb)\\v11.0;Initial Catalog=Hangfire";
}

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        var config = new HttpConfiguration();

        config.Routes.MapHttpRoute(
            name: "Default",
            routeTemplate: "{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );

        if (AppSettings.HangfireUseRedis)
        {
            var redisOptions = new RedisStorageOptions
            {
                Database = AppSettings.RedisDatabase,
                Prefix   = "Foobar:"
            };

            GlobalConfiguration.Configuration.UseRedisStorage(AppSettings.RedisConnection, redisOptions);
        }
        else
        {
            GlobalConfiguration.Configuration.UseSqlServerStorage(AppSettings.SqlConnection);
        }

        JobHelper.SetSerializerSettings(new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.All });

        app.UseHangfireServer();
        app.UseHangfireDashboard();

        app.UseWebApi(config);
    }
}

2 个答案:

答案 0 :(得分:6)

收到您的迷你转储文件(1.2 GB)后,我能够获得有关您的流程堆的信息。他们中的大多数都没有包含任何有趣的内容,而且它们的大小相对较小,这里是最重要内容的摘录:

GC Heap Size:    Size: 0x9f7eb8 (10452664) bytes.
Jit code heap:   Size: 0x1000 (4096) bytes total, 0x905a4d00 (2421837056) bytes wasted.

正如我们所看到的,GC堆大小约为10 MB,因此.NET代码本身没有泄漏,因为它的大小相对较小。但是Jit代码堆看起来很奇怪,所以我决定看看该进程使用了​​哪些模块,并找到了Stackify Profiler的一个:

6b0d0000 6b23a000   StackifyProfiler_x86   (deferred)

PEB显示环境变量StackifyIsPrefix=1,它告诉我们使用了Stackify Prefix。 Profilers 可以修改仪器pupros的JIT代码,因此我决定安装Stackify Prefix以尝试重现该问题。

我创建了一个简单的MVC应用程序,修改了Home/Index操作以将10000个后台作业排入队列,并启用了分析器。完成此步骤后,我发现获取该页面需要很长时间 - 1.5分钟,并且分析器没有显示任何数据。太长了。所以我决定比较关闭探查器的时间 - 只用 5秒。这是一个巨大的差异,但我无法重现内存问题。

我已将作业数量减少到100,打开了分析器并意识到每次调用Redis都会被计算,有数百条记录可以调用Redis。存储所有这些可能会引入内存问题,但我不确切知道它们是如何存储在Stackify前缀中的。

Stackify Prefix Screenshot

我无法重现原始内存问题。但是,Stackify Prefix会通过增加其持续时间来显着影响执行。 您是否尝试过禁用Stackify Prefix探查器并重新运行测试?更新后的版本也可能会解决内存问题。

答案 1 :(得分:2)

我可以同意odinserj的上述评论,因为我写了Prefix profiler。

我们进行了一些设计更改,以帮助解决在Hangfire等库中运行的后台线程。问题是我们在每个线程的内存中保留了影子堆栈 - 在普通的Web应用程序中,我们在请求结束时刷新此堆栈。但是Hangfire旋转的线程将在app域的生命周期内存在。

你会发现在最新版本中,影响应该小得多,因为我们已经考虑了一些特定的hangfire方法,然后我们释放了一些阴影堆栈。