어제 온프레미스에서 3.3.0.beta3-dev로 업그레이드한 후 극심한 로드 오류 발생

[Jose_C_Gomez]

어제 3.3.0.beta3-dev로 업그레이드하고 AI 플러그인도 설치했습니다. 현재 해당 플러그인은 스태프(5명)만 사용하도록 설정되어 있습니다.

하지만 사이트 전체가 극도로 느리고, 심한 로드 에러가 발생하고 있습니다. 서버 로드는 정상적인 것으로 보이는데, 어디서 문제가 발생하는지 파악이 되지 않습니다.

이 문제를 해결하기 위해 확인할 수 있는 곳이 있을까요?

[Jose_C_Gomez]

크롤러 리포트에서 확인되는 내용은 다음과 같습니다. 이게 나쁜 건지 좋은 건지, 아니면 뭔지 모르겠네요. 기준이 없어서요.

[Jose_C_Gomez]

서버를 살펴보니 유니콘 프로세스가 꽤 바쁜 것 같습니다.

이것이 원인이 될까요? CPU를 더 늘려야 하나요, 아니면 유니콘 워커를 더 늘려야 하나요?

[pfaffman (Jay Pfaffman)]

마지막 업그레이드 이후로 시간이 좀 지났나요? 아마 이미지 처리나 리베이킹(rebaking)을 하고 있는 것일 수 있습니다.

/sidekiq에서 현재 어떤 작업이 진행 중인지 확인해 볼 수 있습니다.

[Jose_C_Gomez]

큐가 비어 있습니다

나머지 부분의 의미가 정확히 무엇인지 잘 모르겠습니다.

여기서 정상적인 상태가 무엇인지 확실하지 않습니다… 저희 서버 사양은 다음과 같습니다.

[Jose_C_Gomez]

모든 것을 재시작한 후에는 정상으로 돌아왔지만, 이제 다시 극심한 부하가 발생하고 있습니다. 문제가 어디서 발생하는지 파악할 수 없는데, discourse 내에서 이 문제를 해결하는 데 도움이 되는 도구가 있을까요?

[Jose_C_Gomez]

즉, 유니콘 워커 3개

바쁘게 돌아가고 있습니다… 하지만 제 판단으로는 트래픽이 평소보다 높지는 않은 것 같습니다. 이전과 비슷해 보이는데, 유일한 변경 사항은 3.3.0으로 업그레이드하고 AI 플러그인을 추가한 것입니다. 단, 이 플러그인은 스태프만 사용할 수 있습니다.

문제는 어제 6/3부터 시작되었습니다.

크롤러가 몇 개 더 있는 것 같습니다.

이것은 1개월간의 크롤러 데이터입니다. 하지만 역시 크게 늘어난 것 같지는 않습니다. 사이트가 거의 사용 불가능한 상태입니다.

도움 주시면 감사하겠습니다!

[simon]

추측일 뿐이지만, Sidekiq 로그에서 눈에 띄는 유일한 것은 표시된 작업이 NotifyMailingListSubscribers라는 점입니다. 이 작업은 잠재적으로 많은 요청을 생성할 수 있습니다.

또한, 관리자 / 로그 / 오류 로그 페이지에서 오류를 확인하고 계신가요?

[Jose_C_Gomez]

페이스북 크롤러를 차단하는 블록을 추가했는데, 그 녀석이 너무 심하게 몰아쳤거든요.

하지만 slow / crawlers 항목을 추가해도 robots.txt가 업데이트되지 않는 것을 발견했습니다.

robots.txt에는 slow 항목이 표시되지 않고, block 항목만 표시됩니다.

[Jose_C_Gomez]

@simon

또한, 관리자 / 로그 / 오류 로그 페이지에서 오류가 표시됩니까?

이런 오류가 꽤 많이 나옵니다.

오류 3가지를 확인했지만, 서로 관련이 없어 보입니다… (단정하기는 어렵지만요)

Job exception: PG::DatetimeFieldOverflow: ERROR:  timestamp out of range: "271768-09-23 06:24:11.793040 BC"
LINE 1: ...sers"."moderator" = FALSE AND (users.created_at < '271768-09...
                                                             ^

ActionDispatch::RemoteIp::IpSpoofAttackError (IP spoofing attack?! HTTP_CLIENT_IP="10.10.121.119" HTTP_X_FORWARDED_FOR="14.140.10.244, 14.140.10.244")
app/controllers/topics_controller.rb:1298:in `track_visit_to_topic'
app/controllers/topics_controller.rb:169:in `show'
app/controllers/application_controller.rb:422:in `block in with_resolved_locale'
app/controllers/application_controller.rb:422:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:64:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:391:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:291:in `call'

그리고 SMTP 관련 작업 예외도 하나 더 있습니다.

[supermathie (Michael Brown)]

@Jose_C_Gomez

robots.txt에는 느린 항목은 표시되지 않고, 차단 항목만 표시됩니다.

Discourse는 robots.txt에 의존하지 않고 자체적으로 레이트 리미팅을 수행합니다.

[Jose_C_Gomez]

마이크, 감사합니다.

이것이 무엇일 수 있다는 다른 아이디어가 있나요? 유니콘을 더 많이 회전시키면 도움이 될까요?

그것이 app.yml에서 수행되나요?

[supermathie (Michael Brown)]

@Jose_C_Gomez

유니콘을 더 많이 회전시키면 도움이 될까요?

네, 그 방법이 도움이 될 가능성이 높습니다.

env:
  UNICORN_WORKERS: 8

를 app.yml에 추가하면 됩니다.

해당 플러그인이 설정되어 있다면 prometheus 플러그인을 사용하여 성능 수치를 확인하는 것을 권장합니다. 그렇지 않다면 성능 헤더를 사용할 수도 있습니다.

웹 로그를 분석하면 서버가 과부하 상태인 이유를 파악하는 데 큰 도움이 될 것입니다. 크롤러가 좋은 시작 지점이 될 것 같습니다.

[Jose_C_Gomez]

드디어 업그레이드 완료했습니다. 새로운 DO 인스턴스로 업그레이드하면서 RAM과 CPU를 두 배로 늘렸고, 유니콘 프로세스 수도 3개에서 8개로 늘렸습니다. 데이터베이스 재인덱싱과 vacuum도 수행했는데, 이제 정상 운영이 재개된 것 같습니다!

도움 주셔서 감사합니다.