참고로, 방금 두 개의 포럼을 업데이트했는데, 두 경우 모두 일시적으로 RAM을 8GB로 늘렸다가 다시 원래대로 되돌린 상태였습니다. 두 경우 모두 경과 시간이 1시간 이내로 완료되었습니다. 이 특정 단계는 (일시적으로) 4개 CPU와 8GB RAM 환경에서 약 5분 정도 걸렸습니다.
I, [2024-01-10T16:07:58.323464 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile'
110:M 10 Jan 2024 16:08:52.047 * 100 changes in 300 seconds. Saving...
110:M 10 Jan 2024 16:08:52.048 * Background saving started by pid 3276
3276:C 10 Jan 2024 16:08:52.384 * DB saved on disk
3276:C 10 Jan 2024 16:08:52.386 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
110:M 10 Jan 2024 16:08:52.449 * Background saving terminated with success
Purging temp files
Bundling assets
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
I, [2024-01-10T16:12:14.362017 #3300] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
여기서 12번째 열에 있는 ember 프로세스가 6번째 열에 표시된 대로 2.5GB의 RAM을 사용하고 있으며, 3번째 열에 표시된 대로 CPU를 하나 이상 사용하고 있는 것을 볼 수 있습니다.
# ps auxfc|egrep -A29 containerd
root 1097 0.2 0.5 1510892 44924 ? Ssl 16:00 0:01 containerd
root 4507 0.1 0.0 717892 7556 ? Sl 16:03 0:00 \_ containerd-shim
root 4530 0.1 0.3 312292 30512 ? Ssl 16:03 0:00 \_ pups
systemd+ 4609 0.0 0.3 213236 28608 ? S 16:03 0:00 \_ postmaster
systemd+ 4617 0.0 0.8 213340 67288 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4618 0.0 0.0 213236 5876 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4619 0.0 0.1 213236 10076 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4620 0.0 0.1 213904 8860 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4621 0.0 0.0 68004 5592 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4622 0.0 0.0 213796 7100 ? Ss 16:03 0:00 | \_ postmaster
message+ 4682 0.2 0.4 87976 35724 ? Sl 16:03 0:00 \_ redis-server
1000 7722 1.1 0.0 0 0 ? Z 16:07 0:01 \_ esbuild <defunct>
root 7736 0.0 0.0 2476 520 ? S 16:07 0:00 \_ sh
root 7737 0.0 0.0 9296 4156 ? S 16:07 0:00 | \_ su
1000 7738 8.3 0.0 2476 580 ? Ss 16:07 0:12 | \_ sh
1000 7835 0.4 0.9 929524 78416 ? Sl 16:08 0:00 | \_ node
1000 7857 0.0 0.0 2484 524 ? S 16:08 0:00 | \_ sh
1000 7858 156 30.5 67413228 2491796 ? Sl 16:08 3:37 | \_ ember
1000 7876 39.0 1.7 11486300 145476 ? Ssl 16:08 0:44 | \_ node
1000 7882 36.7 1.5 11466956 122648 ? Ssl 16:08 0:41 | \_ node
1000 7889 37.1 4.1 11647592 340908 ? Ssl 16:08 0:42 | \_ node
1000 7761 1.5 0.0 0 0 ? Z 16:08 0:02 \_ esbuild <defunct>
제 경우에는 4GB RAM으로도 충분했을 것 같습니다. 하지만 언급했듯이 이 전체 작업은 몇 센트 정도의 비용에 불과했습니다. (이제 보니, 1센트 더 지불하면 더 빠른 CPU를 선택할 수 있었음을 알게 되었습니다.)
수정: 작업을 시작하기 전에 백업을 하나 하고, 작업이 완료된 후에도 백업을 하나 더 했습니다. 두 백업 사이의 간격은 35분이었습니다. 따라서 사용자가 체감한 다운타임은 그보다 길지 않았습니다.
수정: Digital Ocean 제어판에 따르면 리사이징 작업은 디스크의 데이터 용량 1GB당 최대 1분까지 걸릴 수 있다고 합니다. 제 경우 데이터가 14GB뿐이었고, 실제로는 리사이징마다 2분 정도 걸렸습니다. 하지만 인스턴스에 데이터가 매우 많다면, 이 리사이징 과정이 더 오래 걸릴 수 있습니다. (다시 말해, 데이터가 매우 많다면 아마도 4GB 미만의 RAM으로 실행하려 하지 않을 것입니다.)