> ## Documentation Index
> Fetch the complete documentation index at: https://docs.regatta.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Resources & Scheduling

> Size CPU and RAM for the SM and RDB Pods, and control where they are scheduled.

## Configure CPU and RAM

`spec.resources.sm` and `spec.resources.rdb` set the total CPU and RAM for the SM Pod and every RDB Pod.

| Field                                         | Required                                | Description                             |
| --------------------------------------------- | --------------------------------------- | --------------------------------------- |
| `spec.resources.sm.requests.cpu` / `.memory`  | Required if `spec.resources.sm` is set  | Requested CPU and RAM for the SM Pod    |
| `spec.resources.sm.limits.cpu` / `.memory`    | Required if `spec.resources.sm` is set  | CPU and RAM limits for the SM Pod       |
| `spec.resources.rdb.requests.cpu` / `.memory` | Required if `spec.resources.rdb` is set | Requested CPU and RAM for every RDB Pod |
| `spec.resources.rdb.limits.cpu` / `.memory`   | Required if `spec.resources.rdb` is set | CPU and RAM limits for every RDB Pod    |

If you omit `spec.resources.sm`/`spec.resources.rdb`, the operator applies fixed minimums for both requests and limits: `6` CPU / `1200M` memory for the SM Pod, `4` CPU / `8000M` memory for every RDB Pod. Values below these minimums are rejected.

CPU and memory values use standard Kubernetes quantity notation:

* CPU: a whole or fractional number of cores, for example `"2"` for 2 cores or `"0.5"` for half a core; or millicores using an `m` suffix, for example `"500m"`, which equals `0.5` cores. `1000m` equals one full core.
* Memory: a number followed by a size suffix. Binary suffixes `Ki`, `Mi`, `Gi`, and `Ti` are powers of 1024, for example `"512Mi"` or `"8Gi"`. Decimal suffixes `k`, `M`, `G`, and `T` are powers of 1000, for example `"500M"`. There is no plain `MB` unit; use `Mi` or `M` explicitly.

This quantity notation applies to `spec.resources.*.requests/limits.memory` and `.cpu` only. The module-level `ram_MB` field (for example `spec.rdb.ram_MB`) is different: it is a plain integer number of megabytes, for example `16000`, not a Kubernetes quantity string.

If you set `num_threads` or `ram_MB` on a module, `spec.resources` for that module's Pod must cover the combined totals: `spec.resources.sm` for modules in the SM Pod, `spec.resources.rdb` for modules in the RDB Pod. SNA counts toward both, since it runs in every Pod type.

There is no separate field to size RegattaDB's memory-backed `/dev/shm` volume: the operator sets its `sizeLimit` equal to the same component's effective `requests.memory` (`spec.resources.sm.requests.memory` for the SM Pod, `spec.resources.rdb.requests.memory` for every RDB Pod).

### Schedule Pods

Use `spec.resources.sm.scheduling` and `spec.resources.rdb.scheduling` to influence where the operator's SM and RDB Pods run. These are standard Kubernetes Pod scheduling settings; omit any setting you do not need:

| Field                       | Effect                                                                                               |
| --------------------------- | ---------------------------------------------------------------------------------------------------- |
| `nodeSelector`              | Requires the Pod to run on a node with all listed labels.                                            |
| `tolerations`               | Allows the Pod to run on nodes with matching taints; tolerations do not select a node by themselves. |
| `affinity`                  | Sets Kubernetes node-affinity, Pod-affinity, or Pod-anti-affinity rules.                             |
| `topologySpreadConstraints` | Controls how matching Pods are distributed across topology domains such as zones or nodes.           |

For example, this places RDB Pods only on nodes labeled for database workloads, tolerates a matching taint, and spreads matching RDB Pods across availability zones:

```yaml theme={null}
spec:
  resources:
    rdb:
      scheduling:
        nodeSelector:
          workload: database
        tolerations:
          - key: workload
            operator: Equal
            value: database
            effect: NoSchedule
        topologySpreadConstraints:
          - maxSkew: 1
            topologyKey: topology.kubernetes.io/zone
            whenUnsatisfiable: DoNotSchedule
            labelSelector:
              matchLabels:
                app.kubernetes.io/component: rdb
```

The same fields and structure can be placed under `spec.resources.sm.scheduling` to apply to the combined SM Pod. Affinity, tolerations, and topology spread constraints use Kubernetes PodSpec syntax; refer to your Kubernetes documentation for available operators and details.

## CPU and RAM: scheduling behavior

Kubernetes uses `requests` to decide where a Pod can run, and `limits` to cap what it can use once running:

* If no Kubernetes node has enough unreserved CPU or memory to satisfy your `requests`, Kubernetes will not schedule the Pod there. A Pod stuck `Pending` while otherwise healthy often means no node currently has enough spare capacity.
* A CPU limit is enforced by throttling: a container that tries to use more CPU than its limit is slowed down, not killed.
* A memory limit is a hard ceiling: if a container tries to use more memory than its limit, Kubernetes kills it (OOM-killed) and restarts it. This is generic Kubernetes behavior that applies to any container, not something specific to RegattaDB.

`num_threads` and `ram_MB` are RegattaDB application-level settings: they tell RegattaDB how much CPU and RAM to plan for internally, per module. Both are optional - if you leave them unset, RegattaDB's System Manager assigns them automatically.

`spec.resources` is a separate, Kubernetes Pod-level setting: it is the boundary Kubernetes enforces around the whole container. Unlike `num_threads`/`ram_MB`, nothing auto-detects this for you, because the operator has no way to discover your Kubernetes node hardware. If you omit `spec.resources.sm`/`spec.resources.rdb`, the operator applies the fixed minimums from Configure CPU And RAM above, so RegattaDB Pods always get a real Kubernetes QoS guarantee - never `BestEffort`. Size them explicitly when your workload needs more than those minimums, even though you are not required to size every individual module's `num_threads`/`ram_MB` to do so. If you do set `num_threads`/`ram_MB`, `spec.resources.sm`/`spec.resources.rdb` must at least cover their combined totals; RegattaDB's own processes account for the headroom they need within that allocation.