Cyfin / Cyblock — Single-Box VMware Sizing Reference
VM on-prem deployment: syslog reception, ingestion, and report generation on one VM in the customer’s own environment. Cyblock adds live inline proxy traffic. Metric server sizing included separately. Result quality is identical to a split-tier deployment; the numbers below simply account for running these functions together.
All numbers are minimum production baselines (row 1 of each table) with headroom tiers above them. Scale up with log volume, report concurrency, and user count.
What to size for: concurrent workloads
In a VM on-prem deployment these functions run alongside each other, so provision for peak concurrency rather than any one job in isolation:
- Syslog reception — light CPU, network-bound; give it burst headroom so it never drops.
- Ingestion — CPU-active (parse + URL categorization lookups), heap allocation, disk writes.
- Report generation — CPU-active and heap-active; a large report can use every core and a lot of heap.
- Metric server — a distinct ES-backed process; include its resources when co-located.
The main case to plan for is a large report running during active ingestion — size so both run comfortably at the same time.
Cyfin (syslog + ingest + report)
| Tier | vCPU | RAM (heap ≈ half) | Notes |
|---|---|---|---|
| Minimum production | 4 | 8 GB (4 GB heap) | Light volume, few configs |
| Medium | 8 | 16 GB (8 GB heap) | Comfortable report-while-ingest concurrency |
| Heavy | 8–16 | 32 GB (12–16 GB heap) | Cores drive reporting parallelism |
Heap past ~12–16 GB gives diminishing returns and longer GC pauses. Allocation rate, not heap size, is usually the practical ceiling — size cores and heap together rather than heap alone.
Cyblock
Everything above, plus the proxy serves user browsing in real time, so keep cores available for it. Size the proxy piece by concurrent users / request rate on top of the ingest+report sizing, and give the proxy guaranteed CPU.
| Tier | vCPU | RAM | Notes |
|---|---|---|---|
| Minimum production | 4–6 | 12 GB | Proxy + modest reporting |
| Medium | 8 | 16–24 GB | Cores reserved for proxy |
| Heavy | 12–16 | 32 GB+ | Proxy connection state + category cache + report heap all resident |
Metric server (out-of-the-box)
Distinct process powering real-time metrics/dashboards. Sizing scales with metric retention and dashboard/query concurrency. Heap guidance: keep heap ≤ 50% of RAM and under ~31 GB; the remaining RAM benefits disk caching.
| Tier | vCPU | RAM (heap ≤ half) | Notes |
|---|---|---|---|
| Minimum production | 4 | 8 GB (4 GB heap) | SSD-backed; rest of RAM aids caching |
| Medium | 8 | 16 GB (8 GB heap) | Higher retention / more concurrent dashboards |
| Heavy | 8–16 | 32 GB (≤16 GB heap) | Large metric volume; keep heap ~31 GB or under |
When co-located, include the metric server’s resources in the box total, or give it its own CPU reservation.
VMware-specific guidance
- Match vCPU to physical cores and avoid host overcommit for these VMs. CPU ready / co-stop time is invisible inside the guest and slows reporting. Prefer fewer, well-scheduled vCPUs over a large oversized count.
- Set a memory reservation at (or near) full VM RAM so the JVM heap (product or metric server) is never ballooned or swapped — that keeps GC behavior predictable.
- Cyblock: set a CPU reservation/shares so the live proxy always has cycles regardless of concurrent reporting.
- Fast datastore — SSD-backed with PVSCSI. Report scans and metric-server indexing are disk-sensitive, so storage throughput is often the first thing to raise.
Note
To tighten these into a single recommendation, plug in the deployment’s log volume (GB/day or events/sec) and user count.