해당 유형의 임포트 작업에 대해 드롭렛의 크기가 상당히 넉넉해 보이기 때문에, UNICORN_WORKERS가 여기서 주요 제한 요인일 것이라고는 생각하지 않습니다.
몇 가지 관찰 사항이 있습니다:
- 임포트 전용/스테이징 컨테이너의 경우 Unicorn을 중지하는 것이 괜찮을 수 있지만, 임포터 자체의 속도를 극적으로 높여 주지는 않을 가능성이 높습니다.
- 첨부 파일과 아바타가 비활성화되어 있으므로 느린 부분 중 두 가지가 제거되었어야 합니다. 그럼에도 불구하고 여전히 분당 약 440개 정도의 게시물만 처리되고 있다면, 병목 현상은 데이터베이스 I/O, 소스 phpBB MySQL 쿼리 측, 또는 Redis/PostgreSQL 대기 시간일 수 있습니다.
- 다음 로그 라인을 주의 깊게 살펴볼 가치가 있습니다:
Exception while creating post 304683. Skipping.
임포트가 계속 진행되더라도, 이는 해당 게시물이 최소한 건너뛰어졌음을 의미합니다. 이 상황이 반복적으로 발생한다면 최종 마이그레이션에서 일부 게시물이 누락될 수 있습니다.
Redis 부분은 PostCreator가 게시물을 생성하는 동안 Discourse의 분산 뮤텍스 락(lock) 과정에서 발생한 1초 Redis 클라이언트 타임아웃으로 보입니다. 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 데이터베이스가 같은 드롭렛에 로컬로 존재하는지, 아니면 네트워크를 통해 읽히고 있는지도 확인해 주세요. 스택 트레이스가 mysql2를 반복하고 있으므로, 느린 소스 데이터베이스나 느린 디스크는 임포터가 대기하는 동안 CPU 사용률을 낮게 유지할 수 있습니다.
현재 속도(분당 약 441개, 333919 / 2167314)로 계산하면 약 69시간이 더 소요될 것으로 보이며, 완료될 수는 있겠지만, Redis 타임아웃 예외가 게시물의 건너뛰기를 유발하고 있는지에 대해 주로 우려가 됩니다.
UNICORN_WORKERS를 높일 것을 권하지 않습니다. 임포트 전용 실행에서는 Unicorn은 대부분 관련이 없습니다. 중요한 것은 그의 임포트가 계속 진행되고 있지만 게시물을 건너뛰고 있다는 점이며, 이것이 제가 지적하고 싶은 부분입니다.