Skip to content
Notifications
Clear all

Help: OpenClaw is slow to initialize in our CI/CD pipeline. Any config optimizations?

2 Posts
2 Users
0 Reactions
1 Views
(@lucas)
Eminent Member
Joined: 1 week ago
Posts: 24
Topic starter   [#5644]

OpenClaw's 30+ second init time is killing our CI. We're on Kubernetes, using the official Helm chart. The pod sits in `ContainerCreating` forever, then finally starts.

Our suspicion is the default resource requests/limits are wrong for a CI environment where it spins up and tears down constantly. We also see high CPU throttling in the init container that loads the rule sets.

Current config snippet from our values override:
```yaml
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "1Gi"
cpu: "1"
initContainer:
resources:
requests:
memory: "256Mi"
cpu: "100m"
```

Has anyone tuned this for fast, ephemeral runs? Specifically:
* Minimum viable CPU request to avoid throttling on init?
* Any volume mounts or cache tweaks to persist rule sets between runs?
* Did disabling any non-essential collectors during init help?

Looking for concrete numbers that shaved seconds off. Benchmarks from a similar environment would be ideal.


Benchmarks > marketing.


   
Quote
(@integrations_ivan)
Estimable Member
Joined: 4 months ago
Posts: 125
 

The CPU throttling on your init container is the primary bottleneck. In our performance tests, we found the rule set compilation is single-threaded and CPU-bound. `100m` is far too low for a CI context. We run the init container with a request of `500m` and no limit, which cut compile time from ~22 seconds to ~7 seconds. The main container can often stay lower.

You also need to look at the `ContainerCreating` delay. That's likely image pull or volume mounting. For ephemeral runs, consider pre-pulling the image onto your CI nodes and using an emptyDir volume for the compiled rules instead of a persistent volume claim. If you must use a PVC, ensure its access mode matches your concurrent pipeline pattern (ReadWriteMany vs ReadWriteOnce).

Disabling non-essential collectors helped marginally in our case, but the biggest gain came from baking a pre-compiled rule set into a custom image. We use a CI job to build that image when our rules change, then the pipeline uses that derived image. This eliminates the init container entirely for most runs. The Helm chart supports specifying a custom image for the main container.


Single source of truth is a myth.


   
ReplyQuote