ckshen
11월 23, 2020, 10:59오후
1
안녕하세요. 최근 저희 인스턴스에서 “극단적 부하(extreme load)” 메시지가 더 자주 발생하고 있습니다. 오늘도 오전 9시 40분에 발생했습니다.
서버 로그를 확인해 보니 오전 9시 40분 당시 CPU와 부하(load)는 정상으로 보였습니다:
메모리 사용량도 하루 종일 꽤 일정한 편이었습니다:
스파이크는 디스크 I/O와 출/입력(outbound/inbound) 대역폭에서 발생한 것으로 보였습니다:
이로 인해 오전 9시 40분에 크롤러 요청이 원인일 것이라는 추측으로 이어졌습니다. 하지만 이를 확인할 방법이 있는지 모르겠습니다. 크롤러 목록과 요청 수를 확인해 보니 대부분이 Google과 Bing에서 온 것으로, 당연히 이들을 차단할 수는 없었습니다.
이로 인해 다음과 같은 질문이 생겼습니다.
특정 시점에 누가 사이트를 액세스하고 있는지 확인할 수 있는 로그가 있나요?
이러한 ‘양질의’ 크롤러들이 요청을 분산하도록 설정할 방법이 있나요?
서버에 더 많은 CPU/메모리를 추가하는 것이 이 상황을 해결하는 데 도움이 될까요? CPU/메모리 사용량이 스파이크를 보이지 않았기 때문에 이에 대해 약간 회의적입니다. 평균 80%의 메모리 사용률은 너무 높은 건가요?
현재 2 vCPU / 2GB 메모리를 사용하고 있습니다. 인스턴스를 4개 unicorn 워커로 설정했는데, 이는 저희가 가진 RAM 용량과 부합하는 수준으로 보입니다.
Falco
11월 23, 2020, 11:49오후
2
네, /var/discourse/shared/standalone/log/var-log/nginx/access.log 파일을 확인해 보세요.
네, slow down crawler user agents 사이트 설정을 사용할 수 있습니다.
9:40 정점 시간대에 I/O 대기 상태였었던 것으로 보입니다. 더 많은 데이터를 캐시에 유지할 수 있으므로 RAM을 늘리면 도움이 될 수 있지만, 그래프 범례를 잘라 놓으셨기 때문에 해당 정점이 읽기인지 쓰기인지 알 수 없습니다
그럼에도 불구하고, 예산이 허락한다면 드롭렛(Droplet) 크기를 다음으로 더 큰 크기로 늘리는 것이 항상 도움이 됩니다.
감사합니다. 오전 9시 40분경 로그를 확인해 보니 요청들은 크롤러보다는 사용자 활동(소비자 브라우저)에서 온 것처럼 보입니다.
녹색 피크는 읽기 요청이었습니다.
네, 크롤러 때문이 아닌 것 같으니 다음 드롭렛 크기로 변경하고 RAM을 2GB에서 4GB로 늘려보면서 효과를 확인해 보겠습니다.
사용자 활동이 원인이란 사실은 조금 놀랍습니다. 지난 2년간 이전보다 활동적인 게시자가 줄었다고 생각했거든요. 하지만 Google Analytics를 확인해 보니 사용자 수는 꾸준히 증가하고 있었습니다. 아마 게시자는 줄었지만, 단순히 글을 읽기만 하는 사용자(Lurker) 수는 늘어난 것이겠죠…
좋은 조언 감사합니다. 정말 감사합니다.
그래프를 살펴보면, 특히 디스크 I/O와 로드 스파이크 측면에서 메모리를 2배로 늘리는 것이 확실히 차이를 만드는 것 같습니다.
.
