Discourse Docker에서 예약/사용된 하드웨어(CPU, RAM, 디스크) 및 관리 방법

[Crius]

이번 주말에 Discourse 설치 환경을 실행하는 VM에 외부 도구들(grafana, prometheus, 일부 exporters)과 분석 도구(matomo)를 설치하고, 외부 위치(AWS S3)에 백업을 설정하는 작업을 했습니다. 마이그레이션을 완료한 지 두 달이 지났고, 마침 여유 시간이 나서 작업을 진행했습니다.

몇 일간의 지표 데이터가 축적되기를 기다린 후 다시 확인해 보니, cadvisor에 따르면 discourse를 실행하는 컨테이너가 사용 가능한 RAM의 거의 전부를 차지하고 있었습니다:

다른 출처로 확인해 보니 그렇게 보이지 않아서 의아했지만, 더 잘 이해해야 할 부분이 몇 가지 있다는 것도 알게 되었습니다.

예를 들어 CPU 사용량은 스파이크가 발생하지만, 거의 대부분의 시간 동안 평균적으로 100%를 훨씬 초과하는 수준을 유지하고 있습니다:

하지만 Docker Stats의 출력은 다음과 같습니다:

CONTAINER ID   NAME                    CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O        PIDS
254d80933447   grafana                 0.02%     83.34MiB / 29.38GiB   0.28%     4.2MB / 10.1MB    88.2MB / 13MB    14
78d8a523c667   prometheus              0.00%     114.6MiB / 29.38GiB   0.38%     741MB / 50.7MB    190MB / 201MB    14
d602e2724c7a   cadvisor                1.48%     67.52MiB / 29.38GiB   0.22%     12.3MB / 691MB    166MB / 4.08MB   24
4718b3629c8e   docker_state_exporter   0.00%     11.54MiB / 29.38GiB   0.04%     2.85MB / 38.8MB   2.7MB / 90.1kB   14
c5a211185855   app                     337.52%   7.543GiB / 29.38GiB   25.67%    365MB / 883MB     360GB / 67.3GB   282
9b95fa3156bb   matomo_cron             0.00%     7.504MiB / 29.38GiB   0.02%     1.48kB / 0B       762MB / 0B       3
553a3e7389eb   matomo_web              0.11%     9.832MiB / 29.38GiB   0.03%     106MB / 203MB     8.89MB / 33MB    9
adf21bdea1e5   matomo_app              0.01%     113.3MiB / 29.38GiB   0.38%     166MB / 146MB     1.26GB / 153MB   4
96d873027990   matomo_db               0.03%     99.66MiB / 29.38GiB   0.33%     63.8MB / 126MB    118MB / 310MB    15
9d21fdde2ec9   node_exporter           0.00%     9.887MiB / 29.38GiB   0.03%     3MB / 48.9MB      10.5MB / 299kB   6

이 포럼을 찾아보면서 unicorn 프로세스 수를 자동 감지 값(8)에서 4로 줄이는 것을 시도해 보았지만, 사용된 CPU/메모리 측면에서 의미 있는 변화는 보이지 않습니다.

마지막으로, vbulletin3에서 discourse로 DB를 가져올 당시 데이터베이스 자체는 약 7GB였습니다. 오늘 확인해 보니 10배 이상으로 증가했습니다.

du -sh /var/discourse/shared/standalone/* | sort -hr | head -n 10
70G     /var/discourse/shared/standalone/postgres_data
1.6G    /var/discourse/shared/standalone/uploads
807M    /var/discourse/shared/standalone/log
69M     /var/discourse/shared/standalone/redis_data
200K    /var/discourse/shared/standalone/postgres_run
28K     /var/discourse/shared/standalone/state
12K     /var/discourse/shared/standalone/tmp
12K     /var/discourse/shared/standalone/ssl
8.0K    /var/discourse/shared/standalone/backups
4.0K    /var/discourse/shared/standalone/postgres_backup

이것은 postgresql이 백그라운드에서 작업을 수행하며 추가 데이터를 많이 생성하는 것 같지만, 이를 적어도 통제할 수 있는 방법이 있을까요?

도움이 될 수 있을지 모르지만 Discourse Doctor의 출력입니다:

DISCOURSE DOCTOR Mon May 15 09:44:17 AM CEST 2023
OS: Linux vmi1229594.OMITTED.net 5.15.0-67-generic #74-Ubuntu SMP Wed Feb 22 14:14:39 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux


Found containers/app.yml

==================== YML SETTINGS ====================
DISCOURSE_HOSTNAME=OMITTED
SMTP_ADDRESS=OMITTED
DEVELOPER_EMAILS=OMITTED
SMTP_PASSWORD=OMITTED
SMTP_PORT=OMITTED
SMTP_USER_NAME=OMITTED
LETSENCRYPT_ACCOUNT_EMAIL=OMITTED

==================== DOCKER INFO ====================
DOCKER VERSION: Docker version 23.0.1, build a5ee5b1

DOCKER PROCESSES (docker ps -a)

CONTAINER ID   IMAGE                                     COMMAND                  CREATED        STATUS                 PORTS                                      NAMES
254d80933447   grafana/grafana:latest                    "/run.sh"                8 hours ago    Up 7 hours             0.0.0.0:8443->3000/tcp                     grafana
78d8a523c667   prom/prometheus:latest                    "/bin/prometheus --c…"   8 hours ago    Up 8 hours             0.0.0.0:9090->9090/tcp                     prometheus
d602e2724c7a   gcr.io/cadvisor/cadvisor:latest           "/usr/bin/cadvisor -…"   8 hours ago    Up 8 hours (healthy)                                              cadvisor
4718b3629c8e   karugaru/docker_state_exporter            "/go/bin/docker_stat…"   8 hours ago    Up 8 hours                                                        docker_state_exporter
c5a211185855   local_discourse/app                       "/sbin/boot"             9 hours ago    Up 7 hours             0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
9b95fa3156bb   matomo:fpm                                "bash -c 'bash -s <<…"   20 hours ago   Up 20 hours            9000/tcp                                   matomo_cron
553a3e7389eb   nginx:alpine                              "/docker-entrypoint.…"   21 hours ago   Up 21 hours            80/tcp, 0.0.0.0:2053->443/tcp              matomo_web
adf21bdea1e5   matomo:fpm-alpine                         "/entrypoint.sh php-…"   21 hours ago   Up 21 hours            9000/tcp                                   matomo_app
96d873027990   mariadb                                   "docker-entrypoint.s…"   21 hours ago   Up 21 hours            3306/tcp                                   matomo_db
9d21fdde2ec9   quay.io/prometheus/node-exporter:latest   "/bin/node_exporter …"   36 hours ago   Up 36 hours                                                       node_exporter

c5a211185855   local_discourse/app                       "/sbin/boot"             9 hours ago    Up 7 hours             0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
adf21bdea1e5   matomo:fpm-alpine                         "/entrypoint.sh php-…"   21 hours ago   Up 21 hours            9000/tcp                                   matomo_app

Discourse container app is running


==================== PLUGINS ====================
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-spoiler-alert.git
          - git clone https://github.com/discourse/discourse-animated-avatars.git
          - git clone https://github.com/discourse/discourse-whos-online.git
          - git clone https://github.com/discourse/discourse-bbcode.git
          - git clone https://github.com/discourse/discourse-signatures.git
          - git clone https://github.com/discourse/discourse-reactions.git
          - git clone https://github.com/paviliondev/discourse-legal-tools.git
          - git clone https://github.com/discourse/discourse-patreon.git
          - git clone https://github.com/discourse/discourse-yearly-review.git
          - git clone https://github.com/discourse/discourse-user-notes.git
          - git clone https://github.com/merefield/discourse-user-network-vis.git
          - git clone https://github.com/discourse/discourse-calendar.git
          - git clone https://github.com/discourse/discourse-prometheus.git

WARNING:
You have what appear to be non-official plugins.
If you are having trouble, you should disable them and try rebuilding again.

See https://github.com/discourse/discourse/blob/main/lib/plugin/metadata.rb for the official list.

========================================
Discourse 3.1.0.beta4
Discourse version at OMITTED: Discourse 3.1.0.beta4
Discourse version at localhost: Discourse 3.1.0.beta4


==================== MEMORY INFORMATION ====================
RAM (MB): 31550

               total        used        free      shared  buff/cache   available
Mem:           30088        3958        1307        4269       24823       21475
Swap:           8191        1140        7051

==================== DISK SPACE CHECK ====================
---------- OS Disk Space ----------
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       194G   93G   91G  51% /

---------- Container Disk Space ----------
Filesystem      Size  Used Avail Use% Mounted on
overlay         194G   93G   91G  51% /
/dev/sda3       194G   93G   91G  51% /shared
/dev/sda3       194G   93G   91G  51% /var/log

==================== DISK INFORMATION ====================
Disk /dev/sda: 200 GiB, 214748364800 bytes, 419430400 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: OMITTED

Device       Start       End   Sectors  Size Type
/dev/sda1     2048      4095      2048    1M BIOS boot
/dev/sda2     4096   4194303   4190208    2G Linux filesystem
/dev/sda3  4194304 419428351 415234048  198G Linux filesystem

==================== END DISK INFORMATION ====================

==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Or just send a test message to yourself.
Email address for mail test? ('n' to skip) [OMITTED]: n
Mail test skipped.
Replacing: SMTP_PASSWORD
Replacing: LETSENCRYPT_ACCOUNT_EMAIL
Replacing: DEVELOPER_EMAILS
Replacing: DISCOURSE_DB_PASSWORD
Replacing: Sending mail to

==================== DONE! ====================

[Crius]

@JammyDodger 감사합니다. Support 채널에 있었다는 걸 못 알아챘네요

[Ed_S]

간단히 말하면 다음과 같습니다.

• CPU 사용률이 모든 코어를 포화 상태로 만들지 않는 한 걱정할 필요는 없습니다.
• RAM 사용량보다는 스왑 활동에 신경 쓰세요.
• 데이터베이스 크기가 10배로 증가했다는 새로운 스레드를 여는 것이 좋습니다.

시스템에서 스왑 활동 메트릭을 제공한다면 이를 사용하세요. 제공하지 않는 경우, 스왑 공간을 가진 디바이스의 디스크 활동을 확인해 보세요.

[Crius]

네, 알겠습니다. RAM 용량이 많으면 SWAP에 대해 너무 걱정하지 않아도 된다는 이야기를 여기저기서 많이 읽었기 때문에, 만약 문제가 생겼을 때 완전히 안전망이 없지는 않도록 8GB 정도를 설정해 두었습니다. 이렇게 설명하면 이해가 되실까요?

SWAP 활동과 관련하여 어떤 부분을 주의 깊게 살펴봐야 하는지 좀 더 자세히 설명해 주실 수 있을까요?

대시보드에서 SWAP 관련해서 찾을 수 있는 정보는 다음과 같습니다:

그리고 전체 메모리 스택은 이렇습니다:

업무상 컨테이너와 k8s를 다루는 데 익숙해서, VM 레벨에서의 이러한 세부 사항들이 무엇을 주시해야 하는지에 대해서는 잘 모르겠습니다.

만약 초보자를 위한 링크 몇 개만 공유해 주셔도 되고, 여기서 긴 글을 쓰는 것이 번거롭거나 시간이 없으시다면 그것도 감사히 받겠습니다

[Ed_S]

이미지를 보내주셔서 감사합니다. 대부분은 상단의 '초당 페이지 수(pages per second)'를 모니터링하시면 됩니다. 지속적인 활동이 관찰되면 더 많은 메모리가 필요합니다. 이미지에서 보시는 것과 같은 짧은 스파이크는 문제없습니다. 현재 최대치가 1000 미만이고 시스템이 정상 상태라고 가정한다면, 초당 500페이지를 초과하는 지속적인 활동을 감시하시면 됩니다.

기본적으로 RAM은 빠르고 스왑은 느립니다. 운영체제는 가능한 한 RAM을 최대한 활용하며, 이것이 '사용되지 않는 RAM’을 측정하거나 파악하기 어려운 이유입니다. 사용자의 경우, 큰 빨간 비율은 디스크 콘텐츠를 캐시하는 데 사용되는 RAM으로, 이는 애플리케이션 성능 향상에 도움이 됩니다. 이 비율이 4분의 3 이상으로 증가한다면 우려할 만합니다. 일부 워크로드의 경우, 2분의 1을 초과하는 것만으로도 우려할 수 있습니다.

하지만 실제로 성능에 치명적인 영향을 미치는 것은 스왑 활동입니다. 스왑은 느리기 때문입니다. 스왑 사용량의 정적(고정된) 수준은 중요하지 않습니다. 그것은 맨 위쪽, 보라색 부분입니다. 사용자의 경우, 최대 스왑 사용량은 8G 대비 2G 미만으로, 충분한 여유가 있습니다. 최대 스왑 사용량이 사용 가능한 스왑 공간에 가까워지면 시스템 충돌이 임박할 수 있습니다. 그렇지 않다면 걱정할 필요가 없습니다.

따라서 지속적인 스왑 활동이나, 녹색으로 표시된 애플리케이션 사용량에 의해 빨간색 디스크 캐시가 압축되는 현상을 감시하세요.

[Crius]

에드, 자세한 설명 정말 감사드립니다. 정말 많이 도움이 되었어요. 나중에 알림 기능으로 직접 실험해 볼 예정이니, 정말 유용한 정보였어요