3.4.0.beta4-dev(58f75ed205) 업그레이드 이후 CPU 사용량 증가

제품 지원
1

이번 주말 업그레이드 이후 CPU 사용량이 상당히 증가한 것을 확인했습니다. RUBY 프로세스가 주요 원인으로 보입니다. 이는 해당 토픽에서 다른 디스코스(Discourse) 사용자가 언급한 내용과 일치합니다.

아래 그래프에서 볼 수 있듯이, 업그레이드 이전의 CPU 사용량과 로드는 업그레이드 이후보다 훨씬 낮았습니다. 업그레이드는 1월 31일 저녁에 수행되었습니다.

1월 27일부터 2월 2일까지의 CPU 및 로드(%)를 보여주는 그래프입니다. (AI가 작성한 캡션)
1월 27일부터 2월 2일까지의 CPU 및 로드(%)를 보여주는 그래프입니다. (AI가 작성한 캡션)985×619 68.1 KB

33시간 간격으로 촬영한 TOP 명령어 실행 결과 두 장입니다:

2월 1일 오후 1:00 (CT) TOP 데이터
2월 1일 오후 1:00 (CT) TOP 데이터689×219 9.92 KB

2월 2일 오후 9:45 (CT) TOP 데이터
2월 2일 오후 9:45 (CT) TOP 데이터649×192 8.48 KB

33시간 동안 ruby 프로세스의 CPU 사용량이 현저히 증가했습니다. TOP 데이터에 따르면, 지난 22일 동안의 CPU 사용량 대비 최근 33시간 동안 CPU 사용량이 2배로 증가했습니다. 33시간 동안 총 11시간의 CPU 시간을 사용했습니다. (5개의 PID에 걸쳐 총 648분)

추가 데이터:

  • 지난 이틀간 트래픽은 약 10% 감소했습니다. (애널리틱스 및 대시보드 기준)
  • 표준 단일 컨테이너 Discourse 설치 (채팅 없음)
  • Sidekiq 큐는 최소 수준입니다. (하루 1,000~2,000건)
  • Discourse 로그에서 특이한 사항은 발견되지 않았습니다.
  • 8GB RAM과 2개 AMD vCPU를 갖춘 DO(DigitalOcean) 서버에서 실행 중입니다.

서버가 완전히 다운된 상황은 아니지만, 5%~7% 수준으로 돌아가는 서버가 25% 수준으로 돌아가는 서버보다 훨씬 안정적입니다.

이 문제를 해결하는 데 도움이 될 수 있는 어떤 정보를 제공해야 할까요?

감사합니다.

2

버그가 있는지 확인하기까지 잠시 지원 티켓으로 남겨두겠습니다.

컨테이너에 들어가서 htop을 실행해 볼 수 있을까요? (설치가 필요합니다) 이렇게 하면 CPU 사용량이 높은 특정 프로세스를 확인할 수 있습니다.

다음과 같은 기법을 사용하면 더 많은 정보를 얻을 수 있습니다: Debugging 100% CPU usage in production Ruby on Rails systems

그러나 가장 가능성이 높은 경우는 sidekiq /sidekiq가 인스턴스에서 과부하 상태인 것입니다. (특히 스케줄러를 살펴보는 것이 좋습니다)

3

htop 뷰.

30초짜리 영상입니다:

랜덤 스크린샷:

이미지는 Unix 계열 시스템의 프로세스 목록 또는 작업 관리기를 보여주며, 여러 'unicorn worker' 프로세스 인스턴스에 초점을 맞추고 있고, 사용자 ID, 프로세스 ID, 우선순위, CPU, 메모리 사용량, 예상 실행 시간 등 구체적인 세부 정보를 제공합니다. (AI 캡션)
이미지는 Unix 계열 시스템의 프로세스 목록 또는 작업 관리기를 보여주며, 여러 'unicorn worker' 프로세스 인스턴스에 초점을 맞추고 있고, 사용자 ID, 프로세스 ID, 우선순위, CPU, 메모리 사용량, 예상 실행 시간 등 구체적인 세부 정보를 제공합니다. (AI 캡션)1140×852 98.8 KB

이 이미지는 Unix 계열 시스템의 프로세스 및 CPU 사용량 출력을 보여주며, Chrome, javascript, Redis와 관련된 여러 워커 프로세스와 PID, 사용자, CPU 사용률(%) 등 세부 정보를 포함합니다. (AI 캡션)
이 이미지는 Unix 계열 시스템의 프로세스 및 CPU 사용량 출력을 보여주며, Chrome, javascript, Redis와 관련된 여러 워커 프로세스와 PID, 사용자, CPU 사용률(%) 등 세부 정보를 포함합니다. (AI 캡션)1139×860 99.7 KB

