Significantly increased CPU and RAM usage compared to buildin barman on Designated primary

[dragoangel]

Description

Hi, from what I observe current plugin version consumes in 2x times more CPU and 4x RAM (facing RAM limit of container) on replication from previous buildin barman solution.

Issue

There maybe be a memory leak and I can't explain to myself so significant CPU usage at all. Would be glad if it can be checked.

Environment

• ghcr.io/cloudnative-pg/plugin-barman-cloud:v0.7.0
• ghcr.io/cloudnative-pg/cloudnative-pg:1.27.0
• K8s v1.31.2

Buildin usage

From my monitoring Designated primary on buildin barman consumes 0.5 CPU and 160MiB of RAM which includes stale (not loaded with anything) postgres, so load of barman I think somewhere near 0.3-0.4 CPU and less near 90MiB.
I tried finding barman process to get exact data but from what I see there is only /controller/manager instance run --status-port-tls --log-level=info and postgres itself.

Plugin usage

From plugin I see barman as dedicated sidecar and it's load on system is significant, stable 0.9 CPU usage just for barman, and RAM usage get up to 350MiB - which is my configured RAM limit for this container:

[dosubot]

There aren't any known issues or tickets reporting high CPU or RAM usage or memory leaks in the plugin-barman-cloud sidecar. The code review shows that the backup and metrics routines involve multiple Kubernetes API calls, environment variable setup, and frequent logging, which could contribute to resource usage if called very often or with verbose log levels. The caching logic for Kubernetes objects uses deep copies and reflection, and if the cache grows large or is not properly managed, it could increase memory usage.

You might want to check the logging level (trace/debug can be expensive), cache TTL settings, and how frequently metrics are collected. The troubleshooting guide added recently may also help with debugging steps and known issues, and it's recommended to use CloudNativePG 1.27.0 or later for improved error handling and status reporting for the plugin-barman-cloud source. No obvious memory leaks or busy loops were found in the main backup logic, but profiling the sidecar process could help pinpoint the source of the resource usage.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[dragoangel]

closing as duplicate of #385