数週間前のある時点から、おそらくDiscourseのアップデート後、サイトの動作が少し遅くなったことに気づきました。現在、3.4.0.beta2-devを実行しています。
サーバーインスタンスの空きメモリがほとんどないことに気づいたため、再起動しました。Discourse起動直後はメモリ使用量は正常（約1.2 GB）でしたが、徐々に増加し始め、再び動作が遅くなるレベルに達しそうです。
サイトはそれほど混雑しておらず（1日20～30人の訪問者）、長年問題なく動作していましたが、最近になってこの状況になりました。
サーバーインスタンスのメモリは2 GBで、確認した要件（最低1 GB、推奨2 GB）を満たしているはずです。
これはメモリリークのように感じられます。もちろん、リークがある場合、DiscourseではなくDockerや他の何かが原因である可能性もあります。このインスタンスはDiscourse専用です。
何かアイデアはありますか？リークかどうかを確認する方法や、リークしているプロセスを特定する方法はありますか？
空きメモリは非常に掴みどころのない概念です。メモリ不足の確実な兆候は、ページングアクティビティです。
free
または
free -h
でスナップショットを取得できます。
vmstat 5 5
は、ページングアクティビティを含む、状況を確認するのに非常に役立ちます。
total used free
Mem: 1.9Gi 1.5Gi 73Mi
Swap: 2.0Gi 54Mi 1.9Gi
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 55524 111624 20080 385060 1 3 68 52 965 349 4 2 93 1 0
0 0 55524 114884 20088 385152 0 0 13 8 1047 352 2 1 96 0 0
0 0 55524 112428 20088 385160 0 0 0 3 831 319 3 1 95 0 0
0 0 55524 111616 20096 385164 0 0 0 51 688 278 2 0 97 0 0
0 0 55524 109884 20104 385168 0 0 0 8 1117 281 2 1 96 0 1
上記に問題はありますか？HTOPからメモリ使用量を確認しており、FREEと一致しているようです。
私の主な懸念は、メモリ使用量が常に増加していることです。ある時点まで増加し、その後はサイトの使用状況に応じて上下しながらその周辺で推移すると予想していました。着実に増加傾向にあるのは懸念事項です。
現時点では問題ありません。SIとSO（ページング）のアクティビティはなく、ディスクトラフィック（BIとBO）も非常に少ないです。
Linuxはディスクキャッシュに空きメモリを使用するため、空きメモリが少なくなるのは悪いことではありません。freeコマンドの出力は利用可能なRAMを示しており、manページには次のように記載されています。
available
スワップなしで新しいアプリケーションを開始するために利用可能なメモリの見積もり。
vmstatの場合、buffとcacheの列はディスクキャッシュに使用されるメモリであり、I/Oパフォーマンスを向上させるために増加する可能性がありますが、メモリプレッシャーがある場合は縮小します。したがって、freeとvmstatの両方で、「free」の量は悲観的な測定値です。
わかりました、ありがとうございます。おそらく、応答の遅さはメモリ不足のように見えた状況とは無関係でした。引き続き監視します。
徐々に大きくなっている可能性もまだあります。
これは、状況を確認するための私の戦術の1つです。
# ps aux|sort -n +5|tail
systemd+ 1659 0.0 1.3 904384 54588 ? S 16:44 0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
root 830 0.0 1.6 2253324 65208 ? Ssl 16:44 0:01 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
systemd+ 1682 0.0 1.9 904516 78092 ? Ss 16:44 0:01 postgres: 13/main: checkpointer
systemd+ 18757 0.1 2.1 912368 85644 ? Ss 18:06 0:00 postgres: 13/main: discourse discourse [local] idle
1000 1688 0.1 6.5 1006548 256428 ? Sl 16:44 0:10 unicorn master -E production -c config/unicorn.conf.rb
1000 2189 0.1 8.5 5657760 333248 ? Sl 16:45 0:06 unicorn worker[3] -E production -c config/unicorn.conf.rb
1000 2113 0.1 8.5 5656608 334352 ? Sl 16:45 0:07 unicorn worker[2] -E production -c config/unicorn.conf.rb
1000 2044 0.4 8.7 6052196 342380 ? Sl 16:44 0:23 unicorn worker[1] -E production -c config/unicorn.conf.rb
1000 2006 1.7 9.0 5628640 352492 ? Sl 16:44 1:33 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000 1971 3.1 11.1 6033652 435388 ? SNl 16:44 2:54 sidekiq 6.5.12 discourse [0 of 5 busy]
（または ps auxc）
CPUと（ディスク）I/Oアクティビティを監視するのが簡単であれば、メモリ使用量ではなく、それらを監視することをお勧めします。特にI/Oです。CPUが低くI/Oが高い場合、フォーラムが遅い場合は、RAMの深刻な不足を示している可能性があります。
サイトが遅くなる原因はバグ以外にもいくつか考えられます。一つは、ユーザー数、ユーザーアクティビティ、データベースサイズの徐々な増加です。もう一つは、Discourseが開発を進め、機能を追加し、ソフトウェアコンポーネントを更新するにつれて、ますます大きくなることです。
しかし、応答性を監視し、現在のマシンが適切なサイズであるかどうかを確認することは価値があります。
（ちなみに、Hetznerの最も安価なマシンは現在4G RAMを搭載しており、価格は現在入手できない2G RAMを搭載した最も安価なマシンと同じです。私のサイトの一つはまだ古い2Gサイズで稼働しています。）
記録として、メインサイトの利用状況を追跡してきたので、最近移行され、サーバーが新しく再起動されたばかりなので、いくつかの調査結果を含めます。かなりの量のデータなので、自由に研究してください！
マシンの現在の状態は次のとおりです。
# uptime
13:55:23 up 4 days, 21:10, 1 user, load average: 0.07, 0.08, 0.02
# free
total used free shared buff/cache available
Mem: 3905344 1638012 98492 481864 2168840 1595004
Swap: 4194288 252928 3941360
ログイン時にマシンが次のように表示されることに気づきました。
Memory usage: 45%
これは、「used」列を最もよく反映しており、「free」列ではありません。
以下のコマンドから定期的に読み取りを行っていました。
date
uptime
free
ps aux|sort -n +5|tail
vmstat 5 5
そして、「free」メモリが「buffer」と「cache」メモリと交換されているのを見ましたが、プロセスごとのRAMフットプリント（RSS）は増加していません。これは、「free」メモリを追跡するのがなぜそれほど良くないのかを示していると思います。ホスティングプロバイダーによってはこれを簡単にしていますが。この場合、メモリリークがないことも示していると思います。
再起動直後に次のように表示されます。
# free
total used free shared buff/cache available
Mem: 3905344 1560508 996400 179712 1348436 1974692
Swap: 4194288 0 4194288
そしてしばらくすると
# ps aux|sort -n +5|tail
...
1000 1688 0.1 6.5 1006548 256428 ? Sl 16:44 0:10 unicorn master -E production -c config/unicorn.conf.rb
1000 2189 0.1 8.5 5657760 333248 ? Sl 16:45 0:06 unicorn worker[3] -E production -c config/unicorn.conf.rb
1000 2113 0.1 8.5 5656608 334352 ? Sl 16:45 0:07 unicorn worker[2] -E production -c config/unicorn.conf.rb
1000 2044 0.4 8.7 6052196 342380 ? Sl 16:44 0:23 unicorn worker[1] -E production -c config/unicorn.conf.rb
1000 2006 1.7 9.0 5628640 352492 ? Sl 16:44 1:33 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000 1971 3.1 11.1 6033652 435388 ? SNl 16:44 2:54 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st
...
0 0 0 866112 314288 1083816 0 0 32 28 484 621 4 1 95 0 0
sidekiq（435MB）とユニコーン（それぞれ330〜350MB）が最大のプロセスであることがわかります。
時間とともに、free RAM、そしてsidekiq RAM（RSS）の使用量が減少し、おそらくページアウトされたためですが、過度の影響はありません。マシンにはページングアクティビティが表示されていません。バッファとキャッシュスペースの増加に有利だと思います。
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st
...
0 0 0 679764 326988 1190840 0 0 0 11 285 396 1 1 98 0 0
約14時間後：
# uptime
10:12:06 up 17:27, 1 user, load average: 0.04, 0.02, 0.00
# ps aux|sort -n +5|tail
...
1000 2006 1.2 9.6 5647908 377424 ? Sl Sep05 12:42 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000 1971 1.8 11.3 6431988 444184 ? SNl Sep05 18:51 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st
...
0 0 2048 199972 342480 1576156 0 0 0 17 361 511 2 2 96 0 0
その後…
# uptime
19:52:00 up 1 day, 3:07, 1 user, load average: 0.02, 0.06, 0.01
# ps aux|sort -n +5|tail
...
1000 2006 1.2 9.8 5654308 382944 ? Sl Sep05 20:44 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000 1971 1.5 11.1 6431668 436340 ? SNl Sep05 25:04 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st
...
0 0 2304 103356 301632 1690136 0 0 0 10 360 511 1 1 98 0 0
その後…
# uptime
12:13:09 up 1 day, 19:28, 2 users, load average: 0.05, 0.06, 0.01
# ps aux|sort -n +5|tail
...
1000 2006 1.2 9.1 5654820 358612 ? Sl Sep05 31:47 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000 1971 1.3 10.0 6431668 393584 ? SNl Sep05 35:08 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st
...
0 0 284416 281596 77904 1908528 0 0 0 38 315 450 1 1 98 0 0
その後
# uptime
13:26:42 up 2 days, 20:42, 1 user, load average: 0.20, 0.06, 0.02
# ps aux|sort -n +5|tail
...
1000 2006 1.2 9.3 5789072 365720 ? Sl Sep05 51:54 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000 1971 1.2 10.0 6433332 393472 ? SNl Sep05 50:44 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st
...
0 0 242944 82016 95188 2082180 0 0 0 131 332 488 1 1 98 0 0
その後
# uptime
09:21:33 up 3 days, 16:36, 1 user, load average: 0.13, 0.10, 0.03
# free
total used free shared buff/cache available
Mem: 3905344 1618936 323032 476664 1963376 1619208
Swap: 4194288 250112 3944176
# ps aux|sort -n +5|tail
...
1000 2006 1.2 9.3 5789200 363572 ? Sl Sep05 67:02 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000 1971 1.1 9.6 6433652 377472 ? SNl Sep05 63:14 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st
...
0 0 250112 321888 56052 1906672 0 0 2 13 293 420 1 0 99 0 0
その後
# uptime
13:55:23 up 4 days, 21:10, 1 user, load average: 0.07, 0.08, 0.02
# free
total used free shared buff/cache available
Mem: 3905344 1638012 98492 481864 2168840 1595004
Swap: 4194288 252928 3941360
# ps aux|sort -n +5|tail
...
1000 1971 1.1 9.5 6434676 371648 ? SNl Sep05 80:49 sidekiq 6.5.12 discourse [0 of 5 busy]
1000 2006 1.2 9.5 5658468 373404 ? Sl Sep05 88:44 unicorn worker[0] -E production -c config/unicorn.conf.rb
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st
...
1 0 252928 101040 86736 2082372 0 0 0 10 333 482 1 0 99 0 0
ご意見ありがとうございます。私も同様の状況を確認していますが、2GBのインスタンスを使用しているため、余裕が少なくなっています。また、「空き」と「使用済み」メモリの測定値が必ずしも役立つわけではないことをご指摘いただきありがとうございます。
数日前にインスタンスを最後に再起動したとき、初期メモリ使用量は1.23GBでした。それ以来、徐々に増加し、現在は1.8GBになっています。今のところ、サイトは比較的応答性があります。
サイトには実際には多くのユーザーがおらず、最近のユーザー登録やアクティビティの増加もありません。過去1か月で、約20の新しいトピック、約100の投稿、および約4人の毎日のアクティブユーザーがありました。
引き続き監視し、インスタンスのメモリが再び最大になるか、サイトが再び遅くなるか、またはその両方が発生した場合は、ここに投稿します。
メモリの問題でDiscourseのアップグレードが手間になってきていたため、ついに仮想マシンを2GBから4GBにアップグレードしました。それ以来、メモリ使用量は安定しています。