こんにちは。以前の投稿でも言及しましたが、DrupalからDiscourseへの移行のテスト実行を行っており、古いサイトを最終的に停止して約200万件の投稿を含む本番データを移行する前に、すべてのソリューションを整えています。わかったことは、かなり高速なVPS（3vCPUコア搭載）でも、インポートプロセスに永遠にかかり、約48時間かかるということです。そして、おそらくrakeタスクやrails cでさらにクリーニングを行う必要があり、rake posts:rebakeが必要なものについては、さらに約20時間かかります。
Rubyツールチェーンの基本はあまり理解していませんが、CPUコアを増やせば、これらのプロセスのいずれかが完了するのに必要な時間を大幅に短縮できるでしょうか？たとえば、bundleコマンドやrakeコマンドは、利用可能なCPU間で作業を分割できるのでしょうか、それとも追加のコアは、複数のユーザーがウェブサイトにアクセスしている場合に複数の同時プロセスを実行するのに主に役立つのでしょうか？
オフラインになりますが、同じ数の投稿を持つフォーラム移行に取り組んでいたとき、インポートスクリプトを変更して、トピックと投稿を 1/100 または 1/1000 のみインポートするようにしました。
これにより、インポートが信頼できるかどうか、また調整やデバッグが必要かどうかをより迅速に確認できます。
@Canapin 実際、それに言及してくれて本当にありがとう。どうやったのかぜひ知りたいです。私も同じことをしたかったのですが、部分的なインポートではデータベースの不整合に遭遇するだろうと想定して、そのアイデアは捨てました。そのため、テスト用にスケルトンのDrupalテストフォーラムを作成しました。しかし、本番DBのコピーでテストする方が良いです。
主に最終的な本番移行が心配です。古いフォーラムをオフラインにするか、少なくとも読み取り専用にする必要があります。うまくいけば、ダウンタイムは最低でも48時間になるでしょう。CPUコアを2倍にしても時間は半分になるでしょうか？
復旧に時間がかかるタスクは、確かにマルチスレッドです。ただし、CPUが2倍になってもパフォーマンスが2倍になるとは限りません。
別の点として、通常 rake posts:rebake のタスクや、フォーラム自体がコンテンツを回復および最適化するための重い処理は、フォーラムが稼働中でも行うことができます。これにより、フォーラムをオフラインまたは読み取り専用にする必要がある時間を短縮でき、ある程度パフォーマンスが低下した状態を提供できます。
私の推奨は、まずテストすることです。マイグレーションを実行し、どれくらいの時間がかかるか、そしてすべてのリベイクが行われていない状態のフォーラムがどのように見えるかを確認してください。それで十分であれば、フォーラムのトラフィックが最も少ない時間帯にマイグレーションを終了するようにスケジュールしてください。そうすれば、多くの人が不満を言うことなく、4〜10時間のマイグレーション時間を稼ぐことができます。
素晴らしい、これで確認できました。このオプションについても疑問に思っていました。
残念ながら、書き留めておらず、忘れてしまいました…しかし、コーディングができるなら、それほど難しくないはずです。
ループを変更して投稿のバッチをスキップさせるために、BATCH_SIZE や offset の値などを調整したかもしれません…
現在、インポートするフォーラムがないため、再試行できませんが、非常に役立つと思うので、次回は簡単なチュートリアルを作成します。
2点お伝えしたいことがあります。
これら2つを組み合わせると、インポート用に大きなVPSを取得し、完了したら（バックアップと復元を使用して）小さな本番VPSに移動することになります。
一般的に、インポート後に投稿をリベイクする必要はありません。
リチャード、返信ありがとうございます。では、これらのうちどれを使用すればよいでしょうか？
UNICORN_WORKERSUNICORN_SIDEKIQSDISCOURSE_SIDEKIQ_WORKERS興味深いですね。この推奨事項は初めて見ました。断片化を減らすなどの効果があるのでしょうか？
はい、当初はPostgresコンソールで[QUOTE]の問題やTextileからMarkdownへの変換をregexp_replace()で修正し、その後すべての投稿を再ベイクしようと考えていました。なぜなら、rake posts:remapコマンドは非常に遅かったからです。しかし、Postgresが使用する正規表現のフレーバーはPCRE互換ではなく、予期しない異常が多すぎて頼ることができないことに気づきました。そのため、インポートプロセス中にPandocで投稿を処理し、インポートされたサイトを提示可能な状態で稼働させ、その後絵文字キーワードなどの細かい部分はrake posts:remapで修正するつもりです。
UNICORN_SIDEKIQS – プロセスの数（デフォルト1）DISCOURSE_SIDEKIQ_WORKERS – プロセス内のスレッド数（デフォルト5）断片化を減らし、インポートによってPostgresの統計情報が偏る可能性がある問題を修正します。
私もこのアドバイスは初めて見ました。もしこれが「常に良い考え」であるなら、Pre-launch checklist after migrating from another platform に追加すべきかもしれません。
何年も前にサムかジェフがくれたアドバイスだったと思うのですが、もう見つけられません。もしかしたら、まだ良い考えかどうか、あるいはそれだけの価値があるかどうかを確認した方が良いかもしれません 
インポートスクリプトを再実行し、データを再インポートする最も速い方法について、どなたかヒントを共有していただけますでしょうか？インポーターのスクリプトでテキスト置換を微調整しようとしていますが、うまくいかない場合はDiscourseデータベースを削除し、./launcher rebuild importを実行する必要があり、かなりの時間がかかります。インポーターのスクリプトで変更を加え、最初からやり直したいと考えています（現在、サイトの小さなスケルトンのモックアップデータベースを使用しているため、インポーターの実行は非常に高速です）。
うーん。今回は8コア仮想コアと16GBのRAMを搭載したかなり強力なVPSに、本番フォーラムデータを別のインポートでテストしています。以下のように設定しました。
UNICORN_SIDEKIQS=4
DISCOURSE_SIDEKIQ_WORKERS=20
UNICORN_WORKERS=16
これでも、import_topicsステージ中にすべてのコアを活用しているようには見えません。
しかし、user_importステージ中にCPUグラフが600%以上（つまり約8コア中6コアが100%使用）に達していたのは興味深いです。
また、この環境変数 RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 に気づきましたが、小さすぎるでしょうか？
ユーザー作成ステート中に、Sidekiq によって非同期で処理されるアクションがさらにいくつかあると思います。
インポートの大部分は残念ながら並列化の恩恵を受けられないため、シングルコア CPU 速度の最適化に注力する必要があります。
理論的には、トピックインポートのさまざまなチャンクを並列で実行できますが、インポーターのリファクタリングと、すべてが順序通りに処理されるようにするためのかなりの作業が必要になります。数回のイテレーションで完了する一度限りのタスクには、それだけの価値はありません。
これらの2つのガイド[1]と[2]を組み合わせて、MySQLでソースフォーラムのコピーを実行している別のDockerコンテナにアクセスしてインポートしました。しかし、個別の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.