その Droplet のサイズは、このようなインポートには十分な性能に見えますので、UNICORN_WORKERS が主要なボトルネックになるとは考えにくいです。
いくつかの観察結果を挙げます。
- インポート専用またはステージングコンテナの場合、Unicorn を停止しても問題ないかもしれませんが、インポータ自体の大幅な高速化にはつながらないでしょう。
- アタッチメントとアバターの無効化により、処理の遅い部分の 2 つが排除されるはずです。それでも約 440 投稿/分しか処理できていない場合、ボトルネックはデータベースの I/O、ソース側の phpBB MySQL クエリ、あるいは Redis/PostgreSQL の待機時間にある可能性があります。
- ログ行は注意深く監視する価値があります。
Exception while creating post 304683. Skipping.
インポートは継続していますが、少なくともその投稿はスキップされたことを意味します。これが繰り返し発生する場合、最終的な移行で投稿が欠落する可能性があります。
Redis 関連の部分は、PostCreator が投稿を作成している間に、Discourse の分散ミューテックスロックで Redis クライアントの 1 秒タイムアウトが発生しているように見えます。Redis が実際に過負荷になっているのか、それとも長時間のインポート中にタイムアウト設定が厳しすぎるのかを確認してください。
次に確認すべき有用なコマンドは以下の通りです。
free -h
df -h
iostat -xz 1
vmstat 1
redis-cli INFO memory
redis-cli INFO stats
redis-cli SLOWLOG GET 20
また、phpBB の MySQL データベースは同じ Droplet 上にローカルにあるのか、それともネットワーク経由で読み取られているのでしょうか？スタックトレースが mysql2 を介して反復処理を行っていることから、ソースデータベースが遅い場合やディスクが遅い場合、インポータが待機している間は CPU 使用率が低く抑えられることがあります。
現在の速度（333919 / 2167314、約 441 件/分）では、残り約 69 時間程度で完了する可能性がありますが、問題となるのは、これらの Redis タイムアウト例外によって投稿がスキップされていないかどうかです。
UNICORN_WORKERS を増やすことは推奨しません。インポート専用実行の場合、Unicorn はほとんど関係ありません。重要なのは、インポートが継続しているものの投稿がスキップされているという点であり、これが私が懸念する部分です。