prometheus-community / prometheus-community/postgres_exporter
Multi-target support - Memory leak
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 3.6k
- Forks
- 835
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 10
Description
What did you do?
I installed the master version (at the time of writing the latest commit is 02aff21) of the PostgreSQL exporter and configured it to scrape metrics from three databases belonging to the same PostgreSQL server. My goal was to test the multi-target support.
Additional information on the configuration: I noticed that the latest version of the PostgreSQL exporter doesn't close connections so I use the parameter idle_session_timeout(cf this comment for more information).
What did you expect to see?
A PostgreSQL exporter running and scraping metrics from multiple databases.
What did you see instead? Under which circumstances?
I realized the PostgreSQL exporter suffers from a memory leak. Here is a screenshot showing the memory consumption for the VM on which is installed the PostgreSQL exporter:

Environment
- System information:
The exporter is running in a container.
- postgres_exporter version:
postgres_exporter, version 0.12.0-rc.0 (branch: master, revision: 34d3605788e91de4ab645a5e60d455bbd7acf0ef)
build user: root@26e17be79988
build date: 20221101-00:51:53
go version: go1.18.7
platform: linux/amd64
- postgres_exporter flags:
PG_EXPORTER_DISABLE_DEFAULT_METRICS=true
PG_EXPORTER_DISABLE_SETTINGS_METRICS=true
- PostgreSQL version:
PostgreSQL 14.4 on x86_64-pc-linux-gnu, compiled by Debian clang version 12.0.1, 64-bit
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue provides no file or test entry point. Reproduce the leak with multi-target scraping against three databases, then profile memory while checking connection handling; done means sustained scraping no longer shows unbounded memory growth.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, postgresql
- Domain
- databases, observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100