Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

148
Views
Postgresql POD Master/Slave don't clean the cache when Client stopped sending data

I'm running a Performance Stress test on our backend using a client that generates the stress.

I've stopped the client from sending data after 5-6 hours , but I've noticed that the cache of the K8S Postgres POD never cleans itself (both Master and Slave).

Here is the report of pg_top:

last pid: 18144;  load avg:  0.11,  0.36,  0.48;       up 98+20:59:02                                                                                                                                 08:42:16
0 processes: 
CPU states:  0.3% user,  0.0% nice,  0.1% system, 99.6% idle,  0.0% iowait
Memory: 123G used, 64G free, 0K shared, 1230M buffers, 96G cached
Swap: 67M used, 8125M free, 30M cached, 0K in, 0K out
 FATAL:  role "root" does not exist

Here is the Postgres configuration of the K8S POD:

numberOfInstances: 2
postgresql:
  parameters:
    effective_cache_size: "90GB"
    effective_io_concurrency: "200"
    listen_addresses: '*'
    log_destination: "stderr"
    logging_collector: "false"
    log_min_error_statement: "DEBUG1"
    log_error_verbosity: "verbose"
    maintenance_work_mem: "2GB"
    max_connections: "10000"
    max_wal_size: "4GB"
    min_wal_size: "2GB"
    max_worker_processes: "30"
    max_parallel_workers_per_gather: "16"
    max_parallel_workers: "30"
    max_parallel_maintenance_workers: "16"
    random_page_cost: "1.1"
    shared_buffers: "40GB"
    shared_preload_libraries: "pg_stat_statements"
    synchronous_commit: "false"
    syslog_facility: "LOCAL0"
    syslog_ident: "postgres"
    syslog_sequence_numbers: "true"
    syslog_split_messages: "true"
    wal_buffers: "16MB"
    work_mem: "6MB"
resources:
  limits:
    cpu: 40000m
    memory: 110Gi
  requests:
    cpu: 40000m
    memory: 110Gi

This results in the Postgres RAM to reach its MAX RAM size which eventually causes the backend to crash.

Any idea what might cause this ?

about 4 years ago · Juan Pablo Isaza
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!