이 이미지는 Redis 서버와 관련된 여러 프로세스를 주로 보여주는 Unix 시스템의 프로세스 목록 스크린샷으로, PID, 사용자, 우선순위, VIRT 및 기타 시스템 관련 정보 등을 포함합니다. (AI 캡션)
이 이미지는 Redis 서버와 관련된 여러 프로세스를 주로 보여주는 Unix 시스템의 프로세스 목록 스크린샷으로, PID, 사용자, 우선순위, VIRT 및 기타 시스템 관련 정보 등을 포함합니다. (AI 캡션)1153×878 101 KB

이 이미지는 실행 중인 "discourse" 프로세스 출력과 다양한 프로세스 세부 정보, 시스템 정보, 실행된 명령어를 보여주는 Unix 계열 운영체제 명령줄 터미널 스크린샷입니다. (AI 캡션)
이 이미지는 실행 중인 "discourse" 프로세스 출력과 다양한 프로세스 세부 정보, 시스템 정보, 실행된 명령어를 보여주는 Unix 계열 운영체제 명령줄 터미널 스크린샷입니다. (AI 캡션)1134×505 59.4 KB

트리 뷰:

이미지는 타임스탬프, 명령어, 사용자 작업을 포함하는 서버 로그의 일부를 보여주며, "sdekiq" 및 "unicorn worker" 프로세스가 "discourse" 및 관련 구성 명령어와 상호작용하는 것을 나타내는 녹색과 빨간색 텍스트의 반복된 줄이 보입니다. (AI 캡션)
이미지는 타임스탬프, 명령어, 사용자 작업을 포함하는 서버 로그의 일부를 보여주며, "sdekiq" 및 "unicorn worker" 프로세스가 "discourse" 및 관련 구성 명령어와 상호작용하는 것을 나타내는 녹색과 빨간색 텍스트의 반복된 줄이 보입니다. (AI 캡션)1151×674 104 KB

이 이미지는 top 명령어를 사용하여 프로세스와 시스템 메트릭을 표시하는 Linux 시스템의 스크린샷입니다. (AI 캡션)
이 이미지는 top 명령어를 사용하여 프로세스와 시스템 메트릭을 표시하는 Linux 시스템의 스크린샷입니다. (AI 캡션)1150×879 119 KB

sidekiq:

이 이미지는 처리된 수, 실패한 이미지 몇 개, 그리고 바쁨 상태, 대기열에 등록된 항목, 재시도, 예약된 항목, 죽은 이미지 등 상세 정보와 각 큐에 대한 삭제 작업을 보여주는 큐 관리 대시보드 스크린샷입니다. (AI 캡션)
이 이미지는 처리된 수, 실패한 이미지 몇 개, 그리고 바쁨 상태, 대기열에 등록된 항목, 재시도, 예약된 항목, 죽은 이미지 등 상세 정보와 각 큐에 대한 삭제 작업을 보여주는 큐 관리 대시보드 스크린샷입니다. (AI 캡션)1189×428 43.8 KB

이 라인 차트는 며칠 동안의 이미지 캡션 작업 진행 상황을 보여주며, 다른 시간에 실패한 시도를 나타내는 세로 마커가 표시되어 있습니다. (AI 캡션)
이 라인 차트는 며칠 동안의 이미지 캡션 작업 진행 상황을 보여주며, 다른 시간에 실패한 시도를 나타내는 세로 마커가 표시되어 있습니다. (AI 캡션)1203×296 50.5 KB

이 이미지는 "discourse-app:817"이라는 이름의 프로세스가 0% 사용률, 461 MB의 RSS로 실행되고 있으며, 제공된 버튼을 사용하여 일시 중지하거나 중지할 수 있는 서버 패널을 보여줍니다. (AI 캡션)
이 이미지는 "discourse-app:817"이라는 이름의 프로세스가 0% 사용률, 461 MB의 RSS로 실행되고 있으며, 제공된 버튼을 사용하여 일시 중지하거나 중지할 수 있는 서버 패널을 보여줍니다. (AI 캡션)1229×537 73.1 KB

구체적으로 보고 싶은 것이 있으면 알려주세요. I

4

음, 뭔가 이상해요:

top -H -p PID_OF_UNICORN

시스템 리소스와 프로세스를 보여주는 top 명령어 출력 스크린샷. 367개의 스레드가 있으며, 대부분 ruby 또는 colourer-2480 프로세스가 실행 중이고 RAM 사용량은 대부분 여유롭지만 일부 사용 중인 상태입니다. (AI 캡션)
시스템 리소스와 프로세스를 보여주는 top 명령어 출력 스크린샷. 367개의 스레드가 있으며, 대부분 ruby 또는 colourer-2480 프로세스가 실행 중이고 RAM 사용량은 대부분 여유롭지만 일부 사용 중인 상태입니다. (AI 캡션)1242×610 102 KB

