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

# Tuning for Large Clusters

> Helm chart settings for clusters with 5,000 or more AIScaleTargets.

The chart defaults are sized for small installs. Once a cluster has around 5,000
enrolled `AIScaleTargets` (ASTs), a handful of values need to change to keep
Thoras ahead of the load.

The configuration below is sized for 5,000 ASTs and was validated on a cluster
with over 6,000. Expect Thoras to peak at roughly **100 cores** and **75 GiB of
memory**. Steady-state usage is significantly lower. The peak is a short burst
that occurs once every training interval (12h by default). Below roughly 5,000
ASTs the defaults are sufficient and none of this is required.

<Note>Requires chart version `5.5.0`</Note>

## Recommended values

Apply the following helm chart values.

```yaml theme={null}
featureFlags:
  thorasManageThoras:
    mode: autonomous
    metricsCollectorFollowsMode: false

thorasWorker:
  replicas: 2
  queriesPerSecond: "100"
  postgresql:
    maxConns: 40
    maxConnLifetime: 15m

thorasApiServerV2:
  replicas: 3
  postgresql:
    maxConnLifetime: 15m

thorasForecast:
  trainingJitterMinutes: 120
  worker:
    scaler:
      maxReplicas: 150

metricsCollector:
  persistence:
    # Size at roughly 200 MiB per AST; see "Storage" below. 1Ti covers
    # ~5,000 ASTs.
    pvcStorageRequestSize: "1Ti"
  timescale:
    requests:
      # TS_TUNE_NUM_CPUS below reads this value, so it must be a whole core
      # count, not millicores.
      cpu: "8"
      memory: 30Gi
    limits:
      memory: 30Gi
  env:
    - name: TS_TUNE_NUM_CPUS
      valueFrom:
        resourceFieldRef:
          containerName: timescaledb
          resource: requests.cpu
          divisor: "1"
    - name: TS_TUNE_MAX_CONNS
      value: "500"
```

## Applying to an existing install

The database tunes itself only when its volume is first initialized, so
deploying the new values alone will not apply the `TS_TUNE_*` settings to an
existing install. Once the new values have rolled out, rerun the tuner and
restart the database pod. Replace `thoras` with your release namespace if it
differs.

```sh theme={null}
kubectl -n thoras exec deploy/metrics-collector -c timescaledb -- \
  /docker-entrypoint-initdb.d/001_timescaledb_tune.sh
kubectl -n thoras delete pod -l app=metrics-collector
```

The database is unavailable for a short time while the pod restarts. Neither
step is needed on a fresh install.

## Thoras components

Autonomous mode lets Thoras rightsize its own components as load grows, so you
do not have to hand-tune their requests.

The database is the exception. `metricsCollectorFollowsMode: false` keeps it in
observation mode, and its resources are set explicitly under
`metricsCollector.timescale` above. Changing its resources requires a restart,
which is disruptive to the database and to the Thoras platform.

## Kubernetes API load

Kubernetes API load from the worker is about 2.4 requests per AST per minute
(\~200/s at 5,000 ASTs, scaling linearly). Budget for it if you run a fixed-size,
self-managed control plane.

## Storage

At scale, plan on roughly **200 MiB per AST**, or about 1 TiB for 5,000 ASTs.

<Note>
  This is deliberately lower than the 1 GB-per-workload guidance on the
  [Persistent Storage](/installation/persistent-storage#understanding-usage)
  page. That rule is sized for small installs, where oversizing is harmless and
  buys IOPS on cloud block storage. At thousands of ASTs it is excessive (it
  would call for 5 TiB or more at 5,000 ASTs) and incurs real cost.
</Note>

See [Persistent Storage](/installation/persistent-storage) for storage class,
EFS, and existing-volume configuration.

## Questions?

For help, email [support@thoras.ai](mailto:support@thoras.ai).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.