Skip to content

Document memory limits and introduce configurable runtime limits #331

@butschster

Description

@butschster

Currently, Buggregator may consume a significant amount of memory when processing multiple or large profiles. This can lead to container instability or crashes if no explicit memory limits are configured (as reported by users running the Docker image).

See buggregator/frontend#280

Problems

  • No clear guidance in the documentation about recommended memory limits.
  • Memory usage can grow significantly with large profiling datasets.
  • Users are forced to manually configure container limits without knowing best practices.

Proposed improvements

  1. Documentation updates

    • Add a section describing recommended memory limits for Docker deployments.
    • Provide example configurations (e.g., docker-compose) with resources.limits.memory.
    • Explain how profiling size impacts memory consumption.
  2. Runtime memory control (Go level)

    • Investigate adding configurable memory limits at the application level.

    • Consider using mechanisms such as:

      • GOMEMLIMIT (Go runtime memory limit)
      • Periodic cleanup / GC tuning
      • Limiting the number or size of stored profiles in memory
    • Optionally introduce configuration parameters (env variables) to control:

      • Max number of stored profiles
      • Max size per profile
      • Retention policy (drop oldest data)
  3. Optional safeguards

    • Add warnings or logs when memory usage approaches limits.
    • Gracefully degrade (e.g., drop older profiling data) instead of crashing.

Goal

Make memory usage predictable and controllable, improve stability, and provide clear guidance for users running Buggregator in production or with heavy profiling workloads.

Metadata

Metadata

Assignees

Labels

Type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions