您好，正如我在之前的帖子中所提到的，我正在对我的 Drupal → Discourse 迁移进行测试运行，以便在最终关闭旧站点以迁移生产数据（包含约 200 万个帖子）之前准备好所有解决方案。我了解到，在一个相当快速的 VPS 上，使用 3 个 vCPU 核心，导入过程需要很长时间，大约 48 小时。然后我可能还需要使用 rake 任务和/或 rails c 进行一些清理，而任何需要 rake posts:rebake 的操作大约还需要 20 小时。
我不太了解 Ruby 工具链的基本原理。但是，如果我增加 CPU 核心数量，是否会显著减少任何一个进程完成所需的时间？例如，bundle 命令或 rake 命令能否将其工作分配给可用的 CPU，或者额外的核心主要用于在多个用户访问网站时运行多个并发进程？
我有点离题了，但当我处理一个有相同数量帖子的论坛迁移时，我修改了导入脚本，使其只导入 1/100 或 1/1000 的主题和帖子。
这是查看导入是否可靠以及是否需要进行调整或调试的更快方法。
@Canapin 实际上非常感谢您提到这一点，我真的很想知道您是如何做到的。我一直想做同样的事情，但我放弃了这个想法，因为我假设部分导入会导致数据库不一致。所以我最终创建了一个骨架 Drupal 测试论坛来测试。但我更愿意测试生产数据库的副本。
我主要担心最终的生产迁移；我将不得不离线旧论坛，或者至少使其变为只读，而且最好的情况也需要至少 48 小时的停机时间，除非增加一倍的 CPU 核心可以使时间减半？
耗时长的恢复任务确实是多线程的。有一个需要注意的地方是，CPU数量翻倍几乎从来不会带来性能翻倍。
另一点是，通常rake posts:rebake的任务以及论坛本身用于恢复和优化内容的繁重工作可以在论坛在线时进行。这可能会减少您需要让论坛离线或只读的时间，并能提供一种体验稍差但可用的状态。
我的建议是：首先进行测试。执行迁移，看看需要多长时间，以及在没有所有rebake的情况下论坛看起来如何。如果时间足够，请将迁移结束时间安排在论坛流量较低的时段，这样您就可以获得4-10小时的迁移时间，而不会引起太多用户的抱怨。
太好了，谢谢你的确认，我也在考虑这个选项。
很遗憾，我没有写下来，而且我忘了……但如果你懂编程，那应该不难。
我可能调整了 BATCH_SIZE 和 offset 等值来改变循环，使其跳过帖子批次之类的……
我现在无法重试，因为我手头没有任何论坛可以导入，但我下次会做一个简单的教程，因为我认为它很有用。
我想提两点。\n\n- 是的，CPU很重要，所以只需获取一个更大的VPS并运行多个sidekiq实例进行重新烘焙和图像处理，这样会更快。\n- 当你的导入完全完成后，最好进行一次备份/恢复，这将提高你的数据库性能。\n\n这两点结合起来：为导入获取一个大的VPS，完成后将其移动到一个较小的生产VPS（使用备份和恢复）。\n\n通常，导入后不需要重新烘焙帖子。
非常感谢 Richard 的回复。那么是这些中的哪一个（或哪些）？
UNICORN_WORKERSUNICORN_SIDEKIQSDISCOURSE_SIDEKIQ_WORKERS真有趣，我以前没见过这个建议。这会减少碎片化还是什么的吗？
是的，我最初打算在 Postgres 控制台中用 regexp_replace() 来修复一些 [QUOTE] 问题和 Textile → Markdown 转换，然后重新烘焙所有帖子，因为 rake posts:remap 命令太慢了。但后来我发现，Postgres 使用的正则表达式风格与 PCRE 不兼容，并且存在太多意外的异常，无法依赖它。所以，我打算在导入过程中通过 Pandoc 处理帖子，这样就可以让导入的站点运行起来并呈现出可用的状态，然后用 rake posts:remap 来修复表情符号关键字之类的小问题。
UNICORN_SIDEKIQS –\u003e 进程数（默认 1）DISCOURSE_SIDEKIQ_WORKERS –\u003e 进程内的线程数（默认 5）这可以减少碎片化，并且可以解决因导入而导致 Postgres 统计数据可能出现偏差的问题。
我以前也没见过这个建议。如果这是“总是一个好主意”，也许应该添加到 https://meta.discourse.org/t/pre-launch-checklist-after-migrating-from-another-platform/83996？
我记得很多年前是Sam还是Jeff给了我这个建议。我现在找不到了。也许我们应该检查一下这是否仍然是个好主意，以及/或者是否值得付出努力 
有没有人能分享一下最快地重新运行导入脚本并让它重新导入数据的技巧？我正在尝试调整导入脚本中的一些文本替换，当我不正确时，我必须删除 Discourse 数据库并运行 ./launcher rebuild import，这需要很长时间。我想在我的导入脚本中进行更改，并让它从头开始（我现在使用的是一个很小的网站骨架模拟数据库，所以运行导入器非常快）。
嗯。我正在测试另一次生产论坛数据的导入，这次是在一台相当强大的 VPS 上，拥有 8 个虚拟核心和 16GB RAM。我设置了：
UNICORN_SIDEKIQS=4
DISCOURSE_SIDEKIQ_WORKERS=20
UNICORN_WORKERS=16
有了这些设置，在 import_topics 阶段似乎并没有充分利用所有核心：
尽管有趣的是，在 user_import 阶段 CPU 图表显示超过 600%（因此使用了大约 6 个核心，每个核心 100%）。
我还注意到这个 env 变量：RUBY_GLOBAL_METHOD_CACHE_SIZE=131072，它会不会太小了？
我认为在用户创建状态下，Sidekiq 会处理更多异步操作。
不幸的是，导入的很大一部分将无法从并行化中受益，您应该优化单核 CPU 速度。
理论上，您可以并行运行主题导入的不同块，但这需要对导入器进行大量重构，并确保所有内容都按顺序处理。对于一次性任务，迭代次数不多，不值得这样做。
我遵循了这两个[1] 和 [2] 指南，通过访问运行源论坛数据库副本的另一个 Docker 容器（MySQL）来进行导入。但我突然想到，与其创建一个单独的 import 容器，不如只使用一个 app 容器，并向其中添加 mysql-dep.tempate：
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
- "templates/web.ssl.template.yml"
- "templates/web.letsencrypt.ssl.template.yml"
- "templates/import/mysql-dep.template.yml"
这样，在导入脚本运行时，我就可以拥有一个功能正常的 Discourse 实例。在导入完所有用户和类别后立即向公众开放论坛，并告知用户还需要几天才能完全填充，这样做有什么坏处吗？我想至少可以在导入完所有主题和帖子，但在导入私信之前就开放论坛，因为仅导入私信就需要大约 24 小时。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.