Compute and sizing

Overview

Use this guide to size the trace analyzer for production from a measured pilot, and to find the constraint to change when analysis falls behind. The analyzer uses compute to receive uploads, prepare traces, and run analysis. PostgreSQL stores ingestion and analysis state, the trace bucket stores session objects, and the repository mirror is disposable local storage.

Load depends on session size, agent activity, analysis duration, and model rate limits, so a developer count alone doesn’t give you a capacity target. Measure representative sessions on one analyzer replica before you change capacity.

Measure a pilot

In PIG 0.3.6, the supervisor runs one analyzer replica. It requests 500 millicores and 1 GiB of memory, with a 2 GiB memory limit. The manual Helm example uses the same values. Treat them as a pilot starting point. They don’t guarantee throughput.

1. Review the requests and limits on the generated analyzer Deployment:

   kubectl get deployment acme-analyzer --namespace pig \
     -o jsonpath='{.spec.template.spec.containers[*].resources}{"\n"}'

2. Run representative sessions from pilot hosts, and check current pod usage:

   kubectl top pods --namespace pig

   kubectl top requires your cluster’s metrics service.

3. In your existing monitoring system, record the measurements listed in Measure each constraint over the pilot.

Measure each constraint

Each constraint has its own measurements and its own place to adjust:

Constraint	Measure	Adjust
Analyzer compute	CPU saturation, memory peaks, restarts, processing time.	Kubernetes capacity and the supported workload configuration for your release.
Analysis throughput	Eligible sessions waiting, time to completion, model throttling.	Model quota and analysis capacity together.
PostgreSQL	Connections, query latency, storage growth, disk throughput.	Database size and capacity through Terraform.
Trace bucket	Uploaded bytes, object counts, request rates, retrieval errors.	Storage policy and network capacity; keep required objects available.
Repository mirror	Checkout size, temporary disk usage, refresh failures.	Node ephemeral storage and repository access.

Adding pods doesn’t clear a backlog caused by model throttling. Before you scale analysis, account for model quota and for the database connections each new replica opens.

Plan capacity for availability and upgrades

Use managed database availability and backups that meet your recovery objectives. Budget cluster capacity for migration Jobs and rolling releases on top of steady-state pods. Distribute workloads according to the release’s supported scheduling settings.

When an update needs more infrastructure, PIG blocks the update and reports the requirement. Apply the cloud change through Terraform, and PIG retries its live checks. For capacity PIG can’t inspect, such as managed database disk headroom, confirm the target release’s requirements from current provider metrics.

Don’t edit generated Deployments to change their resources. The supervisor reconciles those resources back to its configured values.

After any capacity change, repeat the complete-session checks you ran at installation.

See also

• Manage updates and recovery, for blocked updates and release capacity confirmations
• Model providers, for reserving model quota for analysis
• PostgreSQL, for the connections each analyzer replica opens
• Observability, for finding the stage where analysis stops making progress