helmi
(Helmi)
1
为了更新我们的论坛，我在周末进行了全新的 VPS 安装 + 恢复。
这将为我们解决多个问题：
虽然总体上一切顺利，但在之后我遇到了 Postgres 进程失控的问题，占用了 100% 的核心。不过进程数量在变化。我尝试了一些方法，从重建到重启。目前正在尝试一个 rake db:validate_indexes，它已经运行了几个小时但没有任何反馈。我不确定我之前是否做过这个，以及它是否应该更快完成。
论坛的基本使用效果很好，但肯定变慢了。一些耗时较长的任务，比如调出活跃用户的一些用户资料，比平时要花费更长的时间。
我非常确定数据库存在一些问题，但我很难找出是哪些问题。
我得说我们的数据库非常庞大——恢复后，在创建索引之后，我们大约有 150GB。从监控恢复过程来看，我没有看到任何错误，在我看来索引创建也很顺利。
有什么方法可以解决这个问题吗？现在有 3 个 postgres 进程——在我几个小时前重启之前是 6 个——恢复后我也看到过所有 16 个核心都被使用了。
编辑：我现在才注意到，有 3 个 sidekiq 进程正在忙于“为搜索建立索引”。这会不会只是搜索索引重建？如果是这样，有没有其他方法可以解决？当我们进行实时系统恢复时，如果它在多个小时甚至几天内都这样降低性能，那将是一个巨大的问题。
helmi
(Helmi)
2
现在只有一个 sidekiq 任务在运行“Jobs::BackfillBadge”，但仍有 7 个 postgres 进程似乎一直在阻塞 100% 的 CPU。真想知道那里发生了什么。
Falco
(Falco)
3
进行此类迁移后，最好运行 vacuum 来更新数据库统计信息。
1 个赞
helmi
(Helmi)
5
该测试服务器有 32GB 内存、16 核，配置设置为 64MB 工作内存。
编辑：共享缓冲区为 8GB
目前正在进行一个看起来卡住的 vacuum 操作
不确定它是否在执行操作，但它已经在这里停留了 30 多分钟了。
我已将论坛设置为只读模式，并重启了虚拟机以结束之前“卡住”的 7 个 Postgres 进程。重启后不久，其中两个 Postgres 进程又回来了，并且没有变化。Sidekiq 目前没有运行任何东西。
Falco
(Falco)
6
您真的不想运行一个完整的 VACUUM。要恢复性能，您只需要一个 VACUUM VERBOSE ANALYZE。您不能在运行的站点上运行 FULL。
1 个赞
pfaffman
(Jay Pfaffman)
7
我不是大型数据库方面的专家，但我会将缓冲区设为原来的两到三倍。
我相信您的索引有 8GB。
RGJ
(Richard - Communiteq)
8
Postgres 建议 shared_buffers 永远不要超过内部内存的 40%？
话虽如此，
您的服务器可能配置不足。
2 个赞
pfaffman
(Jay Pfaffman)
9
啊哈！专家的明智建议！所以也许我之前认为 8GB/25% 不够是正确的，尽管 16GB 超过了 40%，但它可能仍然是一个好建议，因为……
1 个赞
helmi
(Helmi)
10
各位。如前所述，这是一个测试服务器——上面没有任何流量。这个服务器绝对不足以用于生产环境，但这也不是问题所在。问题是为什么我们会看到 postgres 进程卡住（CPU 使用率 100%）并急剧拖慢速度。直到几天前，我们还在以较低的容量运行测试服务器——它只是因为恢复时磁盘空间不足才被升级的。
生产机器运行着 128GB 内存，具有相同的共享缓冲区设置，没有任何问题——所以我认为这些设置和共享缓冲区大小没有普遍性问题——尤其是在没有流量的私有测试机器上。
但无论如何——我将重新进行恢复，看看是否有什么可能出错的地方，因为似乎没有好的解释来解释这种行为。
