私は小さなサーバー（RAM 1GB）と小さなサイト（公式のDiscourseインストールで8年近く稼働）を運営しています。望ましくないほどのディスクスワップが発生しているので、メモリ使用量を確認し始めました。
メモリ使用量を制限するため（そしてスワップを減らすため）、以前にユニコーンの数を2に設定したことに気づきました。Discourseのバージョンは 3.1.0 です。
しかし、htop を実行すると、20個のユニコーンが実行されていることがわかります（ワーカー0に10個、ワーカー1に10個）。
ここで何を見落としていますか？ app.yml では2と指定されているのに、なぜ20個のユニコーンが実行されているのでしょうか？
また、メモリ使用量を減らす他の方法はありますか？（例えば、db_shared_buffers を128MBに減らした場合の副作用はありますか？）Sidekiqのメモリ使用量を減らすことはできますか？
これは vmstat 5 5 の結果です。
free -h の結果です。
htop はスレッドではなくプロセスを表示していると思われます。いずれにしても、ps uaxf|egrep unicorn.?worker では 2 つのユニコーンしか表示されませんが、htop では表示されている内容はあなたと同じです。
また、私の free コマンドの結果もあなたと同じです。
# free -h
total used free shared buff/cache available
Mem: 985M 782M 61M 60M 141M 32M
Swap: 2.0G 992M 1.0G
ちなみに、スワップが使用されているのを見ても、それ自体は問題ではありません。問題となるのは実際のスワッピング（ページング）です。vmstat 5 5 を実行し、si と so の列を確認してみてください。
# vmstat 5 5
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 1041832 63176 5716 127408 367 325 601 393 8 10 2 1 95 2 0
0 0 1041576 60976 5724 127408 399 0 399 21 212 653 1 1 96 2 0
0 0 1043544 77036 2296 120688 807 803 807 837 404 1144 1 2 94 3 0
0 0 1043288 65040 3704 129476 254 0 2292 5 255 780 1 1 96 2 0
0 0 1048736 81936 2916 119016 762 1499 919 1565 470 1171 3 2 90 5 0
1000 を超える値はできれば見たくありませんが、それほど心配はしていません。2 回目の実行では、はるかに落ち着いた状況が見られました。
# vmstat 5 5
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 1048452 82712 2532 120848 367 325 601 393 8 10 2 1 95 2 0
0 0 1047684 74552 2548 124816 285 0 1049 10 230 655 2 1 95 2 0
0 0 1046660 66556 3692 129008 196 0 1261 16 219 672 1 1 96 2 0
1 0 1046404 65812 3700 129284 54 0 97 13 137 364 1 0 98 0 0
0 0 1046148 65280 3700 129288 50 0 50 3 132 344 1 0 98 0 0
編集: htop の H キーを押すと、スレッドとプロセスの表示を切り替えることができます。
CPU[ 0.0%] Tasks: 66; 1 running
Mem[||||||||||||||||||||||||||||||||||||||||||||||||||824M/985M] Load average: 0.19 0.12 0.05
Swp[|||||||||||||||||||||||||||||| 1015M/2.00G] Uptime: 52 days, 00:50:42
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
13246 1000 20 0 966M 362M 6448 S 0.0 36.8 51:01.52 unicorn worker[0] -E production -c config/unicorn.conf.rb
13237 1000 25 5 1004M 194M 3780 S 0.0 19.8 22:38.19 sidekiq 6.5.9 discourse [0 of 5 busy]
13258 1000 20 0 919M 70176 3632 S 0.0 7.0 5:02.87 unicorn worker[1] -E production -c config/unicorn.conf.rb
12412 systemd-r 20 0 212M 60928 56916 S 0.0 6.0 0:00.23 postgres: 13/main: discourse discourse [local] idle
12818 systemd-r 20 0 212M 39228 34868 S 0.0 3.9 0:00.07 postgres: 13/main: discourse discourse [local] idle
12719 systemd-r 20 0 211M 28400 25336 S 0.0 2.8 0:00.03 postgres: 13/main: discourse discourse [local] idle
13117 1000 20 0 541M 13768 2048 S 0.0 1.4 1:08.11 unicorn master -E production -c config/unicorn.conf.rb
編集: db_shared_buffers: "128MB" はかなり早い段階で設定しましたが、問題は発生していません。
ありがとうございます。大変参考になりました。ユニコーンワーカーを1つだけにする場合のデメリットは何でしょうか？応答時間は改善されるでしょうか、それとも悪化するでしょうか（ユニコーンワーカーは1つの着信接続にしか対応できないのでしょうか？つまり、2つのワーカーがあれば単一の着信接続の処理は速くなるのでしょうか？）、1分あたりの接続数がわずかであると仮定した場合です。
ウェブサイトを閲覧しているとき、vmstat 5 5 は次のようになります。スワッピングを減らすための提案はありますか（スワップネスを10に設定しました）？
編集：パフォーマンスに影響を与えることなく、Sidekiqのメモリ使用量を削減する方法はありますか？
RAMを増設すればサイトは確実に速くなるでしょう。しかし、応答時間が問題でなければ、問題ありません。ご自身のコスト/ベネフィットの計算式を見てみてください。
MKJの意見によるDiscourseデプロイメント設定を読むと興味深いかもしれません。システムレベルのカーネル調整がいくつかあり、それは良い考えです。それが違いを生むかどうかは分かりません。
分かりませんが、ユニコーンはそれぞれ1つのリクエストを処理できると思います。したがって、ユニコーンが1つしかなく、最初の処理が終わる前に2番目のリクエストが入ってくるほどのトラフィックがある場合、2番目のリクエストは待たなければなりません。htopの出力を見ると、1つのユニコーンが他のユニコーンの10倍のCPU時間を消費していることが分かります。これは、私のフォーラムが90％の時間でユニコーンが1つで済む必要があり、10％の時間で2番目のユニコーンが役立つことを意味すると考えられます。3つ目のユニコーンを追加する必要性を感じていませんし、1つに減らしてもフォーラムのメンバーには大きな影響はないかもしれません。しかし、減らす理由はありません。メモリを使用するかもしれませんが、アイドル状態であればスワップアウトされるでしょう。大したことではありません。仮想メモリシステムに任せましょう。
編集：swappinessを調整したことはありません。60のままのようです。より積極的なスワップが、I/Oバッファのためにメモリをより多く解放するのに役立つかもしれません。分かりません。
db_shared_buffers と UNICORN_WORKERS を変更した場合、./launcher rebuild app で再構築せずに再起動する方法はありますか？
