在 Postgres 迁移后，Rails 写入时间增加了 100%

Posted 2023-03-06

【中文标题】在 Postgres 迁移后，Rails 写入时间增加了 100%

【英文标题】：Rails Writes Take 100% Longer After Postgres Migration

【发布时间】：2014-08-12 20:59:54

【问题描述】：

我正在一个大型 Rails 应用程序上从 mysql 迁移到 Postgres，大多数操作都以正常速度执行。但是，我们有一个特定的操作，它将每 30 分钟左右生成一次作业记录。通常会生成并插入大约 200 条记录，之后我们有单独的工作人员从另一台服务器上接工作并处理它们。

在 MySQL 下，生成记录大约需要 15 秒，然后工作人员需要另外 3 分钟来执行并写回结果，一次一个（因此对原始作业记录进行了 200 多次更新）。

在 Postgres 下，大约需要 30 秒，然后工作人员需要 7 分钟来执行并写回结果。

要写入的表大约有 200 万行，ID 下有 1 个序列列。

我尝试调整检查点超时和大小，但没有成功。

该表被大量索引，实际上应该与以前没有任何不同。

我不能发布代码示例，因为它是一个庞大的代码库，如果不发布页面和代码页面，它就没有任何意义。

我的问题是，谁能想到为什么会发生这种情况？ Postgres 日志中没有任何内容，创建这些对象的过程并没有真正改变。 Postgres 是否存在某种我不知道的阻塞同步写入行为？

我已经在我的代码中添加了各种日志记录来发现错误或事务失败，但我什么也没想到，它只需要两倍的时间来运行，这对我来说似乎不正确。

Postgres 实例托管在 M3.Medium 实例类型的 AWS RDS 上。

我们也使用了New Relic，但这里没有显示出任何有趣的东西，这很令人惊讶

【问题讨论】：

如果您不能详细说明 (1) 队列是什么，(2) 工作是如何创建的，或者 (3) 工作人员做什么，那么究竟有什么人能说出有什么不同呢？

worker 执行本地系统任务，并在完成后简单地使用作业信息返回 API 调用以更新各个记录。作业由调度程序每小时创建一次，触发控制器方法并计算一组动态任务并将其插入到处于“待定”状态的表中。工作人员通过 API 调用获取这些信息。我怀疑任何人都能够给我一个答案，但我想在这种情况下就 Postgres 的使用提出一些建议或方向。有人提到索引在 Postgres 上的工作方式不同？

您是否尝试过调整 postgres（通过编辑 postgres.conf）？初始设置非常低。此外，如果你使用 MySQL ISAM 表，Postgres 会更慢，因为它提供了 MySQL ISAM 表不具备的几个特性。

是的，iv 调整了检查点超时和检查点段大小，它似乎没有帮助。我们的 MySQL 数据库都是 InnoDB。它们都在 AWS RDS 上运行，因此 AWS 应该已经将其调整为下降量。我预计它会稍微慢一点，但不会慢 100%。不幸的是，这是一个表演终结者。

【参考方案1】：

为什么您的作业队列包含 200 万行？它们是全部上线还是未将它们移至存档表以使您的报告更简单？

您是否从 psql 提示符或您首选的 SQL IDE/工具对您的 SQL 使用了 EXPLAIN？

Postgres 是一个与 MySQL 完全不同的 RDBMS。它以不同方式分配空间并以不同方式操作空间，因此可能需要以不同方式进行索引。

此外，还有一个名为 pgtune 的工具会建议配置更改。

---

编辑：2014-08-13

另外，rails comes with a profiler 可能会增加一些见解。这是*** thread about rails profiling。

您还想在磁盘 IO 级别查看您的数据库服务器。你的工作是否完成到大量的更新？ Postgres 在您更新现有行时创建新行，并将旧行标记为可用，而不是仅仅覆盖现有行。因此，由于您的 RDBMS 切换，您可能会看到更多的 IO。

【讨论】：

200万行大约是1个月的数据，在应用中需要用到，我们稍后存档。我很想知道更多关于您何时说它需要以不同方式编制索引的信息？你是什​​么意思？我去看看 pgtune，谢谢

您在 psql 中使用 EXPLAIN [postgresql.org/docs/9.2/static/sql-explain.html] 命令让 psql 告诉您它计划如何执行您的查询。如果您看到大量的顺序扫描，您可能希望以不同的方式索引您的数据。

您是说今天您的应用程序的某些部分需要使用三周前作业队列中的数据吗？

正确。作业状态信息与其他信息混合，并沿事件时间线和图表呈现趋势。 （糟糕的工作状态表明系统不健康）所以我们提前一个月用于按需使用非常重要。

好的。我回来解释工作记录生成和履行的每一步。这是了解数据库瓶颈在哪里的唯一真正方法。