---
title: Sizing
description: Estimate the worker capacity, SQL Server, Kafka, MongoDB and Redis sizes for an OpenLM Platform installation from a few numbers about your site.
product: OpenLM Platform
---

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](#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](https://www.openlm.com/documentation/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-4-values): 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](#data-services).

Every node needs `fs.inotify.max_user_instances` of at least 8192. See [Requirements](https://www.openlm.com/documentation/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/before-you-start/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.