【问题标题】:Out of memory when creating a lot of objects C#创建大量对象时内存不足C#
【发布时间】:2011-02-13 05:32:02
【问题描述】:

我在我的应用程序中处理 100 万条记录,这些记录是从 MySQL 数据库中检索的。为此,我使用 Linq 获取记录并使用 .Skip() 和 .Take() 一次处理 250 条记录。对于每条检索到的记录,我需要创建 0 到 4 个项目,然后将它们添加到数据库中。因此,必须创建的平均项目总数约为 200 万。

IQueryable<Object> objectCollection = dataContext.Repository<Object>();
int amountToSkip = 0;
IList<Object> objects = objectCollection.Skip(amountToSkip).Take(250).ToList();
while (objects.Count != 0)
        {
            using (dataContext = new LinqToSqlContext(new DataContext()))
            {
                foreach (Object objectRecord in objects)
                {
                    // Create 0 - 4 Random Items
                    for (int i = 0; i < Random.Next(0, 4); i++)
                    {
                        Item item = new Item();
                        item.Id = Guid.NewGuid();
                        item.Object = objectRecord.Id;
                        item.Created = DateTime.Now;
                        item.Changed = DateTime.Now;
                        dataContext.InsertOnSubmit(item);
                    }
                }
                dataContext.SubmitChanges();
            }
            amountToSkip += 250;
            objects = objectCollection.Skip(amountToSkip).Take(250).ToList();
        }

现在在创建项目时出现问题。运行应用程序时(甚至不使用 dataContext),内存会持续增加。就好像这些物品永远不会被处理掉。有没有人注意到我做错了什么?

提前致谢!

【问题讨论】:

  • 你如何初始化你的 objectCollection ?
  • IQueryable objectCollection = dataContext.Repository();
  • 为什么要批量处理 250 个而不是只迭代 objectCollection?
  • 实际上,他的拉动方法很好。只是迭代还涉及以块的形式提取数据以及如何分页取决于 Linq 实现。此外,您还获得了每次运行必须准确更新 250 个项目而不是任意数量的好处,并依靠框架正确批处理这些内容。
  • 我会得到一个 Sql Timeout 异常,从我正在使用的数据库中获取 100 万条记录需要很长时间。

标签: c# linq-to-sql memory object out-of-memory


【解决方案1】:

好的,我刚刚与我的一位同事讨论了这种情况,我们得出了以下可行的解决方案!

int amountToSkip = 0;
var finished = false;
while (!finished)
{
      using (var dataContext = new LinqToSqlContext(new DataContext()))
      {
           var objects = dataContext.Repository<Object>().Skip(amountToSkip).Take(250).ToList();
           if (objects.Count == 0)
                finished = true;
           else
           {
                foreach (Object object in objects)
                {
                    // Create 0 - 4 Random Items
                    for (int i = 0; i < Random.Next(0, 4); i++)
                    {
                        Item item = new Item();
                        item.Id = Guid.NewGuid();
                        item.Object = object.Id;
                        item.Created = DateTime.Now;
                        item.Changed = DateTime.Now;
                        dataContext.InsertOnSubmit(item);
                     }
                 }
                 dataContext.SubmitChanges();
            }
            // Cumulate amountToSkip with processAmount so we don't go over the same Items again
            amountToSkip += processAmount;
        }
}

通过这个实现,我们每次都处理 Skip() 和 Take() 缓存,因此不会泄漏内存!

