> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/resource-limits.md).
# Resource allocation
Understand container resource allocation, configure resource limits, and troubleshoot resource issues.
This topic describes container resource allocation logic, how you can configure resource limits (if possible for your build infrastructure), and troubleshooting issues related to resource allocation.
{% hint style="info" %}
**Resource requests feature flag**
The ability to set resource requests is behind the feature flag `CI_SUPPORT_RESOURCE_REQUESTS`. To enable it, contact [Harness Support](mailto:support@harness.io).
Enabling this flag lets you define Kubernetes *resource requests* (not just limits) for individual build steps. This helps Kubernetes schedule pods more efficiently and can improve stability for resource-intensive steps (for example, large Build & Push steps) by reducing the risk of pod evictions or out-of-memory (OOM) kills.
{% endhint %}
### What you will learn from this topic
By the end of this topic, you will understand:
* How resource requests and limits affect build pods
* How to override resource limits for individual steps
* How Harness calculates resource requirements for parallel and sequential steps
### Before you begin
Before you configure resource limits, identify your build infrastructure. **Set Container Resources** settings are unavailable for self-managed VM and Harness Cloud build infrastructures.
### Build pod resource allocation
Build pod resources are defined in terms of *requests* and *limits*.
* **What are Kubernetes container requests?** Containers are guaranteed to get requests. If a container requests a resource, Kubernetes only schedules it on a node that can give the container the requested resource.
* **What are Kubernetes container limits?** This defines the upper limit for resource consumption by a Kubernetes container. When the container uses more than the defined limit, Kubernetes evicts the pod.
Go to [Resource requests and limits](https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-resource-requests-and-limits) to understand Kubernetes resource requests and limits.
In Harness, by default, resource requests are always set to the minimum, and additional resources are requested only as needed during build execution, depending on the [resource request logic](#resource-request-logic-and-calculations). Resources are not consumed after a step's execution is done.
Default resource minimums (requests) and maximums (limits) are as follows:
| Component | Minimum CPU | Maximum CPU | Minimum memory | Maximum memory |
| ----------------------------------------------------------------- | ----------- | ----------- | -------------- | -------------- |
| Steps | 10m | 400m | 10Mi | 500Mi |
| Add on (execution-related steps on containers in Kubernetes pods) | 100m | 100m | 100Mi | 100Mi |
### Do not use LimitRange policies to constrain limits
[LimitRange policies](https://kubernetes.io/docs/concepts/policy/limit-range/) set on your Kubernetes cluster can interfere with build pod scheduling. **Do not use LimitRange policies to constrain limits.**
If you choose to use a LimitRange policy, use only the `defaultRequest` policy. Do not use policies that constrain limits, such as `max` and `min`.
### Override resource limits
For an individual step, you can use the **Set Container Resources** settings to override the maximum resources limits:
* **Limit Memory:** Maximum memory that the container can use. You can express memory as a plain integer or as a fixed-point number with the suffixes `G` or `M`. You can also use the power-of-two equivalents, `Gi` or `Mi`. Do not include spaces when entering a fixed value. The default is `500Mi`.
* **Limit CPU:** The maximum number of cores that the container can use. CPU limits are measured in CPU units. Fractional requests are allowed. For example, you can specify one hundred millicpu as `0.1` or `100m`. The default is `400m`. Go to [Resource units in Kubernetes](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) to understand resource units.
{% hint style="info" %}
**Unavailable build infrastructures**
**Set Container Resources** settings are not available for self-managed VM or Harness Cloud build infrastructures.
{% endhint %}
To increase all default resource limits, you can contact [Harness Support](mailto:support@harness.io) to enable the feature flag `CI_INCREASE_DEFAULT_RESOURCES`. This feature flag increases maximum CPU to 1000m and maximum memory to 3000Mi.
To restrict add on (lite engine) resources, you can contact [Harness Support](mailto:support@harness.io) to enable the feature flag `CI_CONSERVATIVE_K8_RESOURCE_LIMITS`. This feature flag sets lite engine resource limits to the default minimum (100m CPU and 100Mi memory).
### Resource request logic and calculations
Limit and request values are based on steps being parallel or sequential. Parallel steps sum the resources for each parallel step, and sequential steps take the maximum resources needed amongst the sequential steps.
The total computed resource requirements are set as the limit and request values for the stage container (also referred to as the Lite-Engine). For example, if total CPU is 600m, then the stage container's memory limit and request values are both set to 600m. This ensures selection of appropriately-sized pods, and it avoids over- or under-utilization of resources.
#### Resource calculation examples
### Troubleshooting
Go to the [CI Knowledge Base](/continuous-integration/troubleshooting-and-resources/ci-articles-and-faqs/continuous-integration-faqs.md) for questions and issues related to resource allocation and build infrastructure, such as:
#### CI pods appear to be evicted by Kubernetes autoscaling
Harness CI pods shouldn't be evicted due to autoscaling of Kubernetes nodes because [Kubernetes doesn't evict pods that aren't backed by a controller object](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-types-of-pods-can-prevent-ca-from-removing-a-node). However, build pods can be evicted due to:
* **Resource pressure**: CPU or memory constraints in the pod or on the node
* **Spot instances**: Using spot/preemptible instances as worker nodes
* **Node conditions**: DiskPressure, MemoryPressure, or other node-level issues
If you notice either sporadic pod evictions or failures in the Initialize step in your [Build logs](/continuous-integration/use-harness-ci/use-harness-ci/viewing-builds.md), add the following [Annotation](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/k8s-build-infrastructure/set-up-a-kubernetes-cluster-build-infrastructure.md#annotations) to your [Kubernetes cluster build infrastructure settings](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/ci-stage-settings.md#infrastructure):
```yaml
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
```
**Monitor and debug pod evictions**
If you don't use monitoring products like CloudWatch, you can set up a DaemonSet-based monitoring solution to capture and persist CI pod events, logs, and descriptions. This helps with:
* Debugging OOM kills and resource issues
* Understanding why pods are being evicted
* Maintaining logs for older executions
Go to [Monitor CI pod events without CloudWatch](/continuous-integration/troubleshooting-and-resources/ci-articles-and-faqs/articles/monitor-ci-pod-events-without-cloudwatch.md) for detailed instructions on implementing this monitoring solution.
#### Docker Hub rate limiting
By default, Harness uses anonymous Docker access to pull Harness-required images. If you experience rate limiting issues when pulling images, try the solutions described in [Harness CI images - Docker Hub rate limiting](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/harness-ci.md#docker-hub-rate-limiting).
#### Use a parallel step to monitor failures
Go to [Use a parallel step to monitor failures](/continuous-integration/troubleshooting-and-resources/ci-articles-and-faqs/articles/parallel-step-for-logging.md) to monitor failures with a parallel step.
#### Change CPU or memory allocation for steps running on Harness Cloud
Unlike with other build infrastructures, you can't change the CPU/memory allocation for steps running on Harness Cloud. Step containers running on Harness Cloud build VMs automatically use as much as CPU/memory as required up to the available resource limit in the build VM.
#### Prioritize a build pod during host-node resource shortages
Use the [Priority Class](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/k8s-build-infrastructure/set-up-a-kubernetes-cluster-build-infrastructure.md#priority-class) setting to ensure that the build pod is prioritized in cases of resource shortages on the host node.
#### Out-of-memory error on the delegate Java heap
Check CPU utilization and try increasing the CPU request and limit amounts.
Your Java options must use [UseContainerSupport](https://eclipse.dev/openj9/docs/xxusecontainersupport/) instead of `UseCGroupMemoryLimitForHeap`, which was removed in JDK 11.
#### Out-of-memory errors with Gradle
Go to [Out of memory errors with Gradle](/continuous-integration/troubleshooting-and-resources/troubleshoot-harness-ci/gradle-daemon.md) to investigate Gradle memory errors.
#### DinD Background step fails after a Docker daemon disconnect or quota limit
This typically indicates that the DinD Background step doesn't have sufficient resources. Try modifying the [container resources for the Background step](/continuous-integration/use-harness-ci/use-harness-ci/manage-dependencies/background-step-settings.md#set-container-resources).
You can also [add a parallel Run step to monitor and help debug the Background step](/continuous-integration/troubleshooting-and-resources/ci-articles-and-faqs/articles/parallel-step-for-logging.md). For example, in this case it would help to use the Run step to monitor resource consumption by the Background step.
### Next steps
* [CI Knowledge Base](/continuous-integration/troubleshooting-and-resources/ci-articles-and-faqs/continuous-integration-faqs.md): Understand CI resource-allocation and build-infrastructure issues.
* [Build, push, upload, and download](https://developer.harness.io/continuous-integration/use-harness-ci/use-harness-ci/build-and-upload-artifacts): Actions to perform on your codebase and artefact.
{% @harness-feedback/feedback %}