Capacity Planning and Sizing for Cribl Stream

What sizing depends on

The Sizing and Scaling page frames scaling around four outcomes: increased data volumes of any size, increased processing complexity, increased deployment availability, and an increased number of destinations. Resource use is proportional to the type of processing: a Function that adds a static field on an event will likely perform faster than one applying a regex find and replace.

Every figure assumes a core model: a Worker Process utilizes up to 1 physical core (1 or 2 vCPUs), performance is proportional to CPU clock speed, and all processing happens in memory, without significant disk. 1 physical core equals 2 virtual/hyperthreaded CPUs (vCPUs) on Intel/Xeon or AMD processors, and 1 vCPU on Graviton2/ARM64 processors.

Heap memory is consumed per Worker Process by lookups and by stateful Functions (Aggregations, Dynamic Sampling, and Suppress), proportional to data throughput. External memory, outside the heap limit, goes mainly to Destinations.

The scaling levers

A Cribl Stream installation scales up within one instance and/or out across many, with controls per deployment shape: the Sizing Calculator under Group Settings, Group Configuration for Cribl.Cloud Worker Groups; Settings, System, Service Processes, Processes for single-instance; and per Worker Group for distributed or hybrid groups.

In on-prem deployments, three Worker Process settings control the allocation:

• Process count: positive numbers specify an absolute number of Workers, negative numbers a number relative to the CPUs in the system. The default is -2.
• Minimum process count: the floor for spawned Worker Processes; a 0 entry is interpreted as "default," which yields 2 Processes.
• Memory (MB): heap memory per Worker Process, defaulting to 2048 and allocated dynamically from the OS. It does not govern external memory.

Which Process count to run depends on the environment, per the Choose a Process Count recommendations:

• x86 (with Hyperthreading): -2 (default), reserving headroom for system/API overhead.
• Non-Hyperthreaded CPUs (such as, ARM Graviton, AWS c7a): -1, reserving one physical core for overhead; each Worker Process uses up to one physical core.
• Containers/Kubernetes: a positive value (such as 4) and/or CRIBL_MAX_WORKERS, since negative values are computed relative to the vCPUs visible to the container (or to CRIBL_K8S_CPU_LIMIT when set).
• Syslog Source LB Enabled: reduce effective Process Count by 1, reserving an additional core for the load balancer process when the Syslog Source's internal TCP load balancer is active.

On the page's example host (6 physical cores hyperthreaded, 12 vCPUs), Process count 4 spawns exactly 4 processes; -2 spawns 10 processes (12-2). Changes need Save, then a restart via Settings, Global, System, Controls, Restart, and in a distributed deployment, deploying the changes to the Groups.

For containers, CRIBL_MAX_WORKERS caps the Worker Process count for the container; the final count is the lowest of the Cribl license limit, the actual Worker Processes (with Process count factored in), the cribl.yml count, and CRIBL_MAX_WORKERS. From the Allocate a Maximum Number of Worker Processes section:

License limit: 7
Number of actual Worker Processes (OS based): 4, calculated as number of actual Worker Processes (6) and Process count (-2)
Worker Processes in cribl.yml: 5
CRIBL_MAX_WORKERS: 3

There are three final assigned Worker Processes, because 3 is the lowest number of all the values above.

Scaling out, the deployment spans multiple Nodes in a distributed deployment when a single instance cannot sustain the volume, managed centrally from one administrator instance called the Leader. Worker Processes operate in parallel: data on a single connection is handled by a single Worker Process, so data should arrive over multiple connections (five to TCP 514 at 200GB/day each beat one at 1 TB/day).

Reading the numbers

The general sizing guideline: plan for a maximum of 200 GB/day in+out per vCPU when hyperthreading is enabled (2 vCPUs per physical core on Intel/AMD), which at its simplest can equate to 100 GB/day in, 100 GB/day out when sending full-fidelity data to a single Destination.

For Intel/Xeon/AMD with hyperthreading, sum expected input and output volume, then divide by 400GB per day per physical core, per the Estimating Number of Cores examples:

• 100GB IN → 100GB out to each of 3 destinations = 400GB total = 1 physical core (or 2 vCPUs).
• 3TB IN → 1TB out = 4TB total = 10 physical cores (or 20 VCPUs).
• 4 TB IN → full 4TB to Destination A, plus 2 TB to Destination B = 10TB total = 25 physical cores (or 50 vCPUs).

