这是一篇关于在 Postgres 数据库中优化写入性能的文章，主要内容如下：

• 背景与问题：作者所在的 Hatchet 平台使用 Postgres 作为任务队列、协调器和监控系统的后台数据库，在开始扩展系统后，观察到数据库出现了一些令人担忧的行为，如 CPU 过高、神秘错误和高锁争用等，不确定是 Postgres 集群达到了极限还是操作有误。

• 基本优化：

  • 减少网络延迟：在本地测试中，单连接无网络延迟时可达到约 2k 写入/秒，添加 2ms 人工延迟后降至约 800 写入/秒。
  • 使用连接池：使用 10 个连接的连接池可使吞吐量提高 5 倍，但超过 20 个连接后，吞吐量提升不明显，且平均写入时间增加，因为每个连接都有开销，包括从连接池获取连接的开销、CPU 和共享资源的开销以及其他瓶颈。
  • 不要使用过多连接：连接池的大小应根据数据库情况进行调整，避免引发“连接风暴”导致数据库性能下降。

• 批量插入优化：

  • 批量插入：将一批行打包到每个查询中，可减少开销，提高吞吐量。在本地测试中，使用批量插入 100k 行比逐行插入的吞吐量提高了 >10 倍。
  • COPY 命令：如果只关心写入数据且不需要返回结果，可以使用 COPY 命令获得更好的性能，测试中使用 COPY 命令的吞吐量达到 63k 写入/秒，比批量插入和单连接插入都快。
• 优化延迟：增加批量大小可提高吞吐量，但也会导致平均写入延迟增加，存在一个最佳批量大小，使吞吐量和延迟达到平衡。
• 总结：通过 6 项优化，在保持低延迟的同时提高了吞吐量，包括减少网络延迟、使用连接池、避免使用过多连接、使用批量插入和 COPY 命令以及确定最佳批量大小等。同时还提到了一些在其他场景中可以提高写入性能的方法，如在同一事务中插入多个表、处理带有外键的表的写入问题等，后续将深入探讨这些场景。

文章最后还提供了订阅以获取更多技术深度内容的信息。