我的 discourse 安装在过去几周里变得越来越慢。过去出现这种情况时，重建应用程序会有所帮助。但是，现在似乎没有帮助了。
我一直在论坛上查找建议，并尝试了一些数据库优化（vacuum full verbose、rebuild index、vacuum analyze verbose）。
但是，这些似乎都没有帮助，当我启动容器时，需要很长时间才能真正连接到论坛。
如果这种情况持续下去，论坛最终将完全无法使用。有什么地方可以开始查找吗？
您的数据库有多大？您有多少内存？
1 个赞
这里可以提供以下命令的输出：
vmstat 5 5
（在问题发生时运行！）
2 个赞
可用内存：(来自 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```
附注：我的网站在这里，如果这对您有帮助：https://crucible.hubbe.net/
[quote="Jay Pfaffman, post:2, topic:260501, username:pfaffman"]
你的数据库有多大？
[/quote]
我该如何检查？
1 个赞
那个服务器上只有 Discourse 吗？你在 app.yml 文件中设置了多少个 unicorn？
2 个赞
这并非唯一的原因，但无疑是最主要的原因。
以下是内存使用率最高的进程：
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，都与 discourse 相关。
我的 app.yml 中注释掉了 UNICORN_WORKERS
保存帖子似乎特别容易超时和失败。
不确定这是否是任何关于正在发生的事情的线索。
vmstat 的输出告诉我们，目前内存不足。
可能是 Discourse 运行正常，一切都按部就班，但您的数据已增长到 4G 内存不足的程度。
也可能是出了什么问题，导致大量不应使用的内存被占用。
衡量规模的一个方法是进行一次不含附件的备份，看看它有多大。
mini-profiler 可能会为我们提供关于哪些数据库操作耗时过长的线索。
如果您有预算将内存翻倍，那就这样做。（如果您能从提供商那里选择增加内存但保持存储不变，那么这是一个可逆的甚至是临时的更改。）
5 个赞
你说得很对。
如果你无法购买更多内存，可以尝试将 db_shared_buffers 设置为较低的值（例如 128MB 或更低），并将 UNICORN_WORKERS 暂时限制为 2，因为你需要尽快停止交换。
3 个赞
62.5 MB
我的托管提供商提供的更多内存价格相当昂贵，所以我将首先探索其他选项。（我担心更改它会破坏我已获得优惠定价的资格……）
我将 db_shared_buffers 更改为 128Mb，将 UNICORN_WORKERS 更改为 2。
launcher app stop / start 是否足以使这些设置生效？
什么是迷你分析器，我该如何使用它？
1 个赞
在键盘上按 Alt+P，后续的论坛操作应该会在论坛横幅下方（对我来说是在右侧）显示一个计时字符串，点击计时字符串会弹出一个带有统计信息的窗口。
这和我差不多，我运行在 1G 内存上。我有 2k 个主题、15k 篇帖子、500 多次注册。
你的 Discourse 有什么历史记录？我隐约记得过去有一个时候，为了性能原因，应该为某个表创建一个索引。
插件呢？你能否在安全模式下运行操作，看看它们是否运行得更快？
2 个赞
1 个赞
有没有什么简单的方法可以找到这些统计数据？
我看到的大多数统计数据都显示了过去一天或一周发生的情况，但没有显示总数。
不确定你说的历史是什么意思。但我是在2021年3月开始使用的。
初步印象是安全模式并不更快。我会尝试使用它和mini-profiler看看这个印象是否成立。
ps auxf 的输出已附上。
auxf.txt (20.1 KB)
1 个赞
在 /about 页面上，有一列是“所有时间”。
看起来您的机器已经一年多没有重启了——可能值得这样做，同时进行安全更新。重启可能有助于解决问题。
1 个赞
我注意到您的服务器似乎配置为使用 hypervisor，而我的服务器配置为使用 lxc。我不知道这是否重要。（我的系统显示一个 /usr/bin/lxcfs 进程，而您的系统没有；您的系统显示一个 hv_vss_daemon 进程，而我的系统没有。）
另外，也许您可以分享 df -T 和 swapon 的输出。
1.3k 个主题，24.7k 篇帖子，631 次注册，7.1k 次点赞
重启 Linux 机器通常没什么帮助，但我猜我可以试试。
我同意这种怀疑的态度！但并非随意提出——我相当确定我们见过一个长期运行的系统在重启后有所改善的案例。（编辑：在此处，尽管那是另一个案例。）
这是 mini-profiler 在保存帖子时显示的内容：
耗时约 30 秒。