感谢您提供所有详细信息。您这样做很好
但我认为这样做可能只会在下次重启前生效。重启后您需要再次执行。请参阅 MKJ 的意见部署配置 以获取使此设置永久生效的技巧。
感觉您可能内存不足（我的意思是 RAM+swap），但 2+4 应该足够了。请运行以下快速诊断并发布结果：
cat /etc/lsb-release
uptime
df -h /
free
swapon
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
也请在此处分享您的 app.yml 文件——但不要包含其中的密码和机密令牌！
如果您能够建立两个 SSH 连接，您可以使用一个连接来运行应用程序重建，并使用另一个连接来查看机器正在做什么。我喜欢交替使用
vmstat 5 5
ps auxrc
您可能正在将交换空间写入远程磁盘——网络附加存储——这已知是一个问题。它会非常慢。也许会导致超时，这就是问题所在。也许有办法调整超时时间。
我找到了 这个——也许有帮助？
（至少在某些 systemd 版本中，默认的 systemd 超时为 90 秒，所以这很吻合）。
您可以尝试通过增加 postgresql 的 systemd 单元（甚至全局）中的 TimeoutStartSec 来解决此问题，但这也许只是隐藏了问题，直到下一个服务突然无法启动。
编辑：如果是这样，那么 这个建议 可能会有帮助：
您可以在
/etc/systemd/system.conf中取消注释以下行：DefaultTimeoutStartSec=90s DefaultTimeoutStopSec=90s并将值更改为您认为合适的值。