Reading autoscaler suggestions

Why this matters in production

autoscale-status is one of the few Ceph commands that shows you its work. Every number the module used to reach a recommendation is in the table. If you can read it, you can tell in seconds whether a recommendation reflects reality or reflects a pool that was created yesterday and has 40 MB in it.

The table

ceph osd pool autoscale-status

POOL         SIZE  TARGET SIZE  RATE  RAW CAPACITY  RATIO  TARGET RATIO  BIAS  PG_NUM  NEW PG_NUM  AUTOSCALE  BULK
.mgr         1.2M               3.0        437.0T  0.0000                1.0       1              on         false
rbd-vms     18.4T               3.0        437.0T  0.1263                1.0     512         1024  warn       false
ec-archive  61.0T               1.5        437.0T  0.2094                1.0    1024              on         true

RATE 1.5 on ec-archive above is a k=4, m=2 profile: six raw bytes per four user bytes.

Reading a recommendation

The module targets roughly 100 PGs per OSD across all pools. It divides that budget between pools in proportion to how much of the cluster each one occupies — RATIO, or TARGET RATIO if you declared one — then rounds to a power of two.

So rbd-vms above holds 12.6% of raw capacity and is being told to go from 512 to 1024 PGs. Either the pool grew, OSDs were added, or another pool shrank. The table tells you which, because all three inputs are right there.

When the inputs are wrong

The classic bad recommendation: a brand-new pool.

POOL       SIZE  RATE  RAW CAPACITY  RATIO  PG_NUM  NEW PG_NUM
new-pool   40M   3.0        437.0T  0.0000      32           1

The module sees a pool holding effectively nothing and proposes the minimum. It is arithmetically correct and operationally wrong — you created that pool because you are about to put 30 TB in it. The fix is not to argue with the module; it is to tell it what you know:

ceph osd pool set new-pool target_size_ratio 0.20

Quiz

Production discipline

Read autoscale-status before and after any change to pool layout, device classes, or OSD count — all three move RAW CAPACITY and therefore every recommendation in the table. Keep a note of pools where you deliberately overrode the module, and why; the next operator will see a pool at 4× the recommended PG count and needs to know it was a decision rather than an accident.

Cross-course references

• Kubernetes: a StorageClass pointing at a new Ceph pool should have target_size_ratio set before the first PVC lands
• Linux: reading a table of derived values back to its inputs is the same skill as reading vmstat fields