pg calculator ceph

What is a PG calculator in Ceph?

A PG calculator for Ceph is a planning tool that helps you choose a sensible number of Placement Groups (PGs) for each storage pool. PG count strongly impacts data distribution, recovery behavior, and cluster balancing. Too few PGs can lead to uneven placement. Too many PGs can increase memory usage and operational overhead.

Even though newer Ceph releases include PG autoscaling, operators still use calculators for capacity planning, migrations, and understanding whether autoscaler recommendations align with workload reality.

Why PG sizing still matters

1) Data distribution quality

Ceph maps objects to PGs, then maps PGs to OSDs through CRUSH. More PGs generally means finer distribution granularity, which helps avoid hot spots.

2) Recovery and rebalance behavior

When OSDs are added, removed, or fail, PGs move and recover. PG count influences how much parallelism and overhead the cluster sees during these events.

3) Operational limits

Each PG has metadata and lifecycle states. Excessive PGs can tax monitors and OSD memory. Healthy operation is usually about balance, not maximizing any one number.

Core formula behind this calculator

This page uses a common planning heuristic:

raw_pg = (osd_count × target_pg_per_osd × pool_ratio) / redundancy_factor

• pool_ratio = pool share of total data (e.g., 0.40 for 40%).
• redundancy_factor = replica size for replicated pools, or k + m for erasure-coded pools.
• The result is then rounded to the nearest power of two for practical pg_num.

Historically, power-of-two PG counts were common practice for easier tuning and predictable growth. Modern Ceph can support broader values, but this convention is still widely used.

Interpreting the calculator output

Suggested pg_num and pgp_num

The tool returns a recommended pg_num and mirrors it to pgp_num. For most modern workflows, this is a good initial target when creating new pools.

Estimated PGs per OSD for the pool

You also get an estimated “PGs per OSD” contribution from that pool. This helps you validate whether one pool is disproportionately heavy compared to the rest.

Example planning scenario

Suppose you have 60 OSDs, a replicated pool of size 3, target 100 PGs/OSD, and this pool is expected to hold 50% of all data.

• Raw PG estimate: (60 × 100 × 0.5) / 3 = 1000
• Nearest power-of-two target: 1024
• This becomes a practical starting point for pg_num.

From there, monitor performance, data distribution, and recovery behavior before making further adjustments.

Best practices when using a Ceph PG calculator

• Prefer planning before pool creation, rather than repeated large PG splits later.
• If using autoscaler, compare manual estimate with autoscaler guidance instead of disabling it blindly.
• Adjust PGs gradually in production to avoid unnecessary churn.
• Account for future OSD growth; don’t size only for today’s topology.
• Keep a runbook for pool changes and recovery windows.

Common mistakes to avoid

• Using one fixed PG number for every pool regardless of data share.
• Ignoring erasure-code chunk counts when estimating redundancy impact.
• Over-optimizing for “perfect math” without validating real cluster behavior.
• Applying aggressive PG increases during peak production traffic.

Final thoughts

A good pg calculator ceph workflow combines simple estimation with real-world telemetry. Start with sound math, then validate with observed latency, balance, and recovery characteristics. In short: calculate, deploy carefully, measure, and iterate.