# Discourse DockerのHW予約/使用量（CPU、RAM、ディスク）と管理方法

**URL:** https://meta.discourse.org/t/discourse-docker-hw-reserved-used-cpu-ram-disk-and-how-to-manage-it/265010
**Category:** Self-hosting
**Tags:** server-resources
**Created:** [2023 年 5 月 15 日午前 8:11 UTC](https://meta.discourse.org/t/discourse-docker-hw-reserved-used-cpu-ram-disk-and-how-to-manage-it/265010 "2023-05-15T08:11:39Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![Crius](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/crius/32/317214_2.png) [@Crius](https://meta.discourse.org/u/Crius)
#### Post date: [2023 年 5 月 15 日午前 8:11 UTC](https://meta.discourse.org/t/discourse-docker-hw-reserved-used-cpu-ram-disk-and-how-to-manage-it/265010/1 "2023-05-15T08:11:39Z")

</div>

この週末を利用して、Discourseのインストールを実行しているVMに外部ツール（grafana、prometheus、一部のエクスポーター）や分析ツール（matomo）をインストールし、バックアップを外部の場所（AWS S3）に設定しました。移行から2ヶ月経ち、ようやく手が空いたので実施しました。

数日間、メトリクスなどが蓄積されるのを待ってから確認したところ、cadvisorによると、Discourseを実行しているコンテナが利用可能なRAMのほぼすべてを消費していることに気づきました。

 ![image](https://global.discourse-cdn.com/meta/original/4X/4/6/e/46e93bc86a77528675e2795e59155f73f0a3d0a7.png)

これは他のソースで確認するとそうではないように見えるため奇妙ですが、他の側面でまだ理解を深めたい点がいくつかあることに気づきました。

例えば、CPU使用率はスパイクがありますが、平均すると常に100%をはるかに超えたまま推移する傾向があります。

 ![image](https://global.discourse-cdn.com/meta/original/4X/6/b/f/6bf1f3363dfd1ba1857a87b2380d74570d54830e.png)

しかし、Docker Statsの出力は以下の通りです。

```plaintext
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

```

このフォーラムで読んだ情報をもとに、ユニコーンプロセスの数を自動検出の8から4に減らしてみましたが、CPU/メモリ使用量に顕著な変化は見られませんでした。

最後に、vbulletin3からDiscourseにデータベースをインポートしたときは、データベース自体は約7GBでした。今日確認したところ、10倍に増加していました。

```plaintext
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の出力を以下に示します。

```plaintext
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! ====================

```

---

<div class="post-metadata">

### Author: ![Crius](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/crius/32/317214_2.png) [@Crius](https://meta.discourse.org/u/Crius)
#### Post date: [2023 年 5 月 15 日午前 8:29 UTC](https://meta.discourse.org/t/discourse-docker-hw-reserved-used-cpu-ram-disk-and-how-to-manage-it/265010/2 "2023-05-15T08:29:17Z")

</div>

@JammyDodgerさん、ありがとうございます。#Support にいることに気づきませんでした :+1:

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [2023 年 5 月 15 日午後 1:13 UTC](https://meta.discourse.org/t/discourse-docker-hw-reserved-used-cpu-ram-disk-and-how-to-manage-it/265010/3 "2023-05-15T13:13:46Z")

</div>

要約すると、次のようになります。

- CPU使用率は、すべてのコアが飽和しない限り、心配しないでください。
- RAM使用量は心配しないで、代わりにスワップアクティビティを心配してください。
- DBサイズが10倍に増加したことについて、新しいスレッドを開始するのが良いでしょう。

システムがスワップアクティビティメトリクスを提供している場合は、それを使用してください。提供していない場合は、スワップスペースを保持しているデバイスのディスクアクティビティを確認してください。

---

<div class="post-metadata">

### Author: ![Crius](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/crius/32/317214_2.png) [@Crius](https://meta.discourse.org/u/Crius)
#### Post date: [2023 年 5 月 16 日午前 8:34 UTC](https://meta.discourse.org/t/discourse-docker-hw-reserved-used-cpu-ram-disk-and-how-to-manage-it/265010/4 "2023-05-16T08:34:06Z")

</div>

なるほど、RAMが多い場合はSWAPをあまり心配しないようにと聞いていたので、念のため8GB作成しました。

SWAPアクティビティに関して、どのような点に注意すべきか、もう少し詳しく教えていただけますか？

ダッシュボードで見つけたSWAP関連の情報は以下の通りです。

 ![image](https://global.discourse-cdn.com/meta/original/4X/9/6/0/9609efdcf073aa1a55e710b0b917062a8dfe855c.png)

そして、メモリスタック全体は以下の通りです。

 ![image](https://global.discourse-cdn.com/meta/original/4X/b/9/8/b9866b03d88b00dba1c4aca73485cbb6a1e7325b.png)

仕事でコンテナ/k8sを扱うことに慣れているため、VMレベルの詳細については、何に注意すべきか分かりません。

もし、入門レベルのリンクがあれば、ここで長文を書く時間がない場合でも、それでもありがたいです :slight_smile:

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [2023 年 5 月 16 日午前 8:54 UTC](https://meta.discourse.org/t/discourse-docker-hw-reserved-used-cpu-ram-disk-and-how-to-manage-it/265010/5 "2023-05-16T08:54:33Z")

</div>

画像ありがとうございます。主に上の「1秒あたりのページ数」を監視してください。持続的なアクティビティが見られる場合は、メモリを増やす必要があります。あなたの画像に見られるような一時的なスパイクは問題ありません。最大値は1000未満であり、おそらくシステムは正常です。したがって、1秒あたり500ページを超える持続的なアクティビティに注意してください。

基本的に、RAMは高速で、スワップは低速です。オペレーティングシステムはRAMを可能な限り使用します。そのため、「未使用のRAM」を測定したり考えたりするのは簡単ではありません。あなたのケースでは、大きな赤い部分はディスクの内容をキャッシュするために使用されているRAMであり、アプリケーションのパフォーマンスを向上させます。もし緑色の部分が4分の3以上になったら、それは懸念事項です。ワークロードによっては、半分以上が懸念事項になるかもしれません。

しかし、パフォーマンスを本当に低下させるのはスワップアクティビティです。スワップは低速だからです。ある程度のスワップ使用量は重要ではありません。それは一番上の部分、紫色の部分です。あなたのケースでは、最大スワップ使用量は8Gに対して2G未満であり、十分な容量があります。最大スワップ使用量が利用可能なスワップスペースの量に近づくと、システムクラッシュが差し迫っている可能性があります。それ以外の場合は、心配ありません。

したがって、持続的なスワップアクティビティ、または緑色のアプリケーション使用によって赤いディスクキャッシュが圧迫されることに注意してください。

---

<div class="post-metadata">

### Author: ![Crius](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/crius/32/317214_2.png) [@Crius](https://meta.discourse.org/u/Crius)
#### Post date: [2023 年 5 月 16 日午前 10:43 UTC](https://meta.discourse.org/t/discourse-docker-hw-reserved-used-cpu-ram-disk-and-how-to-manage-it/265010/6 "2023-05-16T10:43:31Z")

</div>

Edさん、詳しいご説明をありがとうございました。大変参考になりました。後でアラートを試してみます :slight_smile:
