Discourseのインストールがどんどん遅くなっています

root@tymin:/var/discourse# swapon
名前      タイプ      サイズ 使用量 PRIO
/dev/dm-0 パーティション 1.9G   1G   -1
root@tymin:/var/discourse# df -T
ファイルシステム                タイプ     1K-ブロック     使用量   利用可能 使用% マウント位置
udev                      devtmpfs   2008928        0   2008928   0% /dev
tmpfs                     tmpfs       404176    41336    362840  11% /run
/dev/mapper/VolGroup-root ext4      59629100 50018424   6991008  88% /
tmpfs                     tmpfs      2020876        0   2020876   0% /dev/shm
tmpfs                     tmpfs         5120        0      5120   0% /run/lock
tmpfs                     tmpfs      2020876        0   2020876   0% /sys/fs/cgroup
/dev/sda1                 ext2        240972   226212      2319  99% /boot
tmpfs                     tmpfs       404172        0    404172   0% /run/user/1001
tmpfs                     tmpfs       404172        0    404172   0% /run/user/1000
/dev/loop0                btrfs     10485760  4250700   4424308  49% /chroot/compile
overlay                   overlay   59629100 50018424   6991008  88% /var/lib/docker/overlay2/4e9863e34f958e15f57c752fda2057b88f2aa03afaca82e0651f3aa23e56f795/merged
「いいね!」 1

どれくらいのトラフィックがありますか?あなたのフォーラムは、このような問題が発生するにはあまりにも小さいようです。

これは公式のインストールですか?どのようなVPSでフォーラムを実行していますか?

管理ページによると、過去30日間で50,000ページビューです。

そうだと思います。当時は見つけられた指示に従いました。
インストールをあまりカスタマイズしていません。

よくわかりません。cari.netの2コア4GBの仮想サーバーです。

nginx 1.10.3でフォーラムが稼働していますが、これは6年以上前のバージョンなので、何か怪しい点があるはずです。

それ以外にも、これまで見てきた中で最もパフォーマンスの低いDiscourseのインストールの一つであることは間違いありません。当社の独自のホスティングサービスを宣伝したいわけではありませんが、他のホストへの切り替えを検討したことはありますか?この規模とトラフィックのフォーラムであれば、たとえ非常に小さなサーバーであっても問題なく動作するはずです。

「いいね!」 1

共有していただいたミニプロファイラーの情報から学ぶことはたくさんあるはずです。現時点で際立っているのは1点だけです。下書き投稿が膨大な数になっていませんか??
/my/activity/drafts

どうやら3つの下書きがあるようです。

Debian 9 で動作しています。:slight_smile:

nginx は問題なく動作しているようです。私のサイト (https://fredrik.hubbe.net/) の他の部分は遅くありません。

しかし、どのような指標ででしょうか?
Discourse自体が大量のメモリ、IO、またはCPUを消費しているのでしょうか?(もしそうなら、なぜでしょうか?まだ何もしていませんが…)
それともシステムが遅いということでしょうか?もしそうなら、cari.netに相談できます。

そして、今晩遅くに再起動を試して、それが役立つかどうかを確認するつもりです。
約2年経ちましたが、そろそろ時期かもしれませんね。

ちょっと待ってください:

$ expr 0 `ps auxwww | tail +2 | awk '{ print " + " $6}'`
787952

すべてのプロセスの常駐合計が800MB未満の場合、残りのメモリは何をしているのでしょうか?

/proc/meminfo もあまり役に立たないようです:

root@tymin:/# cat /proc/meminfo
MemTotal:        4041756 kB
MemFree:          122852 kB
MemAvailable:      53388 kB
Buffers:           15300 kB
Cached:            87636 kB
SwapCached:       125192 kB
Active:           314348 kB
Inactive:         300988 kB
Active(anon):     270652 kB
Inactive(anon):   276288 kB
Active(file):      43696 kB
Inactive(file):    24700 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1949692 kB
SwapFree:         921348 kB
Dirty:               144 kB
Writeback:             0 kB
AnonPages:        484704 kB
Mapped:            72596 kB
Shmem:             34520 kB
Slab:             319792 kB
SReclaimable:      26836 kB
SUnreclaim:       292956 kB
KernelStack:        6272 kB
PageTables:        19484 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3970568 kB
Committed_AS:    4146996 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     4001728 kB
DirectMap2M:      192512 kB

たぶん、思っている以上に再起動が必要なのかもしれません… 2年間のカーネルメモリリーク?

「いいね!」 3

再起動したら、空きメモリが2GBになりました。
持つかどうかは様子見です。 :slight_smile:

「いいね!」 3

しばらく Discourse を使用していると、ハードディスクの空き容量が非常に大きくなっていることに気づくでしょう。

これは主に Docker Image の問題によるもので、アップグレードが増えるほど、より多くの容量が占有されます。

次のコマンドを実行します。

./launcher cleanup

これにより、Discourse が占有しているスペースをクリーンアップできます。

ディスク容量の使用には役立ちますが、残念ながらこのケースでは以下のようになります。

大量のスワップが発生しており、パフォーマンスが低下しています。

すべてがディスク待ちになっており、これは非常に悪い状態です。

「いいね!」 1

It’s not about not working ok, for me it was an indication that something might be out of date or is not a standard installation.

今のところ、再起動はうまくいっているようです。
まだ理由はよくわかりませんが。

再起動で改善したようで何よりです!

役に立つことが判明するかもしれません。私も、もっと小規模なシステムの情報を共有します。

しかし、パフォーマンスに影響を与える可能性のあるカーネル設定について考えてみましょう。透過的な巨大ページは有効になっていますか?私は無効にしています。

# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

アドバイスについては、MKJ’s Opinionated Discourse Deployment Configuration を参照してください!

以下は、正常に動作している、もっと小規模なシステムの meminfo です。

# cat /proc/meminfo
MemTotal:        1009140 kB
MemFree:           91888 kB
MemAvailable:      88692 kB
Buffers:            7644 kB
Cached:           137040 kB
SwapCached:       144884 kB
Active:           418972 kB
Inactive:         380324 kB
Active(anon):     345300 kB
Inactive(anon):   345852 kB
Active(file):      73672 kB
Inactive(file):    34472 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       2097144 kB
SwapFree:        1049764 kB
Dirty:               400 kB
Writeback:             0 kB
AnonPages:        620688 kB
Mapped:            67192 kB
Shmem:             36536 kB
Slab:              67768 kB
SReclaimable:      27832 kB
SUnreclaim:        39936 kB
KernelStack:        3804 kB
PageTables:        14968 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     2601712 kB
Committed_AS:    3784772 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      460652 kB
DirectMap2M:      587776 kB

これで一件落着としたいのですが。\n\n再起動で解決し、現在も問題なく動作しています。\nメモリリークの原因は不明ですが、状況が変わらない限り、年に一度程度再起動が必要になるでしょう。それは許容範囲内です。

「いいね!」 1

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.