O tamanho da droplet parece razoavelmente adequado para esse tipo de importação, então eu não esperaria que UNICORN_WORKERS fosse o principal limitador aqui.
Algumas observações:
- Parar o Unicorn provavelmente é aceitável para um container de importação ou staging, mas dificilmente acelerará significativamente o próprio importador.
- Com os anexos e avatares desabilitados, duas das etapas mais lentas devem ser removidas. Se você ainda estiver obtendo apenas ~440 posts/min, o gargalo pode estar na E/S do banco de dados, na consulta MySQL do phpBB de origem ou em esperas no Redis/PostgreSQL.
- Vale a pena observar com atenção a linha do log:
Exception while creating post 304683. Skipping.
Embora a importação continue, isso significa que pelo menos aquele post foi pulado. Se isso acontecer repetidamente, a migração final pode estar faltando posts.
A parte do Redis parece ser um timeout de 1 segundo no cliente Redis durante o bloqueio de mutex distribuído do Discourse enquanto o PostCreator está criando um post. Verifique se o Redis está realmente sobrecarregado ou se o timeout está apenas muito agressivo durante uma importação longa.
Próximas verificações úteis seriam:
free -h
df -h
iostat -xz 1
vmstat 1
redis-cli INFO memory
redis-cli INFO stats
redis-cli SLOWLOG GET 20
Além disso, o banco de dados MySQL do phpBB está local na mesma droplet ou sendo lido pela rede? Como o rastreamento de pilha está iterando pelo mysql2, um banco de dados de origem lento ou um disco lento podem manter o uso da CPU baixo enquanto o importador aguarda.
Na taxa atual, de 333919 / 2167314 a cerca de 441 itens/min, você ainda tem aproximadamente 69 horas restantes, então a importação pode terminar, mas minha principal preocupação é se essas exceções de timeout do Redis estão causando a omissão de posts.
Eu não sugeriria aumentar UNICORN_WORKERS. Em uma execução de importação exclusiva, o Unicorn é em grande parte irrelevante. O importante é que a importação está continuando, mas pulando posts, e é isso que eu destacaria.