chore: bump sandbox cpu and memory limits

[wenxi-onyx]

Description

Note: there is no quota constraint on limit vs request

sandbox-nodes-firewalled Nodegroup Resources

Total Nodegroup Capacity:

• 5 nodes × 8 cores = 40 total CPU cores
• 5 nodes × ~30 GB = ~150 GB total memory
• Current utilization: ~1% CPU, 14-18% memory (all pods synced and basically dormant, maybe some use)

Per-Node Resources:

• CPU Allocatable: 7.91 cores (7910m)
• Memory Allocatable: ~29.9 GB (30624976Ki)
• Current CPU requests: 19-26% reserved per node
• Available burst capacity: ~5.8-6.3 cores per node

Changes: file-sync Sidecar Resource Limits

Updated the file-sync sidecar container to enable faster S3 downloads during pod initialization:

Previous:

• CPU limit: 1 core
• Memory limit: 4 GB
• Init time: ~22 minutes for 850 MB (145k files)

New:

• CPU limit: 8 cores
• Memory limit: 8 GB
• Expected init time: ~4-6 minutes (4-5x faster)

Rationale:

• Uses s5cmd with high parallelism (100+ concurrent workers)
• Sidecar only bursts during initialization, then idles
• Low CPU requests (500m) ensure efficient pod scheduling
• Nodes are currently underutilized with ample burst capacity

How Has This Been Tested?

Additional Options

• [Required] I have considered whether this PR needs to be cherry-picked to the latest beta branch.
• [Optional] Override Linear Check

---

Summary by cubic

Increase Kubernetes sandbox pod resource limits to reduce CPU throttling and OOMs during heavier workloads.

Limits raised from 1000m CPU to 4000m and from 4Gi memory to 6Gi; requests increased from 50m CPU/128Mi to 250m CPU/256Mi.

^{Written for commit 47b06df. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 1 file

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adjusts Kubernetes resource limits for the sandbox pod’s S3 sync sidecar container, increasing its CPU and memory limits. The change is localized to the pod spec construction in backend/onyx/server/features/build/sandbox/kubernetes/kubernetes_sandbox_manager.py and affects how sandboxes schedule and consume cluster resources under quota/LimitRange constraints.

Confidence Score: 4/5

• This PR is likely safe to merge, but the new limits can break scheduling in quota-constrained clusters.
• Change is a single resource-limit bump in the Kubernetes pod spec; main risk is operational (pods becoming unschedulable or crowding other workloads) depending on cluster ResourceQuota/LimitRange and autoscaling behavior.
• backend/onyx/server/features/build/sandbox/kubernetes/kubernetes_sandbox_manager.py

Important Files Changed

Filename	Overview
backend/onyx/server/features/build/sandbox/kubernetes/kubernetes_sandbox_manager.py	Bumps the S3 sync sidecar container resource limits from 1000m/4Gi to 8000m/8Gi; no other logic changes.

Sequence Diagram

sequenceDiagram
  participant Caller as Build/Session Manager
  participant KSM as KubernetesSandboxManager
  participant K8s as Kubernetes API Server

  Caller->>KSM: provision(user/session)
  KSM->>K8s: Create Pod (sandbox + s3-sync sidecar)
  Note over KSM,K8s: PR bumps sidecar limits to 8000m CPU / 8Gi RAM
  K8s-->>KSM: Pod scheduled (or rejected by quota/LimitRange)
  Caller->>KSM: exec incremental sync / workspace ops
  KSM->>K8s: kubectl exec into sidecar/sandbox
  K8s-->>KSM: command output
  Caller-->>KSM: terminate()
  KSM->>K8s: Delete Pod

Loading

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}