PostgreSQL - 如果我同时运行多个查询，在什么情况下我会看到加速？在什么情况下我会看到放缓？

Question

作为一个非 DBA 的人，我谦虚地对待你们，我确信我的问题充满了概念上的缺陷，并且“这取决于”地雷。我也很确定，你们所有选择回答的人都会想要比我目前所能提供的更多的细节。

也就是说，我对以下情况感到好奇：

• 假设我有两个重要的查询。
• 查询 1 平均需要 2 分钟才能完成。
• 查询 2 平均需要 5 分钟才能完成。

如果我连续运行它们，一个接一个地运行，我预计平均需要 7 分钟才能完成。这合理吗？

然而，更重要的是，如果我同时运行这两个查询呢？同时进行两个独立的连接。

• 在什么条件下我会看到加速？（总时间 < 7 分钟）
• 在什么情况下我会看到经济放缓？（总时间 > 7 分钟）

现在，如果我同时运行 1,000 个非平凡的查询，我有预感它会导致整体速度变慢。在这种情况下，瓶颈可能在哪里？处理器？内存？驱动器？

同样，我知道在不知道具体细节（我没有）的情况下可能无法准确回答这个问题。我正在寻找一些一般准则，以便在提出以下问题时考虑：

• 在什么情况下并发查询会导致整体加速？
• 在什么情况下并发查询会导致整体速度变慢？

Answer 1

如果我连续运行它们，一个接一个地运行，我预计平均需要 7 分钟才能完成。这合理吗？

如果他们使用不相关的数据集，那么是的。

如果他们共享一个数据集，并且第一个查询的缓存是冷的并且查询主要是 I/O 绑定，那么第二个可能会很快完成。在处理性能分析和查询计时时需要考虑缓存效果。

然而，更重要的是，如果我同时运行这两个查询呢？同时进行两个独立的连接。

“这取决于”。

如果他们都使用同一个表的顺序扫描，那么在 PostgreSQL 中这将是一个巨大的性能胜利，因为它支持同步顺序扫描。

如果他们共享相同的索引，那么他们可能会从彼此读取到缓存中受益。

如果它们是独立的并且接触不同的数据，那么它们可能会争夺 I/O 带宽，在这种情况下，它们可能需要与顺序运行相同的时间。如果 I/O 子系统受益于并发性（更高的净吞吐量和更多的客户端），那么总时间可能会更少。如果 I/O 子系统处理并发性很差，那么它们可能需要比顺序运行更长的时间。或者它们可能根本不受 I/O 限制，在这种情况下，如果每个 CPU 都有空闲 CPU，它们就可以很好地执行，就好像另一个根本没有运行一样。

这在很大程度上取决于硬件和系统配置、数据集以及查询本身。

现在，如果我同时运行 1,000 个非平凡的查询，我有预感它会导致整体速度变慢。在这种情况下，瓶颈可能在哪里？处理器？内存？驱动器？

是的，由于多种原因，这很可能会减慢速度。

• PostgreSQL 在进程间协调、事务和锁管理、缓冲区管理等方面的自身开销。这可能是一个相当大的成本，而且 PostgreSQL 并不是真正为高客户端数量而设计的——如果你排队工作，它会更好。

• 工作内存、缓存等的竞争。

• 操作系统调度开销，因为它处理 1000 个都需要时间片的竞争进程。这些天相当小，现代操作系统具有快速调度程序。

• I/O 抖动。大多数 I/O 系统都有一个峰值性能的客户端数量。有时它是 1，即最好只有一个客户端，但它通常更高。有时性能再次下降到阈值以上。有时它只是达到一个平台。