Sizing

Use this page to size the cluster and the data services before you order them. The numbers are estimates from a reference installation with about 300 license servers. Your site's activity can differ, so check the real use after one to three months and adjust. See Check and adjust.

What to collect

Collect these numbers about your site first:

Input	Where to find it	Why it matters
S: license servers you monitor	Your license administrators. Count each vendor daemon or port once.	Drives usage data, Kafka traffic and database growth
U + W: users and workstations	The scope of your directory synchronization	Drives the MongoDB size
Y: years of history to keep	Your reporting needs	Drives the SQL Server size
R: Kafka message retention, in days	14 recommended (the Kafka default is 7). In this release, OpenLM Platform sets 3 days on its data-pipeline topics itself, so the 14 days apply to the topics without their own setting.	Drives the Kafka disk
Products	The components you switch on in step 4: the standard set, plus any others you add	Drives CPU and memory
Data services	Your own servers or managed services, or inside the cluster	Adds cluster capacity when they run inside

The number of license servers matters more than the number of users. A site with 1,200 users and 40 license servers needs more than a site with 5,000 users and 10.

Cluster capacity

Size the workers with two rules and take the larger result. Both rules assume the data services run outside the cluster.

By license servers

The data-processing jobs that prepare reporting data grow with the usage data, so the license-server count sets the worker size. Find your count in this table:

License servers (S)	Workers
Fewer than 100	3 × 8 vCPU / 32 GiB
100 to 199	3 × 12 vCPU / 48 GiB
200 or more	3 to 4 × 16 vCPU / 64 GiB

By the components you switch on

This rule sets the floor for any site:

Item	Estimate
vCPU	2 × the CPU the pods request. The standard set requests about 10 vCPU, so plan at least 24 vCPU. Add 4 vCPU for each additional data-processing job you switch on beyond the standard set.
Memory	1.25 × the memory the pods can use at most (their limits), rounded up to whole nodes. The standard set's limits add up to about 55 GiB, so plan at least 96 GiB.
Workers	At least 3 workers, so that you can drain one for maintenance, each with at least 8 vCPU / 32 GiB.

The data-processing jobs cause the peaks. Several of them run at the same time, each with 2 to 5 vCPU. Most of the time OpenLM Platform uses far less: a test system with about 85 pods used about 1 vCPU and 16 GiB.

Data services inside the cluster

If the data services run inside the cluster, add 32 GiB of memory and 6 to 8 vCPU. That covers these services:

• MongoDB: at least 8 GiB.
• Kafka: 4 to 6 GiB.
• Redis: 1 GiB.
• SQL Server, if it runs in the cluster too: about 16 GiB and 4 vCPU.

Their volumes need fast ReadWriteOnce storage, sized as in Data services.

Every node needs fs.inotify.max_user_instances of at least 8192. See Requirements.

Data services

Estimate the size of each data service with these formulas:

Service	Estimate	Notes
SQL Server (all four databases)	max(50 GB, 2 × (2 GB + 0.072 GB × S × Y))	Grows by about 0.006 GB per license server per month. Reporting needs 2 vCores. Plan 4 for heavy dashboards.
Kafka disk	max(20 GB, 1.25 × (0.048 GB × S × R + 3 GB))	Set a size limit on each topic, so retention can't fill the disk.
MongoDB	max(20 GB, 2 × (1 GB + 0.22 GB per 1,000 users and workstations))
Redis	1 to 2 GB of memory	Cache only, no persistent data

If you report from Power BI in DirectQuery mode, use incremental refresh once the usage tables pass about 100 million rows, whatever the SQL Server size.

Examples

The following table applies the formulas to three sites:

Site	S	U + W	Y	R	SQL Server	Kafka	MongoDB	Workers (data services outside)
Small, about 1,200 users	30	3,000	5	14	50 GB	30 GB	20 GB	3 × 8 vCPU / 32 GiB
Medium	100	20,000	5	14	80 GB	90 GB	20 GB	3 × 12 vCPU / 48 GiB
Large	300	90,000	5	14	220 GB	250 GB	42 GB	3 to 4 × 16 vCPU / 64 GiB

With the data services inside the cluster, add 32 GiB of memory and 6 to 8 vCPU to each example.

Check and adjust

These factors come from one large installation, and activity per license server varies: sites with heavy CAD or EDA use generate more sessions. After one to three months, compare the real figures with the estimate and resize. Check these figures:

• Database growth: the size of the four databases, month on month.
• Kafka disk: the space the broker uses, against its limit.
• Cluster: kubectl top nodes at busy times, and whether pods are pending or restarted for lack of memory.