저는 업로드 파일을 모두 NAS 스토리지(glusterfs)에 호스팅하고 있습니다.
최근 NAS에서 크고 일정한 네트워크 트래픽이 발생하고 있음을 발견했습니다. 원인을 추적해 보니 Discourse가 최적화된 이미지를 요청하고 있었습니다. 이러한 이미지를 지속적으로 조회하는 작업(job)이 있는 건가요? 왜 그런 건가요? 그리고 이를 어떻게 끄나요?
참고로, 내 포럼에서는 업로드 사이트 설정의 정리 기능이 비활성화되어 있습니다.
다비드가(@david) 추가한 주 이미지 색상 조회용 백필일 가능성이 있습니다.
결국 완료되어 정상 상태로 돌아갈 것입니다.
백필을 위해 모든 이미지를 순회해야 하므로, 모든 이미지의 색상을 흰색 등으로 강제 설정하는 방식으로 우회할 수 있을 것입니다.
제 관점으로는,
15분마다 25개의 이미지를 처리하는 것으로 보입니다. 맞나요? 이는 매우 미미한 수준이어야 합니다. 그런데 저는 매 분마다 수천 개의 파일이 조회되는 것을 보고 있습니다.
또한 6개월 전의 대역폭을 살펴봐도 동일한 패턴을 확인할 수 있습니다. 따라서 다른 원인일 것 같습니다.
그러나 이는 Discourse 작업(job)이나 유사한 프로세스에 의해 수행되고 있다고 거의 확신합니다. Discourse 앱을 중지하면 대역폭 사용이 사라지지만, nginx만 중지해도 대역폭 사용은 계속되기 때문입니다.
/sidekiq를 확인해 보세요. 현재 실행 중인 작업을 알려 줄 거예요. 모든 탭을 클릭하는 것을 잊지 마세요.
실행 중인 작업이 없습니다. 
. 여기에 표시되지 않는 다른 작업이 있을까요?
아니면 컨테이너 내에서 파일 색인을 시도하는 것이 있을까요?
모든 백그라운드 로직은 Sidekiq 잡에서 처리됩니다. 현재 실행 중인 잡이 없는데도 디스크 I/O가 높은 상태라면, 사용자가 웹사이트를 방문하고 nginx를 통해 이미지가 서빙되고 있는 것일 수 있습니다.
정적 에셋 앞에 캐싱 CDN이 구성되어 있나요?
이전에 이 부분을 테스트해 보았습니다.
따라서 사용자가 웹사이트를 방문하기 때문이 아닙니다. 만약 그렇다면 nginx를 중지했을 때 트래픽이 사라졌어야 합니다.
그때에는 Linux 검사 도구를 사용하여 정확히 어떤 PID와 시스템 콜이 생성되고 있는지 확인해야 합니다.
먼저 Discourse 앱을 재시작하여 지속적인 트래픽을 제거했습니다. 그런 다음 관리 패널로 이동해 일괄 보고서(bulk reports) 섹션을 확인했습니다. 오랫동안 보고서가 제대로 표시되지 않고 있었습니다:
보고서가 타임아웃되는 즉시 네트워크 대역폭이 급증하는 것을 확인할 수 있었습니다. 또한 에러 로그에서 다음과 같은 오류를 확인했습니다:
'hijack admin/reports bulk ' is still running after 90 seconds on db default, this process may need to be restarted!
여기서 무엇이 잘못되고 있는 것일까요?
데이터베이스도 같은 NAS 스토리지에 있나요?
아니요, 데이터베이스는 물리적 SSD 디스크에 있습니다.
업로드 폴더만 NAS에 있습니다.
즉, 그 둘 사이에 상관관계가 없습니다. 다시
네트워크 공유에서 다음 명령을 실행하면
df -Pk
df -P
du -s
상당한 시간이 걸리나요?
아, 알겠습니다. 그 보고서 결과는 캐시되어 있긴 한데, 아마도 완료되지 않아 캐시할 수 없는 것 같습니다. 네트워크 공유기가 너무 느리기 때문이겠죠.
그렇다면 이를 방지하기 위해 우리가 할 수 있는 것이 있을까요? 예를 들어, 디스크 크기를 계산하지 않는 S3 업로드처럼 처리하는 것은 어떨까요?