Размер droplet выглядит достаточно мощным для такого импорта, поэтому я не ожидаю, что UNICORN_WORKERS станет здесь основным ограничителем.
Несколько наблюдений:
- Остановка Unicorn, вероятно, допустима для контейнера, предназначенного только для импорта или тестирования, но это вряд ли значительно ускорит сам процесс импорта.
- Отключение вложений и аватаров должно исключить два самых медленных этапа, поэтому, если вы всё ещё получаете лишь около 440 постов в минуту, узким местом может быть ввод-вывод базы данных, сторона запросов MySQL в исходном phpBB или задержки Redis/PostgreSQL.
- Строку лога стоит внимательно отслеживать:
Exception while creating post 304683. Skipping.
Хотя импорт продолжается, это означает, что как минимум этот пост был пропущен. Если это происходит repeatedly, финальная миграция может оказаться неполной.
Часть с Redis выглядит как тайм-аут клиента Redis в 1 секунду во время распределённой блокировки мьютекса в Discourse, пока PostCreator создаёт пост. Стоит проверить, действительно ли Redis перегружен, или же тайм-аут просто слишком агрессивен во время длительного импорта.
Полезными следующими шагами будут проверки:
free -h
df -h
iostat -xz 1
vmstat 1
redis-cli INFO memory
redis-cli INFO stats
redis-cli SLOWLOG GET 20
Также, находится ли база данных MySQL phpBB локально на том же droplet или читается по сети? Поскольку стек вызовов итерируется через mysql2, медленная исходная база данных или медленный диск могут удерживать использование CPU низким, пока импортёр ожидает.
При текущей скорости, от 333919 из 2167314 примерно по 441 элементу в минуту, у вас остаётся примерно 69 часов, так что импорт может завершиться, но меня в первую очередь беспокоит, не вызывают ли эти исключения тайм-аутов Redis пропуск постов.
Я не рекомендую увеличивать UNICORN_WORKERS. При запуске, предназначенном только для импорта, Unicorn в основном не имеет значения. Главное — импорт продолжается, но пропускает посты, и именно на это стоит обратить особое внимание.