Checkpointer process holds the shared_buffers memory and it is the expected behaviour. Even during idle, shared buffers
arethere for reads and future modifications. You have SB configured to be 10GB and it will stay allocated throughout
thewhole uptime of the server. This is totally OK and should help (generally) with the performance.
The “idle” thing is slightly less straightforward, as checkpointer and writer try to spread the load in time.
As for memory climbing to 90%, you might want to reduce shared buffers to something less than 1/3 of your RAM and see
ifit helps.
But again, if there’s no issues with system availability and health then you should not be bothered imo
> 6 апр. 2025 г., в 14:37, Motog Plus <mplus7535@gmail.com> написал(а):
>
>
>
> Hi All,
>
> I’m running PostgreSQL on an EC2 c5.4xlarge Ubuntu instance with the following specs:
>
> 32 GB RAM
>
> 1.2 TB disk
>
> 16 vCPUs
>
>
> Pgpool-II Configuration:
>
> max_pool = 2
>
> num_init_children = 1000
>
> client_idle_limit = 300 seconds
>
> connection_life_time = 300 seconds
>
> load_balance_mode = on
>
>
> PostgreSQL Configuration:
>
> max_connections = 3000
>
> checkpoint_timeout = 15min
>
> checkpoint_completion_target = 0.9
>
> shared_buffers = 10GB
>
> wal_buffers = 64MB
>
> min_wal_size = 80MB
>
> max_wal_size = 10GB
>
> effective_cache_size = 20GB
>
> work_mem = 4MB
>
> maintenance_work_mem = 1GB
>
> bgwriter_delay = 200ms
>
> bgwriter_lru_multiplier = 2
>
> bgwriter_lru_maxpages = 100
>
> max_standby_streaming_delay = 5s (on standby)
>
>
> I have a primary-standby streaming replication setup, and application modules (running in Kubernetes pods) connect to
thedatabase through Pgpool-II using HikariCP.
>
>
> ---
>
> Issue Observed:
>
> Even when no queries are running and application batch jobs have completed, memory usage remains high(40%)—
particularlyattributable to the checkpointer and background writer processes. According to Grafana, memory continues to
remaincached.
>
> When I manually kill the checkpointer process on the node, memory usage drops immediately(9%). If I don't kill it and
startanother batch, memory usage increases further — reaching up to 90%, though under normal conditions it stays around
65–70%.
>
>
> ---
>
> System Memory Snapshot (when idle):
>
> free -h :
> total 30 Gi
> used 12 Gi
> free 2.2 Gi
> shared 10Gi
> buff/cache 27Gi
> available 18Gi
> PostgreSQL memory usage from ps:
>
> ps -eo pid,rss,cmd | grep postgres | awk '{sum+=$2} END {print sum/1024 " MB"}'
>
> Output:
> 25682.4 MB
>
> Note: Even though the system is idle for over 50 hours, connections connect, become idle and drop.
>
> ---
>
> Question:
>
> Is it normal for the checkpointer and background writer to hold onto memory like this after workloads finish? Is this
relatedto how PostgreSQL manages shared buffers or dirty pages in a streaming replication setup?
>
> Are there any parameters in postgresql.conf or Pgpool that can help ensure memory is better reclaimed when the system
isidle?
>
> Any guidance would be much appreciated.
>
> Best regards,
> Ramzy