On Graviton2/ARM64, 1 physical core is 1 vCPU, with overall throughput about 20% higher than a corresponding Intel or AMD vCPU; the same totals divide by 480GB per day per vCPU, plus an additional core per Worker Node for OS/system overhead.

Node bounds, per the Estimating Number of Nodes section: at least 4 ARM vCPUs, or at least 8 x86 vCPUs (i.e., 4 cores with hyperthreading), per Node; below this threshold, OS overhead from reserved threads claims an excessive percentage of capacity. No more than 48 ARM vCPUs, or 48 x86 vCPUs (i.e., 24 cores with hyperthreading); that allocation handles disk I/O requirements when persistent queueing engages. Plan for peak workloads even with 20% of Worker Nodes down, and in the 5-20 TB range, size for 4-8 Worker Nodes per Worker Group.

Per the Estimating Memory Requirements section: start with the default heap memory allocation of 2048 MB (2 GB) per Worker Process, adding more as you hit limits. Since version 4.13, baseline memory usage may increase on hosts that are not memory-constrained. A Splunk LB Destination may use up to 4 MB of memory for each indexer, so one with 300 indexers could require 1.2 GB of extended memory per process.

Cloud instances: meet sizing requirements with multiples of the listed families, reserving at least 5GB disk per instance, more if you enable persistent queuing; AWS and Azure list two architecture rows, GCP one Intel row. Values from the Recommended AWS, Azure, and GCP Instance Types section, as published:

What the docs flag

The caveats attached to these levers and numbers:

• Unpinned containers inherit a loose default. The Worker Process count defaults to -2 (Worker Processes (CPU cores) = total CPU cores - 2), and a container launched without CRIBL_MAX_WORKERS inherits it, which can lead to inefficient resource usage, particularly on machines with many CPU cores.
• Excess Worker Processes are a stability risk. Improper configuration can lead to unstable container deployments, or to Cribl crashing and service outages.
• Out of memory is a diagnostic. The error logs to $CRIBL_HOME/log/cribl_stderr.log and indicates either a memory leak or that the memory setting is too low for the workload. Cribl support can help troubleshoot.
• Hypervisors need reservations. On VMware or other hypervisors, prefer CPU and memory reservations or equivalent guarantees; heavy overcommit can reduce effective throughput and increase tail latency, and live migration can cause brief pauses. The docs publish no specific reservation, overcommit, or migration policies.
• Leaders are not sized by events. Leader capacity follows managed components and concurrent administrators, not event throughput, and the sizing guidance baselines Worker and Leader Nodes unless your topology or control-plane load clearly differs.

Frequently asked questions

How many Worker Processes does Cribl Stream spawn by default?

Cribl Stream sets the Worker Process count to -2 by default, total CPU cores minus 2. On the page's 12 vCPU example host it spawns 10 processes, while an absolute value such as 4 spawns exactly 4. Changes require Save and a server restart, plus deploying changes to the Groups in a distributed deployment.

How do I estimate the cores a Cribl Stream deployment needs?

Sum expected input and output volume, then divide by 400GB per day per physical core on Intel/Xeon or AMD processors with hyperthreading, or by 480GB per day per vCPU on Graviton2/ARM64. So 3TB in plus 1TB out is 4TB total: 10 physical cores (or 20 VCPUs) on Intel or AMD. Add one core per Worker Node for OS/system overhead.

What are the per-Node vCPU bounds Cribl recommends for Cribl Stream?

Cribl recommends at least 4 ARM vCPUs, or at least 8 x86 vCPUs (4 cores with hyperthreading), per Node, and no more than 48 ARM vCPUs, or 48 x86 vCPUs (24 cores with hyperthreading). Below the floor, OS overhead from reserved threads claims an excessive percentage of capacity, and the ceiling handles disk I/O when persistent queueing engages. In the 5-20 TB range, size for 4-8 Worker Nodes per Worker Group.

How much heap memory should a Cribl Stream Worker Process get?

Start with the default heap memory allocation of 2048 MB (2 GB) per Worker Process, adding more as you hit limits. Heap memory is consumed by lookups and by stateful Functions such as Aggregations, Dynamic Sampling, and Suppress, proportional to data throughput. Since version 4.13, baseline memory usage may also increase on hosts that are not memory-constrained.