That droplet size looks reasonably strong for this kind of import, so I would not expect UNICORN_WORKERS to be the main limiter here.
A couple of observations:
- Stopping Unicorn is probably fine for an import-only/staging container, but it likely will not massively speed up the importer itself.
- Attachments and avatars being disabled should remove two of the slower parts, so if you are still only getting ~440 posts/min, the bottleneck may be database I/O, the source phpBB MySQL query side, or Redis/PostgreSQL waits.
- The log line is worth watching carefully:
Exception while creating post 304683. Skipping.
Even though the import continues, that means at least that post was skipped. If this happens repeatedly, the final migration may be missing posts.
The Redis part looks like a 1-second Redis client timeout during Discourse’s distributed mutex lock while PostCreator is creating a post. I would check whether Redis is actually overloaded or whether the timeout is just too aggressive during a long import.
Useful next checks would be:
free -h
df -h
iostat -xz 1
vmstat 1
redis-cli INFO memory
redis-cli INFO stats
redis-cli SLOWLOG GET 20
Also, is the phpBB MySQL database local on the same droplet, or being read over the network? Since the stack trace is iterating through mysql2, a slow source database or slow disk can keep CPU usage low while the importer waits.
At the current rate, from 333919 / 2167314 at about 441 items/min, you still have roughly 69 hours left, so it may finish, but I would mainly be concerned about whether those Redis timeout exceptions are causing skipped posts.
I’d not suggest raising UNICORN_WORKERS. On an import-only run, Unicorn is mostly irrelevant. The important thing is that his import is continuing but skipping posts, which is the part I’d flag.