gpt4 book ai didi

ruby-on-rails - ActiveRecord 批量数据,内存永远增长

转载 作者:行者123 更新时间:2023-12-01 05:36:06 24 4
gpt4 key购买 nike

我正在使用 ActiveRecord 将一些数据从一个数据库中的表批量迁移到另一个数据库中的另一个表。大约 400 万行。

我正在使用 find_each 批量获取。然后我对获取的每条记录进行一些逻辑处理,并将其写入不同的数据库。我尝试过直接一一写入,并使用不错的 activerecord-import gem 进行批量写入。

但是,无论哪种情况,在导出/导入的整个生命周期中,我的 ruby​​ 进程内存使用量都在增长。我认为使用 find_each,我得到了 1000 个批次,一次应该只有 1000 个在内存中......但不,我获取的每条记录似乎都在永远消耗内存,直到过程结束。

有任何想法吗? ActiveRecord 是否在某处缓存了一些我可以关闭的内容?

2012 年 1 月 17 日更新

我想我会放弃这个。我试过了:
* 确保所有内容都包含在 ActiveRecord::Base.uncached do
* 添加 ActiveRecord::IdentityMap.enabled = false (我认为应该关闭当前线程的身份映射,尽管它没有明确记录,而且我认为身份映射在当前 Rails 中无论如何都没有默认开启)

这些似乎都没有太大影响,内存仍在泄漏。

然后我添加了一个周期性的显式:

  • GC.start

  • 这似乎减慢了内存泄漏的速度,但内存泄漏仍然发生(最终耗尽所有内存和轰炸)。

    所以我想我要放弃了,并决定目前不可能使用 AR 从一个数据库中读取数百万行并将它们插入到另一个数据库中。也许正在使用的特定于 MySQL 的代码中存在内存泄漏(这是我的数据库),或者在 AR 中的其他地方,或者谁知道。

    最佳答案

    我建议将每个工作单元排队到 Resque队列 。我发现 ruby​​ 在迭代像这样的大型数组时有一些怪癖。

    让一个主线程按 ID 将工作排队,然后让多个 resque 工作人员点击该队列以完成工作。

    我已经在大约 30 万条记录上使用了这种方法,所以它很可能会扩展到数百万条。

    关于ruby-on-rails - ActiveRecord 批量数据,内存永远增长,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8674047/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com