MagicStack / MagicStack/asyncpg
Memory leak with Pool usage
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 8.1k
- Forks
- 468
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
* **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](https://github.com/magicstack/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
)
```
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez au point d’entrée asyncpg.create_pool avec les arguments de pool indiqués et reproduisez l’augmentation progressive de la mémoire à l’aide de la mesure psutil décrite. Comparez les connexions du pool aux connexions asyncpg directes, notamment après max_inactive_connection_lifetime, un garbage collection explicite et la fermeture du pool. La tâche est terminée lorsque la reproduction ne montre plus d’augmentation liée au nombre de requêtes.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- postgresql, python
- Domaine
- databases
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 35/100