Question

我正在创建一个Web应用程序，该应用程序将在世界上的每个城镇，地区和国家/地区拥有一个数据库，以允许将其他对象映射到某个位置。作为应用程序的一部分，我希望用户能够搜索一个地方，为此我使用弹性搜索来索引所有内容。要与Elastic Search进行交互，我正在使用NEST。

我有以下代码：

public void RefreshLocationIndex()
{
    int count;
    using (var dbContext = new ModelContext())
    {
        IndexMany(dbContext.Countries, "Country");
    }

    using (var dbContext = new ModelContext())
    {
        count = dbContext.Regions.AsNoTracking().Count();
    }
    for (var i = 0; i <= count; i += BATCH_SIZE)
    {
        using (var innerContext = new ModelContext())
        {
            IndexMany(innerContext.Regions.OrderBy(t => t.RegionID).Skip(i).Take(BATCH_SIZE),
                    "Region");
        }
    }


    using (var dbContext = new ModelContext())
    {
        count = dbContext.Towns.AsNoTracking().Count();
    }
    for (var i = 0; i <= count; i += BATCH_SIZE)
    {
        using (var innerContext = new ModelContext())
        {
            IndexMany(innerContext.Towns.AsNoTracking().OrderBy(t => t.TownID).Skip(i).Take(BATCH_SIZE), "Town");
        }
    }
}

public void IndexMany(IQueryable<Entity> objects, string type)
{
    var itemCount = objects.Count();
    if (itemCount > 0)
    {
        SearchClient.Instance.IndexManyAsync(objects, SearchClient.Instance.Settings.DefaultIndex, type);
    }
}

正如您所看到的，我将非常大的表分成批处理，以避免加载到内存中。问题是这不起作用，我不断出现内存异常。我认为为每个批处理使用新的上下文可以避免这个问题，因为当处理上下文时它会处理它已经加载的所有实体，但事实似乎并非如此。有什么想法吗？

正如数据量的指示：国家/地区表有193条记录 Region表有80,523条记录城镇表有2,743,469条记录

Answer 1

我不了解ElasticSearch和NEST，但根据their source code，IndexManyAsync每次调用时都会创建一个新任务。

因此，如果执行任务的速度比实体框架实现的要慢得多，那么您将执行大量正在执行（或等待执行）的任务，每个任务在内存中加载BATCH_SIZE个实体作为那些实体作为参数传递：所以基本上所有实体都将同时加载到内存中。

我不知道如何解决这个问题，因为我不了解NEST或ElasticSearch关于批处理索引的最佳做法，但这里是您的问题的解释。

Answer 2

如果对象没有实时引用，则该对象仅适用于垃圾回收很明显，您已经处理了上下文，但您可能仍然引用了不那么明显的实体。在SearchClient.Instance.IndexManyAsync（objects，...）中的某个地方，你仍然必须持有对象的引用。

在此示例中，处理dbContext时不会回收内存。

List<Region> regions;
using (var dbContext = new ModelContext())
{
    regions = dbContext.Regions.ToList();  
}  //dbContext is disposed, but memory is not reclaimed.
regions = null; //memory is reclaimed

Answer 3

对于AsNoTracking()和dbContext.Countries，您不会错过innerContext.Regions吗？当您使用ChangeTracker时，它将在内存中保留引用，直到查询的实体引用消失为止。

在你的情况下，它可能会增加你的记忆，因为由于ChangeTracker，实际上没有处理多个上下文（主要是Regions的innerContext）。

尝试对所有查询使用AsNoTracking并再次检查内存占用。

仍然在你的情况下，通过不使用AsNoTracking，所有被跟踪的实体都被传递给你的SearchClient方法，然后你不知道这些引用何时会被实际发布。

如果问题与EF本身无关，请尝试使用ANTS Memory Profiler之类的工具查找内存泄漏，这非常有用。

实体框架将数千个对象传输到Elastic Search

3 个答案: