PGVector(pg16)容器批量插入后重启PostgreSQL无响应问题求助

使用PGVector:pg16 Docker容器，涉及的表结构如下：

CREATE TABLE IF NOT EXISTS embeddings (
    content_id UUID NOT NULL,
    chunk_id UUID NOT NULL PRIMARY KEY,
    chunk_position INT NOT NULL,
    embedding_vector VECTOR(1536) NOT NULL,
    inserted_at TIMESTAMP DEFAULT TIMEZONE('utc', NOW())
);

已创建的索引：

CREATE INDEX IF NOT EXISTS embedding_vector_idx 
ON embeddings USING hnsw (embedding_vector vector_ip_ops) 
WITH (m = 16, ef_construction = 64);

CREATE INDEX IF NOT EXISTS content_id_idx 
ON embeddings (content_id);

插入方式为每批150条向量，共插入40万条数据，示例语句：

INSERT INTO embeddings (chunk_position, content_id, chunk_id, embedding_vector) 
VALUES (cp1, cid1, chid1, ev1), …., (cp150, cid150, chid150, ev150);

问题现象 #

• 单条向量平均插入时间约7.8秒，插入过程中内存占用线性增长，最终达到4GB（约每10万向量占用1GB），内存耗尽后不得不重启容器。
• 容器重启后，embeddings表无法访问达半小时之久。

待解答问题 #

1. 批量插入embeddings表时内存持续增长的原因是什么？
2. 为何重启PGVector容器后PostgreSQL会长时间无响应？

已尝试操作 #

• 以每批150个向量的方式向embeddings表插入40万条数据
• 重启PGVector容器释放内存

预期结果 #

• 内存占用达到阈值后稳定或下降
• 容器重启后PostgreSQL立即恢复响应

实际结果 #

• 内存占用持续线性增长至4GB（约每10万向量占用1GB）
• 重启PGVector容器后，PostgreSQL无响应约半小时后才恢复embeddings表访问

问题解答 #

1. 批量插入时内存持续增长的原因 #

PGVector的HNSW索引在构建阶段会将大量数据驻留内存。HNSW是基于图的近似最近邻索引，插入数据时需要维护图的拓扑结构，m=16和ef_construction=64的参数意味着每个新插入的向量要与更多已有节点建立连接，构建过程中会缓存中间计算数据和未持久化的图结构。

同时，批量插入的事务会先将所有待插入数据加载到内存，加上PostgreSQL自身的shared_buffers、work_mem等内存配置，如果work_mem设置过大，每批插入的排序、索引构建操作会占用更多内存；而HNSW索引在插入期间不会主动释放内存，直到事务提交或索引完成持久化，导致内存随插入量线性增长。

另外，40万条1536维向量本身数据量不小，加上索引构建的额外开销，每10万条占用1GB内存符合HNSW索引的内存消耗特性——索引的内存占用通常是原始向量数据的数倍。

2. 重启后长时间无响应的原因 #

PostgreSQL重启后会执行恢复过程，包括重做WAL（预写日志）和检查点后的未持久化数据。对于带有HNSW索引的表，重启时PostgreSQL需要重新加载HNSW索引的元数据，甚至可能需要重新构建部分索引结构（如果索引持久化不完整）。

另外，40万条数据对应的HNSW索引文件较大，重启时PostgreSQL需要将索引核心部分加载到内存，这个过程会涉及大量磁盘IO操作，若容器使用的存储性能较差（如机械硬盘或共享存储），IO等待会导致数据库长时间无响应。

还有一种可能是，重启前内存耗尽导致数据库异常终止，PostgreSQL需要执行崩溃恢复，回滚未提交的事务并修复不一致的索引结构，这个过程对于大表和复杂索引来说会消耗大量时间。

内容的提问来源于stack exchange，提问作者Matanel Abayof