【讨论】:

    【解决方案2】:

    啊,好老的InsertOnSubmit 内存泄漏。在尝试使用 LINQ to SQL 从大型 CVS 文件中加载数据时,我曾多次遇到过这种情况并撞到了墙角。问题是即使在调用SubmitChanges 之后,DataContext 仍会继续跟踪使用InsertOnSubmit 添加的所有对象。解决方法是SubmitChanges在一定数量的对象之后,再为下一批创建一个新的DataContext。当旧的DataContext 被垃圾回收时,所有被它跟踪的插入对象(并且您不再需要)也会被回收。

    “但是等等!”你说,“创建和处理许多 DataContext 将产生巨大的开销!”。好吧,如果您创建单个数据库连接并将其传递给每个 DataContext 构造函数,则不会。这样,始终保持与数据库的单个连接,DataContext 对象是一个轻量级对象,代表一个小型工作单元,完成后应丢弃(在您的示例中,提交一定数量的记录) .

    【讨论】:

    • Ehh 我在我的问题中说过,即使我不使用 DataContext 我也会得到这个泄漏,所以它没有绑定到 InsertOnSubmit 或 SubmitChanges (我已经测试过)并且使用 DataContext 是最佳实践在使用块中。 DataContextes 是轻量级的,需要大量重新创建(请参阅:stackoverflow.com/questions/123057/…)。我已经尝试过使用 1 个 DataContext 来完成所有事务,结果更糟。
    • 您在重复我所说的 - 为每个小型工作单元使用一个新的 DataContext(当然,在 using 语句中)。在没有DataContext 的情况下,您究竟是如何测试您的示例的?你从哪里得到objects 集合?
    • 对不起,我的意思是没有 InsertOnSubmit 和 SubmitChanges 调用;] 我的错。起初我还认为 InsertOnSubmit 和 SubmitChanges 是问题所在,在修复此问题并进行第二次运行后,我仍然遇到了泄漏。泄漏是因为 Skip 和 Take 对所有检索到的项目进行了缓存,并且在运行时从不自动处理它。所以最终我在一个 chached 列表中有 200 万个项目。
    • 是的,这就是我在回答中描述的确切问题。顺便说一句,在我的情况下,即使在解决了内存泄漏之后,它的性能仍然不够,所以我用 C# 编写了一个 CLR 存储过程,它的运行速度提高了大约 200 倍(加载 730 万条记录时需要 3 分钟而不是 10 小时)。
    • 哇,好吧,听起来棒极了 ^^ 我已经解决了记忆问题,但我必须同意你的观点,性能并不是真正值得欢呼的东西。很好,您可以通过编写存储过程来解决这个问题。
    【解决方案3】:

    我最好的猜测是 IQueryable 会导致内存泄漏。 也许 MySQL 没有适当的 Take/Skip 方法实现,它正在内存中进行分页?发生了奇怪的事情,但你的循环看起来很好。所有引用都应该超出范围并被垃圾收集..

    【讨论】:

      【解决方案4】:

      是的。

      所以在循环结束时,您将尝试在列表中包含 200 万个项目,不是吗?在我看来,答案是微不足道的:存储更少的项目或获得更多的内存。

      -- 编辑:

      我可能读错了,我可能需要编译和测试它,但我现在不能这样做。我将把它留在这里,但我可能是错的,我没有仔细审查它以做出明确的决定,但答案可能证明有用,也可能没有用。 (从downvote来看,我猜不是:P)

      【讨论】:

      • 不,他有一个包含 200 万个条目的数据库,一次取 250 个条目,然后将 4 个新的子条目添加到数据库中。在内存中没有任何类型的列表..阅读问题..
      • @Tigraine 我认为是skip 搞砸了他。无论如何,这是我的猜测。
      • list objectCollection 中的缓存是瓶颈。它不会自动处理
      【解决方案5】:

      您是否尝试过像这样在循环外声明项目:

      IQueryable<Object> objectCollection = dataContext.Repository<Object>();
      int amountToSkip = 0;
      IList<Object> objects = objectCollection.Skip(amountToSkip).Take(250).ToList();
      Item item = null;
      while (objects.Count != 0)
              {
                  using (dataContext = new LinqToSqlContext(new DataContext()))
                  {
                      foreach (Object objectRecord in objects)
                      {
                          // Create 0 - 4 Random Items
                          for (int i = 0; i < Random.Next(0, 4); i++)
                          {
                              item = new Item();
                              item.Id = Guid.NewGuid();
                              item.Object = objectRecord.Id;
                              item.Created = DateTime.Now;
                              item.Changed = DateTime.Now;
                              dataContext.InsertOnSubmit(item);
                          }
                      }
                      dataContext.SubmitChanges();
                  }
                  amountToSkip += 250;
                  objects = objectCollection.Skip(amountToSkip).Take(250).ToList();
              }
      

      【讨论】:

      • 试过了,没用>。
      猜你喜欢
      • 1970-01-01
      • 2011-05-18
      • 2017-03-15
      • 2012-10-26
      • 1970-01-01
      • 1970-01-01
      • 2013-12-05
      • 2012-02-21
      • 1970-01-01
      相关资源
      最近更新 更多