4

在使用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);
    }
}
4

2 回答 2

9

收到您的小型转储文件 (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 前缀的环境变量。Profilers可能会修改用于检测目的的 JIT 代码，因此我决定安装 Stackify Prefix 以尝试重现该问题。

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

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

Stackify 前缀截图

我无法重现原始内存问题。但是，Stackify Prefix 确实通过增加其持续时间来显着影响执行。您是否尝试禁用 Stackify 前缀分析器并重新运行测试？更新的版本也可能会修复内存问题。

于 2016-11-03T10:01:34.227 回答
5

我同意 odinserj 的上述评论，因为我编写了前缀分析器。

我们进行了一些设计更改，以帮助考虑在 Hangfire 等库中运行的后台线程。问题是我们在每个线程的内存中保留影子堆栈——在普通的 Web 应用程序中，我们会在请求结束时刷新这个堆栈。但是 Hangfire 启动的线程将在应用程序域的生命周期内存在。

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

于 2017-02-02T15:46:01.710 回答