[Feature] Add Resource Limits for Container

[antonio-amjr]

Fix: #911
In combination with: project-chip/certification-tool-backend#327

Description

Add backend resource limits for Raspberry Pi 4 deployment

Changes

Backend CPU and memory limits (docker-compose.yml)
Added deploy.resources.limits to the backend service:

• cpus: '2.5' — caps the backend at 2.5 of the 4 available cores, preventing
  test execution from starving the OS, Docker daemon, and other services during
  heavy SDK test runs.
• memory: 1500M — prevents the backend from consuming all available RAM and
  forcing the OS to swap to SD card, which causes severe performance degradation
  on Raspberry Pi 4.

[gemini-code-assist]

Code Review

This pull request adds CPU and memory resource limits to the backend service in the docker-compose configuration. The review feedback highlights potential issues with hard-coding these limits, particularly on Raspberry Pi 4 devices with varying RAM capacities, and recommends making the limits configurable via environment variables to prevent OOM kills or restrictive caps.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[oxesoft]

A couple of small things worth double-checking before merge — nothing blocking, the core fix is sound and I confirmed docker compose config resolves the new deploy.resources.limits block correctly.

[oxesoft]

The PR description says memory is capped at 1500M, but the default here is 2000M (it was bumped in 718d282 when the hardcoded value became overridable via BACKEND_MEMORY_LIMIT). Could you confirm which value is actually intended and update the description to match? On the minimum supported spec (4GB RPi4 per docs/Raspberry Pi-Setup.md), the extra 500M meaningfully changes how much headroom is left for the OS + db/frontend/proxy containers.

[oxesoft]

BACKEND_CPU_LIMIT / BACKEND_MEMORY_LIMIT aren't documented anywhere (not in default.env, not in the Raspberry Pi setup doc). Since the point of making these configurable is to let users tune the caps for their own hardware, it'd help discoverability to add them to default.env — even commented out with the defaults shown — the way the other configurable vars in that file are presented.

[oxesoft]

Only backend gets resource limits; db, frontend, and proxy stay unbounded. If the goal is avoiding OS/swap pressure on the Pi, is backend-only scope intentional (i.e. it's the only service that spikes during SDK test runs), or worth a follow-up for the others too?