大家好，希望得到一些帮助！
有人遇到过这种情况吗？
./launcher rebuild app 正在运行，进行到这一点就卡住了。
现在它在运行了，但速度非常慢。我已经通过自行安装的 DigitalOcean 虚拟机运行论坛 3 年了，但这是第一次出现这种情况，导致了大量的停机时间。有什么方法可以解决这个问题吗？是论坛上的图片问题还是其他原因？
请再打开一个 SSH 会话，尝试找出是哪个迁移出了问题？
类似 ps aux | grep postgres 的命令应该能显示它的开始。
1 个赞
我不是 Linux 专家（坦白说，甚至连业余爱好者都算不上），但我会试试。
1 个赞
内存不足是我的猜测。你可以试试
free -h
也许也可以试试
du -hs /var/discourse/shared/standalone/*
1 个赞
内存（RAM）还是磁盘空间？
我认为两者应该都足够——Droplet 是：8 GB 内存 / 4 个 Intel vCPU / 160 GB 磁盘 + 200 GB / Ubuntu 18.04.3 (LTS) x64
在 db:migrate 仍在运行时，再打开一个 SSH 会话并运行那些命令是否“安全”？
如果我是你，我会先获得一个仍在积极支持的操作系统的新 VPS。
是的。
好的——请理解我不是 Linux 专家——你的帖子暗示当前的 Ubuntu 版本已经过时了等等？
是的，该操作系统发布于 2018 年 4 月，支持期为 5 年，已于 6 个多月前结束。
2 个赞
感谢提供信息。
作为一个坦诚承认自己是业余爱好者并尽力而为的人——您有什么建议我接下来该怎么做？
db:migrate 失败——消息是：
client_loop: send disconnect: Connection reset
重新登录后，您说得对：
新的发行版“20.04.6 LTS”可用。
运行“do-release-upgrade”进行升级。
考虑到我的论坛目前已关闭，我是否可以安全地进行升级，然后再担心修复论坛？或者我应该先尝试让论坛恢复在线？
这是一个 SSH 错误……
升级前是否进行了备份？如果进行了备份，最简单的方法是获取一台全新的 Ubuntu 22 服务器，安装 Discourse 并恢复备份。
1 个赞
很难说，但既然东西都失败了，我不会冒险。至少在确保备份存放在安全的地方之前不要这样做。
很有可能你可以启动一个新的虚拟机，停止容器（听起来它本来就没有运行），然后将所有内容 rsync 到新服务器并尝试在那里重新运行。这很可能能让你恢复运行而不会丢失任何数据。
这一切听起来很简单，但我感觉自己在这里有点力不从心。它目前运行在一个 DigitalOcean 实例上。那么启动一个新的虚拟机——这是一个有争议的说法？在同一个实例上？还是在一个新的实例上？
VM 是 DigitalOcean 称为 droplet 的通用术语。
看起来您可能想看看我的个人资料，并考虑托管服务 
1 个赞
ystemd+ 7660 0.0 0.3 352060 28284 ? S 22:31 0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
systemd+ 7667 0.0 0.1 352588 9628 ? Ss 22:31 0:00 postgres: 13/main: checkpointer
systemd+ 7668 0.3 0.9 352060 78796 ? Ss 22:31 0:03 postgres: 13/main: background writer
systemd+ 7669 0.0 0.1 352060 13696 ? Ss 22:31 0:00 postgres: 13/main: walwriter
systemd+ 7670 0.0 0.1 352728 11892 ? Ss 22:31 0:00 postgres: 13/main: autovacuum launcher
systemd+ 7671 0.0 0.0 67996 5320 ? Ss 22:31 0:00 postgres: 13/main: stats collector
systemd+ 7672 0.0 0.0 352612 6640 ? Ss 22:31 0:00 postgres: 13/main: logical replication launcher
systemd+ 10900 82.0 3.8 487164 317728 ? Rs 22:33 10:42 postgres: 13/main: discourse discourse [local] DELETE
systemd+ 10901 0.0 0.1 353432 13804 ? Ss 22:33 0:00 postgres: 13/main: discourse discourse [local] idle
htop 显示 discourse [local] delete 占用了 100% 的 CPU。该液滴有 8GB 内存，目前使用量 <1GB（不包括缓冲区）。
操作系统已过时，但这对我来说似乎非常奇怪。内存和磁盘充足，并且该 postgres 删除任务已运行超过 12 分钟。帖子少于 600K，用户少于 4K，因此数据库并不大。哦。等等。postgres_data 目录是 28GB。
我运行了 VACUUM VERBOSE ANALYZE;。
我做了这个：
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
我现在正在尝试并发重新索引。也许 vacuum 和 reindex 会有帮助。
谢谢 Jay。如果您需要我提供任何帮助，请告诉我。
请分享长时间运行的查询的完整 SQL。
我在哪里能找到它？
迁移没有打印任何日志。重建中的最后一行是
I, [2023-12-04T22:33:33.759401 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
我正在为刚刚重新启动的那个编写完整的日志。
进入容器，切换到 postgres 用户，输入 psql 并运行
SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;