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.
Requires chart version
5.5.0Recommended values
Apply the following helm chart values.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 theTS_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.
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.This is deliberately lower than the 1 GB-per-workload guidance on the
Persistent Storage
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.