거기서 V8 DefaultWorker를 볼 수 있을 것 같아요. 이건 mini_racer의 회귀(regression) 문제인 것 같네요. 이 문제가 해결되는지 확인하기 위해 되돌려 볼게요.

5

네, 이제 되돌려 놓았습니다.

커밋으로 성능이 복원되었는지 알려주세요.

6

네, 높은 CPU 사용량 문제가 해결되었습니다. 1분 및 5분 평균 부하가 이전 값의 약 1/3 수준으로 낮아졌습니다. 이는 현재 시스템에서 htop과 netdata가 실행 중인 상태에서의 결과입니다.

HTOP 영상

Do 그래프

이미지는 다양한 시간 간격에 걸쳐 CPU 사용률과 부하(1/5/15)를 보여주는 두 개의 선 그래프로, 서로 다른 선이 각각 다른 부하(0.100, 1.000, 15.000, 50.150)를 나타냅니다. (AI 캡션)
이미지는 다양한 시간 간격에 걸쳐 CPU 사용률과 부하(1/5/15)를 보여주는 두 개의 선 그래프로, 서로 다른 선이 각각 다른 부하(0.100, 1.000, 15.000, 50.150)를 나타냅니다. (AI 캡션)988×553 28.2 KB

시스템에 더 많은 데이터베이스 쿼리가 캐시됨에 따라 CPU 사용량과 부하가 서서히 감소할 것으로 예상됩니다.

부하 테이블:

시간 수정 전 수정 후
1분 0.4 ~ 0.6 0.06 ~ 0.1
5분 0.39 ~ 0.5 0.15 ~ 0.18

15분 지표는 재빌드(rebuild)의 영향을 받습니다. 오늘 아침에 추가 통계를 공유하겠습니다.

늦은 밤까지 수정해 주셔서 감사합니다.

7

죄송합니다. mini_racer 업그레이드가 정말 큰 모험이었어요. 곧 해결될 수 있기를 바랍니다.

8

빠른 응답과 조사를 위해 감사합니다.

롤백보다는 그날 다른 계획이 있으셨을 텐데요.

이주 후 2주째인 신규 Discourse 사용자로서, 이 제품은 사용감이 매우 좋습니다.

9

여기서도 비슷한 상황입니다.

이미지에는 두 개의 차트가 포함된 상세한 그래프가 표시됩니다: 상단 차트는 1월 27일에 2.03%의 CPU 사용률로 표시된 현저한 피크가 강조된 CPU 사용률의 시간별 변화를 보여주는 다채로운 선 그래프이고, 하단 차트는 시스템 부하를 선 그래프 형식으로 표시하며, 무시할 수 있는... (AI 캡션)
이미지에는 두 개의 차트가 포함된 상세한 그래프가 표시됩니다: 상단 차트는 1월 27일에 2.03%의 CPU 사용률로 표시된 현저한 피크가 강조된 CPU 사용률의 시간별 변화를 보여주는 다채로운 선 그래프이고, 하단 차트는 시스템 부하를 선 그래프 형식으로 표시하며, 무시할 수 있는... (AI 캡션)2208×1234 295 KB

[수정: 최신 브랜치로 업데이트한 후 이제 해결된 것 같습니다]

10

재빌드 후 18시간이 지난 성능 검토 결과입니다. 부하 테이블이 모든 것을 말해 줍니다.

부하 테이블:

시간 수정 전 수정 후
1분 0.4 ~ 0.6 0.03 ~ 0.05
5분 0.39 ~ 0.5 0.09
15분 0.68 0.12

범례:

  • 빨간 화살표 - 앱 재빌드
  • 보라색 화살표 - netdata 종료

이미지에는 두 개의 그래프가 표시되어 있습니다: 하나는 높은 CPU 사용량을 나타내는 빨간 화살표가 있고, 다른 하나는 하루 중 다른 시점에 발생하는 부하 스파이크를 보여주는 보라색 화살표가 있습니다. (AI 캡션)
이미지에는 두 개의 그래프가 표시되어 있습니다: 하나는 높은 CPU 사용량을 나타내는 빨간 화살표가 있고, 다른 하나는 하루 중 다른 시점에 발생하는 부하 스파이크를 보여주는 보라색 화살표가 있습니다. (AI 캡션)984×551 54.8 KB

11

참고로, 루프를 닫으면서, 이 문제를 일으키던 버그는 다음과 같았습니다:

저는 해당 지엠(gem)을 업데이트했습니다. 즉각적인 이점 중 하나는 이 v8 버전이 약간 더 적은 메모리를 사용한다는 점으로, 이는 좋은 소식입니다.

12

어젯밤 수정이 포함된 최신 릴리스를 설치했습니다. CPU 사용량이 과거 수준으로 돌아왔습니다.

훌륭한 작업에 감사드립니다.