这不是我的问题，但这意味着没有其他东西了吗？
1 个赞
也许并非有意，但值得审计主机内容中是否存在加密货币挖掘进程等。
3 个赞
步骤 1：修复已识别的 vfs 驱动程序性能问题
7 个赞
关于切换到（理想情况下是）overlay2，我将不得不删除我当前的安装并重新安装所有东西。这是因为我目前所在的宿主机仅支持 fuse-overlayfs 或 vfs，而这两者都不推荐。
但是他们很快就会启用支持 overlay2 的 KVM。
所以我的意图是使用 KVM，而不是同样不推荐的 fuse-overlayfs。
现在，在 Discourse 应用本身中，我可以进行备份。这具体备份了什么？
如果我进行备份，在一个全新的服务器上重新安装一个全新的 Discourse，然后在初始 Discourse 设置后用备份覆盖它，我是否会丢失当前 Discourse 论坛的任何东西（我的意思是像消息、聊天、设置、用户、上传的图片等）？
这样做会奏效吗？
是的，那会奏效。
您唯一没有提到的是，要确保在新 Discourse 上安装与当前 Discourse 相同的插件。如果您重新使用 app.yml，那么您也会没事的。
3 个赞
好的，谢谢你指出来，我敢肯定我差点就撞上了。
好的，那么……
- 在 Discourse 管理区域进行备份
- 为了安全起见，当然要备份服务器
- 复制 yaml 文件
- 转储服务器
- 使用支持的技术设置新服务器
- 安装具有正确存储驱动程序的 Docker
- 使用备份的 yaml 文件重建一个全新的 Discourse 实例
- 从备份恢复 Discourse
有点惊讶备份只有 19.2 MB。
我们已经上传了几个图片等……但我想我只能试试了。
我将在周末进行尝试，如果存储驱动程序更改奏效，我会回来报告。
1 个赞
检查是否已设置：
1 个赞
3 个赞
它确实被勾选了，但 在备份中包含生成的缩略图。禁用此选项将减小备份大小，但需要在恢复后重新烘焙所有帖子。 没有被勾选。
@RGJ … 对，好主意，需要采取更多步骤，因为我将不得不以新的实体创建一个服务器，但这与风险相比微不足道。
我将让_自动_备份触发，以便我获得其中的所有数据，因为据我所知，手动备份不包括图片等。
谢谢…
这是一个错误的假设。
创建手动备份时，会弹出一个窗口供您选择是仅备份数据库，还是包含上传文件。
创建计划备份时，由“备份含上传文件”设置决定。
4 个赞
好的，我误解了您之前的“请注意，该特定设置仅适用于计划备份，而不适用于手动备份。”
谢谢……
2 个赞
您好，我重新开启了这个话题，因为它仍然是开放的，并且在迁移到新的虚拟服务器后，我们遇到了同样的问题。就像其他人说的那样，我以前重建 Discourse 从来没有超过 20 分钟，但在新服务器上却需要几个小时，而且它的资源是以前服务器的两倍。
我查看了 Meta 上关于长达一小时的升级的其他话题，但无法弄清楚我们遇到的问题是什么：
服务器：4Gb 内存，2CPU，50 Gb 磁盘。
交换空间：
/$ free
总计 已用 可用 共享 缓冲/缓存 可用
内存: 3911740 507208 2318476 268 1384032 3404532
交换空间: 4095976 45472 4050504
Docker：
/$ sudo docker info
客户端:
版本: 26.1.3
上下文: default
调试模式: false
服务器:
容器: 3
运行中: 0
暂停: 0
已停止: 3
镜像: 3
服务器版本: 26.1.3
存储驱动程序: overlay2
后端文件系统: extfs
支持 d_type: true
使用元数据复制: false
原生 Overlay Diff: true
userxattr: false
日志驱动程序: json-file
Cgroup 驱动程序: systemd
Cgroup 版本: 2
插件:
卷: local
网络: bridge host ipvlan macvlan null overlay
日志: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: 非活动
运行时: io.containerd.runc.v2 runc
默认运行时: runc
Init 二进制文件: docker-init
containerd 版本:
runc 版本:
init 版本:
安全选项:
apparmor
seccomp
配置文件: builtin
cgroupns
内核版本: 6.8.0-31-generic
操作系统: Ubuntu 24.04.2 LTS
OSType: linux
架构: x86_64
CPUs: 2
总内存: 3.731GiB
名称: podkasts
ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Docker 根目录: /var/lib/docker
调试模式: false
实验性: false
不安全注册表:
127.0.0.0/8
实时恢复启用: false
在我看来一切正常，但我可能遗漏了什么。我们还能从哪里查找问题？
也许是“吵闹的邻居”导致你的新虚拟机比旧虚拟机慢，因为他们占用了你得不到的所有 CPU？
1 个赞
是的，谢谢你，很高兴像你这样经验丰富的管理员也没有在上述信息中发现任何明显问题，这让人感到安心。是的，我们已经开始检查物理服务器和我们的虚拟环境。至少论坛运行正常，用户没有注意到任何问题。我们只在重建时遇到这个严重的性能问题。昨天我们花了 4 个小时进行重建。
1 个赞
如果我遇到这个问题，我会打开两到三个终端窗口。一个用于运行重建，一个用于记录经过的时间以及日志更新之间发生长时间延迟的位置，最后一个用于记录机器活动：可能运行 vmstat 5
当日志长时间不更新时，请记下 vmstat 报告的活动。
在此处发布日志中的合适摘录，以及您的笔记和相应的 vmstat 输出。
看起来重建的特定部分很可能耗时：要做的是找出是哪些部分，并在那些时候查看机器在做什么。
在停顿期间，我可能还会使用 ps auxf 拍摄机器活动的快照。
4 个赞
谢谢，这是个很好的建议。下次需要重建时，我们会照此办理。
2 个赞