linux – 为什么PostgreSQL在长时间运行INSERT时没有保存到磁盘… SELECT …？

2023年10月26日 165次阅读

我正在使用外部数据包装器将大量数据(在一列上进行非常简单的日期转换)移动到本地数据库.使用Django游标(因为我懒得拔出凭据来创建原始的psycopg2游标)我做了这种查询(匿名并删除了几个连接,但与原始连接相同)：

cursor.executemany(
    sql.SQL(
        """
        INSERT INTO local_table (
            foreign_key_id,
            other_foreign_key_id,
            datetime,
            comment
        )
        SELECT other_local_table.id,
               %s,
               (object_date + to_timestamp(object_time, 'HH24:MI')::time) at time zone '…',
               comment
          FROM imported_schema.remote_table
          JOIN other_local_table ON other_local_table.code = remote_table.code
        """
    ),
    [(dummy_id,)],
)

但是,一段时间后,本地Postgres服务器总是会被OOM杀死.我期待Postgres将新行刷新到磁盘以避免内存不足,但据我所知,这只是没有发生 – / var / lib / docker / volumes / vagrant_postgres_data只增加几MB而驻留内存使用成长为GB.本地服务器没有足够的RAM来将整个结果集保存在内存中,因此我需要一个不涉及更昂贵的硬件设置的解决方案.

我是否需要设置类似wal_sync_method或work_mem的东西才能生效？

根据文档,executemany应该是工作的正确工具：

The function is mostly useful for commands that update the database: any result set returned by the query is discarded.

在Linux上在两台服务器上运行Postgres 10.6 containers,在本地运行Django 2.1.我没有使用FDW以外的任何扩展.

解释计划：

Insert on local_table  (cost=817872.44..818779.47 rows=25915 width=56)
  ->  Subquery Scan on "*SELECT*"  (cost=817872.44..818779.47 rows=25915 width=56)
        ->  HashAggregate  (cost=817872.44..818390.74 rows=25915 width=48)
              Group Key: other_local_table.id, 1, timezone('…'::text, (remote_table.object_date + (to_timestamp((remote_table.object_time)::text, 'HH24:MI'::text))::time without time zone)), remote_table.comment
              ->  Nested Loop  (cost=101.15..807974.88 rows=989756 width=48)
                    ->  Nested Loop  (cost=0.57..60.30 rows=73 width=12)
                          ->  Nested Loop  (cost=0.29..42.35 rows=38 width=4)
                                ->  Seq Scan on fourth_local_table  (cost=0.00..7.45 rows=1 width=4)
                                      Filter: ((code)::text = '…'::text)
                                ->  Index Scan using … on third_local_table  (cost=0.29..34.49 rows=41 width=8)
                                      Index Cond: (id = fourth_local_table.id)
                          ->  Index Scan using … on other_local_table  (cost=0.29..0.45 rows=2 width=16)
                                Index Cond: (id = third_local_table.id)
                    ->  Foreign Scan on remote_table  (cost=100.58..9421.44 rows=151030 width=20)

postgresqltuner建议我

set vm.overcommit_memory=2 in /etc/sysctl.conf … This will disable memory overcommitment and avoid postgresql killed by OOM killer.

这是解决方案吗？

最佳答案 除了可能消耗任何内存量的HashAggregate之外,我在执行计划中没有看到任何内容,这应该受到work_mem的限制.

要诊断这一点,您应该首先配置系统,以便获得常规的OOM错误,而不是调用OOM杀手.这意味着使用sysctl设置vm.overcommit_memory = 2并将vm_overcommit_ratio调整为100 *(RAM – swap)/ RAM.

当服务器收到OOM错误时,它会将当前内存上下文及其大小转储到PostgreSQL日志中.这应该指示内存的去向.如有疑问,请将其添加到问题中.

您使用的是第三方扩展吗？

点赞