MagicStack / MagicStack/asyncpg

Memory leak with Pool usage

未关闭
#1,024 3 条评论 4 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

主要语言
Python
星标
8.1k
派生
468
PR 合并指标
30 天内没有已合并 PR

描述

  • asyncpg version: 0.27
  • PostgreSQL version: 14
  • Do you use a PostgreSQL SaaS? If so, which? Can you reproduce
    the issue with a local PostgreSQL install?
    : no
  • Python version: 3.8, 3.10 and 3.11
  • Platform: docker images python:3.x-slim-buster
  • Do you use pgbouncer?: no
  • Did you install asyncpg with pip?: yes
  • Can the issue be reproduced under both asyncio and
    uvloop?
    : only asyncio

When we use a Pool, the memory usage of our process keeps increasing slowly with the number of queries. After 1000 queries, it is ~10MB and this increases with the number of queries executed on connections acquired from the pool. This remains after the max_inactive_connection_lifetime has passed with no activity, with explicit garbage collection and even after we close the pool. We can reproduce this with a psutil measurement and observe it in production. When we replace the usage of Pool with our own creation/cleanup of asynpg Connections, the issue dissapears.

Pool created with the following arguments:

asyncpg.create_pool(
    max_inactive_connection_lifetime=300,
    command_timeout=30,
    min_size=0,
    max_size=5
)

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从 asyncpg.create_pool 入口点开始,使用报告中的池参数,并通过所描述的 psutil 测量方法复现内存逐渐增加的现象。将池化连接与直接的 asyncpg 连接进行比较,包括在 max_inactive_connection_lifetime 之后、显式垃圾回收之后以及关闭池之后的情况。当复现不再显示与查询数量相关的增长时,即表示完成。

由索引模型根据 Issue 内容生成。

评估

技术栈
postgresql, python
领域
databases
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
停滞
描述清晰度
需要澄清
新手友好度
35/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。