재구축에 약 3시간 소요

내 문제는 아니지만, 이 말은 다른 게 없다는 뜻인가요?

의도적으로 그런 것은 아니겠지만, 호스트에서 암호화폐 채굴 프로세스 등이 실행되고 있는지 감사(audit)를 해보는 것이 좋을 수도 있습니다.

1단계: 이미 식별된 vfs 드라이버 사용으로 인한 성능 문제 수정

이 swap 작업으로 (이상적으로는) overlay2를 사용하려면, 현재 설치를 지우고 모든 것을 다시 설치해야 합니다. 현재 제가 있는 호스트는 fuse-overlayfs 또는 vfs만 지원하며, 이 둘은 모두 권장되지 않기 때문입니다.
그러나 곧 overlay2를 지원하는 KVM이 활성화될 예정입니다.

따라서 저의 의도는 권장되지 않는 fuse-overlayfs 대신 그 KVM을 사용하는 것입니다.

자, Discourse 앱 자체에서는 백업을 수행할 수 있습니다. 이것이 정확히 무엇을 백업하는 것일까요?

현재 Discourse 포럼에서(메시지, 채팅, 설정, 사용자, 업로드된 이미지 등) 어떤 정보도 잃지 않을 것이라면, 백업을 수행한 후 새로운 서버에 새로운 Discourse를 설치하고, 초기 Discourse 설정 후 그 백업으로 덮어쓰는 방식으로 진행할 수 있을까요?

이것이 작동할까요?

네, 그렇게 하면 됩니다.

한 가지 언급하지 않은 점은, 현재 Discourse에 있는 플러그인과 동일한 플러그인이 새 Discourse에도 설치되어 있는지 확인하는 것입니다. app.yml 파일을 재사용한다면 이 부분도 문제없을 것입니다.

맞아요, 그 점을 짚어줘서 고마워요. 제가 그대로 부딪혔을 것 같아요.

자, 그러면…

  1. Discourse 관리자 영역에서 백업 생성
  2. 안전을 위해 서버 전체도 백업
  3. yaml 파일 복사본 생성
  4. 서버 덤프 생성
  5. 지원되는 기술로 새 서버 설정
  6. 적절한 스토리지 드라이버로 Docker 설치
  7. 백업된 yaml 파일을 사용해 완전히 새로운 Discourse 인스턴스 재구축
  8. 백업에서 Discourse 복원

백업 파일이 겨우 19.2MB라 조금 놀랐어요.
이미 여러 이미지 등을 업로드했는데… 어쨌든 시도해볼 수밖에 없겠죠.

주말에 진행해보고 스토리지 드라이버 변경이 해결책이었는지 결과를 알려드릴게요.

아래 항목이 설정되어 있는지 확인해 주세요:

image

해당 설정은 예약 백업에만 적용되며, 수동 백업에는 적용되지 않음을 유의해 주세요. 수동 백업의 경우 항상 명시적인 선택지를 제공합니다.

활성화해야 할 또 다른 설정은 include thumbnails in backups입니다.

@smileBeda 모든 것이 정상적으로 작동하는 것을 확인한 후 #4를 미루는 것을 제안합니다.

실제로는 확인되었지만, Include generated thumbnails in backups. Disabling this will make backups smaller, but requires a rebake of all posts after a restore.는 확인되지 않았습니다.

@RGJ … 맞아요, 좋은 생각이에요. 새 법인으로 서버를 생성해야 하므로 더 많은 단계를 거쳐야 하지만, 위험성에 비하면 사소한 문제입니다.

수동 백업에는 이미지 등이 포함되지 않는다고 이해하고 있으므로, 자동 백업 트리거를 사용하겠습니다. 그러면 모든 데이터가 포함되니까요.

감사합니다…

그것은 잘못된 가정입니다.

수동으로 백업을 생성할 때 팝업 창을 통해 데이터베이스만 백업할지, 업로드된 파일을 포함할지 선택할 수 있습니다.

예약된 백업을 생성할 경우 업로드 포함 백업 설정이 이를 결정합니다.

네, 이전의 해당 특정 설정은 예약된 백업에만 적용되며, 수동 백업에는 적용되지 않습니다.라는 내용을 오해했네요.

감사합니다…

Hi, 이 주제가 아직 열려 있어서 재사용합니다. 새 가상 서버로 마이그레이션한 후에도 동일한 문제가 발생하고 있습니다. 다른 분들 말씀처럼, 저희는 Discourse를 재구축하는 데 20분이 채 걸리지 않았는데, 이번 새 서버에서는 몇 시간이나 걸리고 있습니다. 게다가 이 서버는 이전 서버보다 리소스가 두 배나 더 많습니다. :thinking:

Meta에서 수 시간씩 걸리는 업그레이드에 대한 다른 주제들을 살펴봤지만, 저희 서버의 문제가 무엇인지 파악이 되지 않습니다:

서버: 4GB RAM, 2CPU, 50GB 디스크.

스왑:

/$ free
               total        used        free      shared  buff/cache   available
Mem:         3911740      507208     2318476         268     1384032     3404532
Swap:        4095976       45472     4050504

Docker:

/$ sudo docker info
Client:
 Version:    26.1.3
 Context:    default
 Debug Mode: false

Server:
 Containers: 3
  Running: 0
  Paused: 0
  Stopped: 3
 Images: 3
 Server Version: 26.1.3
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 
 runc version: 
 init version: 
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.8.0-31-generic
 Operating System: Ubuntu 24.04.2 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.731GiB
 Name: podkasts
 ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

저에게는 정상적으로 보이는데, 혹시 제가 놓치고 있는 것이 있을까요? 다른 어디를 확인해 볼 수 있을까요?

사용하지 않는 CPU 리소스를 다른 사용자가 모두 점유하고 있어서, 새로운 VM이 이전 VM보다 느려지는 ‘노이ジー 네이버(noisy neighbor)’ 현상일 수 있습니다.

네, 감사합니다. 경험이 풍부한 관리자이신 분이 위 정보에서 명백한 문제를 발견하지 못하셨다는 점은 안심되는 점입니다. 그리고 네, 물리 서버와 가상 네트워크 환경을 점검하기 시작했습니다. 적어도 포럼은 사용자가 인지할 수 있는 문제 없이 정상적으로 작동하고 있습니다. 심각한 성능 문제는 재빌드(rebuild) 시에만 발생합니다. 어제 재빌드에는 4시간이 걸렸습니다. :face_with_spiral_eyes:

이 문제가 내 것이라면, 터미널 창을 두세 개 열어 둘 것입니다. 하나는 리빌드를 실행하는 용도, 하나는 경과 시간과 로그 업데이트 사이에 발생하는 긴 지연이 어디서 일어나는지 기록하기 위한 용도, 그리고 마지막 하나는 머신 활동을 기록하기 위한 용도입니다. 아마도 vmstat 5를 실행할 것입니다.

로그가 의심스럽게도 오랫동안 업데이트되지 않는 지점에 도달하면, vmstat가 보고하는 활동을 메모해 두세요.

로그에서 적절한 발췌 부분과 함께 메모와 해당 시점의 vmstat 출력을 여기에 올려주세요.

리빌드의 특정 부분에서 시간이 많이 소요되고 있을 가능성이 매우 높습니다. 해야 할 일은 어떤 부분인지 찾아내고, 그 시점에 머신이 무엇을 하고 있는지를 확인하는 것입니다.

아마도 정지되는 동안에도 ps auxf를 사용하여 머신 활동 스냅샷을 찍을 것입니다.

감사합니다. 정말 좋은 조언입니다. 다음에 재구축을 해야 하면 이렇게 진행하겠습니다.