绕过 UploadCreator 进行导入

支持
1

我正在使用批量导入工具向 Discourse 导入数据。对于主题和帖子的导入效果非常好，但目前瓶颈在于文件。我们有大约 50,000 名用户带有头像，虽然用户数据导入数据库只需几秒钟，但头像导入却耗时数小时。目前每秒仅处理约一次上传。

有什么方法可以加快这一过程吗？我不确定哪个环节最慢。如果找不到头像文件（即 photo_filename 不存在），执行速度非常快；但我在尝试深入探究最终由该导入代码调用的 UploadCreator 类时感到有些困惑。

我们还有超过 600,000 个附件，因此我非常担心使用相同的 create_upload 调用导入这些附件会需要多长时间。

        upload = create_upload(u.id, photo_filename, File.basename(photo_filename))
        if upload.persisted?
          u.import_mode = false
          u.create_user_avatar
          u.import_mode = true
          u.user_avatar.update(custom_upload_id: upload.id)
          u.update(uploaded_avatar_id: upload.id)
        else
          puts "Error: Upload did not persist for #{u.username} #{photo_real_filename}!"
        end
2 个赞
2

@neounix 有什么想法吗？毕竟你之前运行过大型批量导入工具。

多亏了批量导入工具，我们将 2600 万篇帖子的处理时间从一周缩短到了大约两小时。现在的痛点是附件，处理它们需要好几天时间。

3

嘿 @TheDarkWizard，

我们并没有使用 Discourse 的脚本来迁移实际文件。

我们使用了常规的文件传输工具，例如 tar、gzip、sftp、rsync 等。

老实说，我们确实使用了 Discourse 提供的各种迁移脚本，但最终我们迁移过程中所用代码的一半以上都是我们自己编写的。这是因为我们花了数月时间编写 gsub() 代码，用于清理（审核）过去几十年间发布的“代码”帖子。这些帖子由多年发布大量代码的版主审核，而每个人都希望自己的代码完美无缺，没有任何语法问题！

我们认为 Discourse 提供的脚本是一个极佳的起点，并在此基础上广泛使用；同时，我们也基于这些脚本编写了大量自有代码。

希望这能帮到你。

4

抱歉，也许我的问题被忽略了。我们不需要关于如何将文件移动到执行导入的服务器环境的说明。我们有一个由 @Ghan 编写的批量导入脚本，我们正在尝试弄清楚如何加快附件的导入速度。从普通导入切换到批量导入后，帖子导入时间从一周缩短到了大约两小时。我希望有人能指点一下如何正确处理附件。

5

如果我看错了您的问题，导致回复没有帮助，深感抱歉。

无论如何，我相信您一定能搞定。这并非什么高深莫测的难题（毕竟只是软件）：slight_smile: 而且你们都很聪明。

祝您好运。很抱歉没能提供更多帮助。我们在 2020 年第二季度完成了迁移工作，如今（迁移任务）早已成为过去式。

1 个赞
6

没问题！

您的网站看起来很棒 :slight_smile:

1 个赞
7

我不认为存在类似的“银弹”。由于上传操作不依赖先前帖子的处理结果，你可以设计运行多个进程（例如每个进程处理不同的日期范围），从而将处理时间缩短为原来的 CPU 核心数的倒数倍（前提是数据库和文件系统不是瓶颈）。

8

看起来，在处理帖子的附件时，会启动许多 Sidekiq 作业来处理这些帖子的其他相关处理。因此，即使只有一个进程在处理附件导入，也会缓慢地将服务器的负载平均值推高至 40 以上，尽管服务器拥有 8 个核心。（我已增加 Sidekiq 工作进程的数量以应对负载。）

我或许可以在导入完成前停止 Unicorn 服务，但这只是将负载推迟到稍后时间。看起来无论如何都必须进行这些处理。

9

这是一个基本真理。