ここ数週間、私のディスコースのインストールがどんどん遅くなっています。以前は、このようなことが起こったとき、アプリを再構築することで改善されました。しかし、今回は役に立たないようです。
このフォーラムでアドバイスを探し、いくつかのデータベース最適化（vacuum full verbose, rebuild index, vacuum analyze verbose）を試しました。
しかし、どれも効果がないようで、コンテナを起動すると、フォーラムに実際に接続できるようになるまで非常に長い時間がかかります。
このままでは、フォーラムは最終的に完全に使い物にならなくなってしまいます。どこから探し始めればよいか、何かアイデアはありますか？
データベースのサイズはどのくらいですか？ RAMはどのくらい搭載されていますか？
ここで役立つのは、
vmstat 5 5
の出力です。（問題が発生している時に実行してください！）
利用可能なメモリ：（topより）
iB Mem : 4041756 total, 108980 free, 3834244 used, 98532 buff/cache
KiB Swap: 1949692 total, 972196 free, 977496 used. 31140 avail Mem
Vmstat の出力：（読み込み中に非常に遅くなっています）
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st\n 9 2 1011424 108300 15308 122392 37 32 145 101 0 0 2 3 93 1 0\n 5 2 1028312 114696 9976 101252 2104 3904 2176 3915 340 1939 41 38 1 19 0\n 2 4 1054116 115892 10196 102260 1378 6803 4171 6826 870 1812 23 28 1 48 0\n 0 4 1011420 257496 10860 108464 3427 3937 6223 3969 829 2788 15 28 2 55 0\n 6 2 1001844 154328 12988 120800 4366 124 7166 161 742 2947 14 26 2 58 0\nhubbe@tymin:~$ vmstat 5 5\nprocs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st\n 1 4 1004748 85768 13948 114648 37 32 145 101 0 0 2 3 93 1 0\n 0 6 1033260 108584 10212 101668 1566 6661 4368 6807 497 1990 11 27 0 61 0\n12 7 1050808 99524 10708 94852 1932 4551 4854 4625 660 2263 24 32 2 42 0\n 5 8 1078776 125060 9136 92948 2079 6963 5541 7030 771 2040 17 32 0 51 0\n 4 3 1004784 168216 10164 103420 2631 1457 4970 1467 617 2136 34 38 1 27 0\n```
PS：参考までに、私のサイトはこちらで利用可能です：https://crucible.hubbe.net/
[quote="Jay Pfaffman, post:2, topic:260501, username:pfaffman"]
データベースのサイズはどのくらいですか？
[/quote]
どうすれば確認できますか？そのサーバーにはDiscourseしかありませんか？ app.yml ファイルでユニコーンをいくつ設定しましたか？
それは唯一のものではありませんが、間違いなく最大のものです。
メモリ使用量別のトッププロセスは次のとおりです。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1818 hubbe 20 0 910068 159724 10272 S 0.0 4.0 0:31.17 ruby
6141 hubbe 25 5 1195492 140180 10080 S 4.2 3.5 11:31.61 ruby
1845 hubbe 20 0 908732 124036 9388 S 2.8 3.1 0:29.94 ruby
1780 hubbe 20 0 910076 82072 3796 S 0.0 2.0 0:28.40 ruby
1937 systemd+ 20 0 360060 25632 21076 S 0.0 0.6 0:00.86 postmaster
2134 systemd+ 20 0 356020 23608 19760 S 0.0 0.6 0:00.13 postmaster
1797 systemd+ 20 0 355840 22620 19404 S 1.4 0.6 0:00.75 postmaster
2092 systemd+ 20 0 356288 21644 17584 S 0.0 0.5 0:00.17 postmaster
2063 systemd+ 20 0 355984 18364 16504 S 0.0 0.5 0:00.20 postmaster
1939 systemd+ 20 0 355904 15668 15232 S 0.0 0.4 0:00.25 postmaster
2131 systemd+ 20 0 353948 14804 13000 S 0.0 0.4 0:00.02 postmaster
38770 root 20 0 689760 12940 0 S 0.0 0.3 434:00.34 dockerd
43876 root 20 0 16492 9428 1608 S 0.0 0.2 3:34.89 roxen
5728 hubbe 20 0 574796 8136 2064 S 0.0 0.2 0:58.94 ruby
37533 root 20 0 593420 5848 1020 S 2.8 0.1 539:40.11 containerd
5689 systemd+ 20 0 96432 5832 1672 S 0.0 0.1 3:54.43 redis-server
2196 www-data 20 0 166248 4924 2580 S 0.0 0.1 1:18.03 nginx
2197 www-data 20 0 165972 4484 3168 S 0.0 0.1 1:29.32 nginx
このリストのほとんどは、roxen を除いて、ディスコースに関連しています。
UNICORN_WORKERS は app.yml でコメントアウトされています
投稿の保存が特にタイムアウトして失敗しやすいようです。
それが何かの手がかりになるかはわかりませんが。
vmstat の出力は、現状では RAM が不足していることを示しています。
Discourse が正常に動作しており、すべてが順調であるにもかかわらず、データが 4G の RAM では不足するほど増加した可能性があります。
あるいは、何か問題が発生し、使用されるべきではない大量の RAM が使用されている可能性もあります。
サイズを測る方法の 1 つは、添付ファイルなしでバックアップを取得し、そのサイズを確認することです。
ミニプロファイラーが、どのデータベース アクションに時間がかかっているかについてのヒントを与える可能性があります。
RAM を倍増する予算がある場合は、そうしてください。(プロバイダーからそのようなオプションがある場合、RAM を増やしてもストレージはそのままにしておくように注意すれば、これは元に戻すことができ、一時的な変更にさえなる可能性があります。)
それが的を射ています。
RAMを増設できない場合は、一時的に db_shared_buffers の値を低く設定（例えば128MB以下）し、UNICORN_WORKERS を2に制限してみてください。スワップをできるだけ早く停止する必要があります。
62.5 MB
ホスティングプロバイダーのRAMはかなり高価なので、まず他の選択肢を探します。（そして、変更すると現在の価格設定が無効になるのではないかと心配しています…）
db_shared_buffers を 128MB に、UNICORN_WORKERS を 2 に変更しました。
これらの設定を有効にするには launcher app stop / start だけで十分ですか？
ミニプロファイラーとは何ですか？また、どのように使用しますか？
キーボードでAlt+Pを押すと、その後のフォーラムのアクションでフォーラムバナーのすぐ下にタイミング文字列が表示されます（私の場合、右側です）。タイミングをクリックすると、統計情報が表示されるポップアップウィンドウが表示されます。
私の環境でも、1GBのRAMで動作させていますが、ほぼ同じです。トピックは2000件、投稿は15000件、サインアップは500件以上あります。
Discourseの履歴について教えていただけますか？ 過去にパフォーマンス上の理由で特定のテーブルにインデックスを作成する必要があった時期があったような気がするのですが。
プラグインについてはどうですか？ セーフモードでアクションを実行して、より速く実行されるかどうかを確認できますか？
そのような統計情報を簡単に見つけられる場所はありますか？
私が目にする統計情報のほとんどは、過去1日または1週間の出来事を示していますが、合計は示されていません。
履歴について、どういう意味か分かりません。しかし、2021年3月に始めました。
最初の印象では、セーフモードは速くありません。それをミニプロファイラーといじって、その印象が続くかどうかを確認します。
ps auxf の出力は添付されています。
auxf.txt (20.1 KB)
/about ページに、歴代の列があります。
お使いのコンピューターは1年以上再起動されていないようです。再起動して、同時にセキュリティを更新することをお勧めします。再起動で改善する可能性は十分にあります。
サーバーはハイパーバイザーを使用するように設定されているようですが、私のサーバーはLXCを使用するように設定されています。それが重要かどうかはわかりません。（私のシステムでは /usr/bin/lcs というプロセスが表示されますが、あなたのシステムでは表示されず、あなたのシステムでは hv_vss_daemon というプロセスが表示されますが、私のシステムでは表示されません。）
また、df -T と swapon の出力を共有していただけますか。
1.3k トピック、24.7k ポスト、631 件のサインアップ、7.1k いいね
Linux マシンを再起動しても通常は何も改善しませんが、試してみることはできます。
これには懐疑的な態度で同意します！しかし、私はそれを軽々しく提案しているわけではありません。長時間稼働しているシステムが再起動で改善したケースを実際に見たことがあると確信しています。（編集：こちらですが、これは別のケースでした。）
投稿の保存について、ミニプロファイラーは次のように表示されました。
約30秒かかりました。