# High memory usage of PostgreSQL leader pod
**URL:** https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727
**Category:** Percona Operator for PostgreSQL
**Tags:** postgresql
**Created:** [April 29, 2026, 3:04pm UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727 "2026-04-29T15:04:19Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@an-toine](https://forums.percona.com/u/an-toine)
#### Post date: [April 29, 2026, 3:04pm UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/1 "2026-04-29T15:04:19Z")
## Description:
Hello !
We are using the Percona PostgreSQL operator to instanciate databases in a Kubernetes cluster.
Lately, we have received alerts about the leader pod being evicted because of memory pressure on a node.
After some investigations, we have found the memory usage of the pod was steadily increasing (and conversely, the node available memory was decreasing), leading to this eviction :
How can we investigate this issue ?
## Steps to Reproduce:
Create a 3 nodes cluster using CRD `perconapgclusters.pgv2.percona.com` :
```yaml
apiVersion: pgv2.percona.com/v2
kind: PerconaPGCluster
metadata:
annotations:
argocd.argoproj.io/tracking-id: artifactory:pgv2.percona.com/PerconaPGCluster:artifactory/artifactory-pg-db
current-primary: artifactory-pg-db
freelens.app/resource-version: v2
pgv2.percona.com/patroni-version: 4.1.0
postgres-operator.crunchydata.com/trigger-switchover: Tue Mar 31 10:19:18 AM CEST
2026
labels:
app.kubernetes.io/instance: artifactory
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: pg-db
app.kubernetes.io/version: 2.8.2
argocd.argoproj.io/instance: artifactory
crunchy-pgha-scope: artifactory-pg-db
deployment-name: artifactory-pg-db
helm.sh/chart: pg-db-2.8.2
name: artifactory-pg-db
pg-cluster: artifactory-pg-db
pgo-version: 2.8.2
pgouser: admin
name: artifactory-pg-db
namespace: artifactory
spec:
backups:
enabled: true
pgbackrest:
global:
archive-push-queue-max: 5G
repo1-retention-full: "1"
repo1-retention-full-type: count
image: docker.io/percona/percona-pgbackrest:2.57.0-1
manual:
options:
- --type=full
- --annotation="percona.com/backup-name"="artifactory-pg-db-repo1-full-pknd9"
repoName: repo1
metadata:
labels:
pgv2.percona.com/version: 2.5.0
repoHost:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchLabels:
postgres-operator.crunchydata.com/data: pgbackrest
topologyKey: kubernetes.io/hostname
weight: 1
priorityClassName: low
repos:
- name: repo1
schedules:
full: 0 0 * * *
volume:
volumeClaimSpec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Gi
storageClassName: portworx-pso-fb-v3
trackLatestRestorableTime: true
crVersion: 2.8.2
extensions:
builtin:
pg_audit: true
pg_stat_monitor: true
image: docker.io/percona/percona-distribution-postgresql:16.11-2
imagePullPolicy: Always
instances:
- affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchLabels:
postgres-operator.crunchydata.com/data: postgres
postgres-operator.crunchydata.com/instance-set: jfrog-platform
topologyKey: kubernetes.io/hostname
weight: 1
dataVolumeClaimSpec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Gi
storageClassName: portworx-pso-fb-v3
metadata:
labels:
pgv2.percona.com/version: 2.5.0
name: jfrog-platform
replicas: 3
walVolumeClaimSpec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 800Gi
storageClassName: portworx-pso-fb-v3
patroni:
dynamicConfiguration:
postgresql:
parameters:
max_connections: 200
pg_hba:
- local all all trust
- host all all 10.10.0.0/16 md5
leaderLeaseDurationSeconds: 30
port: 8008
switchover:
enabled: true
targetInstance: artifactory-pg-db-jfrog-platform-sgtv
type: Switchover
syncPeriodSeconds: 10
pause: false
pmm:
enabled: false
image: docker.io/percona/pmm-client:3.4.1
querySource: pgstatmonitor
secret: artifactory-pg-db-pmm-secret
serverHost: monitoring-service
port: 5432
postgresVersion: 16
proxy:
pgBouncer:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchLabels:
postgres-operator.crunchydata.com/cluster: artifactory-pg-db
postgres-operator.crunchydata.com/role: pgbouncer
topologyKey: kubernetes.io/hostname
weight: 1
exposeSuperusers: true
image: docker.io/percona/percona-pgbouncer:1.25.0-1
metadata:
labels:
pgv2.percona.com/version: 2.5.0
port: 5432
replicas: 3
standby:
enabled: false
unmanaged: false
users:
- databases:
- artifactory
name: artifactory
options: SUPERUSER
secretName: artifactory-db-secret
- databases:
- xray
name: xray
options: SUPERUSER
secretName: xray-db-secret
```
## Version:
Kubernetes 1.34.3
Percona PostgreSQL operator 2.8.2
Percona distribution PostgreSQL 16.11-2
## Logs:
n/a
## Expected Result:
The database memory usage should not increase over time
## Actual Result:
The database memory usage increased to the point the pod got evicted
## Additional Information:
n/a
---
### Author:  [@Ege\_Gunes](https://forums.percona.com/u/Ege_Gunes)
#### Post date: [April 30, 2026, 7:01am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/2 "2026-04-30T07:01:58Z")
@an-toine I assume your workload patterns didn’t change much? I’ll deploy a cluster with a similar configuration to yours to see if I observe the same pattern.
---
### Author:  [@Ege\_Gunes](https://forums.percona.com/u/Ege_Gunes)
#### Post date: [April 30, 2026, 7:08am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/3 "2026-04-30T07:08:31Z")
Just remembered that pg\_stat\_monitor might create a significant memory overhead. Have you tried disabling pg\_stat\_monitor to see if it helps?
---
### Author:  [@an-toine](https://forums.percona.com/u/an-toine)
#### Post date: [April 30, 2026, 7:34am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/4 "2026-04-30T07:34:24Z")
There was no recent workload change that could explain this new behavior.
We have not updated the client application and the usage remained stable across time.
I confirm extension `pg_stat_monitor` is enabled, we could try disabling it to check if situation improves :
```auto
➜ ~ k get perconapgclusters.pgv2.percona.com -o yaml artifactory-pg-db | grep -B 5 pg_stat_monitor
trackLatestRestorableTime: true
crVersion: 2.8.2
extensions:
builtin:
pg_audit: true
pg_stat_monitor: true
```
Antoine
---
### Author:  [@Ege\_Gunes](https://forums.percona.com/u/Ege_Gunes)
#### Post date: [May 6, 2026, 2:17pm UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/5 "2026-05-06T14:17:05Z")
@an-toine did you have the chance to disable it? any updates?
---
### Author:  [@an-toine](https://forums.percona.com/u/an-toine)
#### Post date: [May 7, 2026, 6:36am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/6 "2026-05-07T06:36:11Z")
To investigate further, we chose to work on enabling PMM for this instance : will disabling this module impact PMM collected data ?
As an aside, I saw we were not setting limits memory and cpu requests/limits for this instance, and I was wondering if it could impact the memory usage in any way ?
---
### Author:  [@an-toine](https://forums.percona.com/u/an-toine)
#### Post date: [May 12, 2026, 6:47am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/7 "2026-05-12T06:47:41Z")
For your information, we have disabled module `pg_stat_monitor` and set a 8GB memory limit/2GB memory request.
We are closely monitoring the instance to evaluate the effectiveness of the change.
---
### Author:  [@Ege\_Gunes](https://forums.percona.com/u/Ege_Gunes)
#### Post date: [May 21, 2026, 6:57am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/8 "2026-05-21T06:57:38Z")
@an-toine do you see any difference?
---
### Author:  [@an-toine](https://forums.percona.com/u/an-toine)
#### Post date: [May 21, 2026, 7:04am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/9 "2026-05-21T07:04:08Z")
We think we have solved our issue by setting memory limit and requests on the instance :
We now observe a ceiling in memory usage, there is no constant increase over time.
For us, this issue is solved 🙂
Thank you for your help !
---
### Author:  [@Ege\_Gunes](https://forums.percona.com/u/Ege_Gunes)
#### Post date: [May 21, 2026, 7:06am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/10 "2026-05-21T07:06:15Z")
@an-toine I’m happy to hear that. Is this with pg\_stat\_monitor disabled or enabled?
---
### Author:  [@an-toine](https://forums.percona.com/u/an-toine)
#### Post date: [May 21, 2026, 7:10am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/11 "2026-05-21T07:10:35Z")
This behavior is observed with pg\_stat\_monitor plugin disabled.
---
### Author:  [@Ege\_Gunes](https://forums.percona.com/u/Ege_Gunes)
#### Post date: [May 21, 2026, 7:16am UTC](https://forums.percona.com/t/high-memory-usage-of-postgresql-leader-pod/40727/12 "2026-05-21T07:16:38Z")
Thanks @an-toine!
This issue is solved by disabling pg\_stat\_monitor and setting memory limits.