如何在 PostgreSQL 上保持高插入性能

Question

我正在从事一个项目，该项目将测量文件中的数据解析到 Posgres 9.3.5 数据库中。

核心是一个表（按月分区），其中包含每个测量点的一行：

CREATE TABLE "tblReadings2013-10-01"
(
-- Inherited from table "tblReadings_master":  "sessionID" integer NOT NULL,
-- Inherited from table "tblReadings_master":  "fieldSerialID" integer NOT NULL,
-- Inherited from table "tblReadings_master":  "timeStamp" timestamp without time zone NOT NULL,
-- Inherited from table "tblReadings_master":  value double precision NOT NULL,
  CONSTRAINT "tblReadings2013-10-01_readingPK" PRIMARY KEY ("sessionID", "fieldSerialID", "timeStamp"),
  CONSTRAINT "tblReadings2013-10-01_fieldSerialFK" FOREIGN KEY ("fieldSerialID")
      REFERENCES "tblFields" ("fieldSerial") MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE RESTRICT,
  CONSTRAINT "tblReadings2013-10-01_sessionFK" FOREIGN KEY ("sessionID")
  REFERENCES "tblSessions" ("sessionID") MATCH SIMPLE
  ON UPDATE CASCADE ON DELETE RESTRICT,
  CONSTRAINT "tblReadings2013-10-01_timeStamp_check" CHECK ("timeStamp" >= '2013-10-01 00:00:00'::timestamp without time zone AND "timeStamp" < '2013-11-01 00:00:00'::timestamp without time zone)
)

我们正在用已经收集的数据填充表。每个文件代表大约 48,000 个点的交易，并且有数千个文件。它们是使用导入的INSERT INTO "tblReadings_master" VALUES (?,?,?,?);

最初，文件以 1000+ 次插入/秒的速度导入，但过了一段时间（数量不一致，但从不超过 30 分钟左右），该速度下降到 10-40 次插入/秒，并且 Postgres 进程运行 CPU。恢复原始速率的唯一方法是执行完全真空和分析。这最终将每个月表存储大约 1,000,000,000 行，因此真空需要一些时间。

编辑：这是一个示例，它在较小的文件上运行了一段时间，然后在较大的文件启动后它失败了。较大的文件看起来更不稳定，但我认为这是因为事务仅在文件末尾提交，大约 40 秒。

将有一个 web 前端选择一些项目，但没有更新或删除，这在没有其他活动连接的情况下可见。

我的问题是：

1. 我们怎么知道是什么导致了 CPU 速度变慢/轨道（这是在 Windows 上）？
2. 我们可以做些什么来保持原有的性能？

Answer 1

有一些事情可能会导致这个问题，但我不能确定其中任何一个是真正的问题。故障排除都涉及打开数据库中的额外日志记录，然后查看慢速部分是否与那里的消息一致。确保在 log_line_prefix 设置中放置了时间戳，以便查看有用的日志。请参阅我的调优介绍以开始使用：https : //wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Postgres 将所有写入操作都写入操作系统缓存，然后再写入磁盘。您可以通过打开 log_checkpoints 并阅读消息来观察它。当事情变慢时，可能只是所有缓存现在都已满，所有写入都被卡住，等待 I/O 的最慢部分。您可以通过更改 Postgres 检查点设置来改进这一点。

人们有时会遇到数据库内部问题，其中大量插入卡住等待数据库中的锁定。打开 log_lock_waits 看看你是否遇到了那个。

有时，您可以执行突发插入的速率高于系统自动清理进程启动后所能承受的速率。打开 log_autovacuum 以查看问题是否与发生时同时发生。

我们知道，数据库私有 shared_buffers 缓存中的大量内存在 Windows 上的运行效果不如在其他操作系统上好。当它发生时，也没有那么多的可见性。我不会尝试托管在 Windows PostgreSQL 数据库中每秒插入 1000 次以上的内容。对于真正繁重的写入，这还不是一个好平台。

Answer 2

我不是 Postgres 专家，所以这可能是错误的！您的主键有 3 列，sessionID 作为第一个字段。该文件是否包含适当的时间戳分布？您可能会考虑将其作为主键中的第一个字段或使用代理键，因为目前它相当宽。

从你的脚本来看，我认为你没有集群。与 SQL Server 不同，但我认为您必须使用“Cluster”命令指定 Postgres 中表的物理顺序。该链接谈到了这一点：

/sf/ask/335758391/