Healthcare IT Server & VM Sizing: The Practitioner's Guide

Introduction

Most clinical system performance incidents are not caused by bad software. They are caused by infrastructure that was sized against a vendor spreadsheet, deployed onto a shared virtualization cluster with no reservations, and never re-measured after go-live.

The pattern is predictable. The system performs acceptably during testing, when three people are using it. It degrades six weeks after go-live, when the full radiology department is on it and the nightly backup window starts overlapping with the morning read. By the time anyone measures, the storage array is saturated, the VM is fighting for CPU scheduling slots, and the vendor is blaming the network.

This guide covers how to size clinical workloads properly: what to measure, what the numbers actually mean, and where the standard approaches fail.

1. Why Vendor Sizing Sheets Are Not Enough

Every clinical system vendor publishes minimum specifications. They are useful, and they are not a sizing exercise. Three structural problems:

They describe a reference configuration, not yours. A vendor spec written for "up to 200,000 studies per year" assumes a study mix, a compression policy, a retention window, and a concurrency profile. Change any of those and the number stops applying. A site doing high-volume CT with thin-slice reconstruction has a completely different profile from one doing mostly CR and ultrasound at the same study count.

They are written to win procurement, not to survive year three. Minimum specs are a competitive number. Vendors are incentivised to quote low, because the alternative is losing a bid to someone who quoted lower. The specification is usually accurate for day one and silent about year three.

They assume dedicated resources. Almost every published spec implicitly assumes the CPU and memory are actually available to the VM. On a consolidated cluster running at high commitment, they are not.

Treat the vendor sheet as a floor. Your sizing is the vendor floor, plus measured reality, plus growth, plus headroom for the failure modes you have decided to survive.

2. The Four Dimensions

CPU

Clinical workloads are rarely CPU-bound in steady state, and frequently CPU-bound in bursts. The bursts are what matter.

The burst sources:

Image decompression and rendering — a viewer opening a multi-thousand-image CT study
Interface message bursts — an ADT feed replaying after an outage
Batch processing — nightly prefetch, routing rules, reconciliation jobs
Database query storms — worklist refresh across many concurrent workstations

Size for the burst, not the average. A server that averages 20% CPU and hits 100% for eight minutes every morning at handover is an under-sized server, and the average will never tell you.

The number to watch on virtualized hosts is not guest CPU utilisation — it is CPU ready time (VMware) or steal time (KVM/Xen). This is time the VM wanted to run and could not, because no physical core was free. Guest CPU can read 40% while the application is visibly slow, because the guest cannot see the time it spent waiting in the scheduler queue.

CPU ready (per vCPU, 20s sample)	Interpretation
Under 2%	Healthy
2–5%	Contention beginning; investigate
5–10%	Users will notice; act
Over 10%	Severe; the host is oversubscribed

vCPU counts are not free. A VM with 16 vCPUs must wait for 16 physical cores to be simultaneously schedulable. On a busy host, a 16-vCPU VM can perform worse than the same workload with 8 vCPUs, because it waits longer for a scheduling window. Start smaller than you think and scale up on evidence.

Memory

Memory sizing for clinical systems is driven by three consumers: the application heap, the database buffer cache, and the file system cache.

The database buffer cache is usually the one that matters. If the working set of your RIS or PACS database does not fit in memory, every worklist refresh becomes a storage read. The symptom is a system that is fast in the morning and slow by mid-afternoon as the cache fills with the wrong data.

Practical guidance:

Size database VMs so the hot working set fits in the buffer cache, not so the entire database fits. For most imaging databases the hot set is the recent study window plus all index structures.
Never overcommit memory on clinical VMs. Set reservations. Ballooning and host swapping on a database server produce latency spikes that are extremely hard to diagnose from inside the guest.
Leave headroom for the operating system, agents, and monitoring.

Storage: IOPS and Latency

This is where most sizing exercises fail, because capacity and performance get conflated. A 200 TB archive tier and a 2 TB database have entirely different performance requirements, and buying one large pool for both means the database inherits archive-grade latency.

Latency is the metric users feel. IOPS is a throughput number; latency is an experience number.

Workload	Target read latency	Notes
Clinical database (RIS/PACS/LIS)	Under 5 ms	Above ~10 ms, worklists become visibly slow
Image cache / short-term store	Under 10 ms	Drives study open time
Interface engine queue/journal	Under 5 ms	Write-latency sensitive; synchronous commits
Long-term archive	Tens of ms acceptable	Retrieval is asynchronous

Two rules prevent most storage-related incidents:

Separate the tiers. Database, image cache, and archive should not share the same spindles or the same QoS policy.
Size for the concurrent worst case, which is almost always the backup window overlapping clinical activity — or a migration running against production.

Network

Imaging is the only common hospital workload where a single user action can move a gigabyte. Sizing considerations:

Modality to PACS — bursty, large transfers. A modern CT can produce a multi-gigabyte study in a single send.
PACS to diagnostic workstation — latency-sensitive and bandwidth-hungry; this is the path radiologists judge the system by.
Interface traffic — tiny by volume, but latency and reliability critical.
Replication and backup — sustained, high-volume, and the most common cause of contention with clinical traffic.

The design rule is separation: clinical image traffic, replication/backup traffic, and management traffic should not compete for the same uplinks without QoS.

3. Workload Profiles

The following are starting points for a mid-size general hospital with a mixed modality profile. Validate every one against measurement — they frame the conversation, they do not replace it.

PACS Core (application / archive server)

CPU — burst-driven. Sensitive to routing rules, compression, and prefetch policy. Prefetch and auto-routing are the two configuration choices that most change CPU demand.
Memory — dominated by database buffer cache and image cache.
Storage — three tiers: database (low latency), online cache (medium), archive (capacity).
Network — highest sustained volume of any clinical system in the hospital.

The most common PACS sizing error is treating the online cache as an afterthought. If the cache is too small, every study older than the cache window becomes an archive retrieval, and users experience archive-tier latency on routine reads.

VNA

Similar to PACS but weighted toward capacity and ingestion throughput rather than interactive read latency. Key variables: number of contributing systems, tag-morphing rules applied on ingest, and whether the VNA also serves the diagnostic read path. If it does, treat it with PACS-grade latency targets.

RIS

Database-dominant, moderate CPU, low storage volume, high sensitivity to database latency. RIS performance complaints are almost always database latency or lock contention, not CPU.

LIS

Similar to RIS with two differences: transaction rate is typically higher and more uniform (instruments do not take lunch breaks), and result-delivery interfaces make it more sensitive to interface engine health.

Interface Engine

Small footprint, disproportionate blast radius. Sizing considerations that matter more than raw specs:

Write latency on the message journal. Interface engines commit synchronously. Slow journal writes throttle the entire message flow.
Queue depth headroom. Size queue storage to hold a full outage-and-replay cycle. If a downstream system is offline for six hours, the queue must absorb six hours of traffic without filling.
CPU for transformation. Heavy transformation scripts on high-volume feeds change the profile substantially.

Diagnostic / Enterprise Viewer Server

Server-side rendering shifts load from workstations to the server, and often to the GPU. If your viewer renders server-side, sizing becomes a concurrency exercise: how many simultaneous diagnostic sessions, each holding a decoded study in memory.

4. Measuring Instead of Guessing

Bed count is a poor sizing input. These are better, and all of them come from systems you already run.

From the RIS or PACS database:

Studies per year, broken down by modality
Study size distribution per modality — not just the mean; the 95th percentile matters
Peak-hour study volume as a multiple of the average hour
Concurrent user sessions at peak

From the current infrastructure:

CPU ready / steal time at peak, per VM
Storage read and write latency at peak, per datastore
Database cache hit ratio through the day
Network utilisation on the modality and workstation segments

The single most useful derived number is your peak-to-average ratio. A hospital doing 140,000 studies a year averages about 16 studies an hour across the whole year — a meaningless number. The same hospital may do 60 studies in the 10:00 hour on a Tuesday. Size for the Tuesday.

5. Virtualization-Specific Pitfalls

Oversubscription without reservations. Consolidation ratios that work for file servers do not work for clinical databases. Set CPU and memory reservations on production clinical VMs, and document them so they survive the next cluster rebalance.

NUMA misalignment. A VM sized larger than a single physical NUMA node forces memory access across the interconnect, increasing latency for exactly the memory-bound workloads you care about. Where possible, size clinical VMs to fit within one NUMA node.

Snapshot decay. A snapshot left on a busy database VM grows a delta file and degrades write performance continuously. Snapshots taken "just for the upgrade" and forgotten are a recurring cause of mysterious slow-downs weeks later. Alert on snapshot age.

Storage migration during clinical hours. Migrating a live PACS datastore in the middle of the reading day competes directly with clinical I/O. Schedule it, or expect a phone call.

The noisy neighbour you do not control. If clinical VMs share a cluster with general enterprise workloads, your performance is subject to someone else's batch job. Either isolate clinical workloads onto dedicated hosts, or enforce it with resource pools and shares.

6. Worked Example: 500-Bed Hospital

Inputs gathered from the existing environment:

Input	Value
Studies per year	138,500
Peak hour volume	62 studies
Peak concurrent diagnostic sessions	14
Peak concurrent clinical viewer sessions	110
HL7 messages per day	~48,000
Database size (RIS + PACS metadata)	340 GB
Hot working set (12 months)	~90 GB

Resulting sizing decisions:

PACS database VM — memory sized so the ~90 GB working set fits comfortably in buffer cache with OS headroom; storage on the low-latency tier with a sub-5 ms target; CPU reservation set; sized to fit within one NUMA node.

PACS application / archive VM — CPU sized against the peak hour plus prefetch overhead, not the annual average; online cache sized to cover the retrieval window that keeps routine reads off the archive tier (commonly 12–24 months for a general hospital, longer where comparison studies are clinically routine).

Interface engine VM — modest CPU and memory; journal on low-latency storage; queue volume sized to hold at least 24 hours of the busiest feed, so a downstream outage never becomes a data-loss event.

Network — dedicated segment for modality-to-PACS traffic; separate path or QoS class for replication and backup, so the nightly job cannot contend with the morning read.

The specific core and gigabyte counts belong in your environment's own document, because they depend on your CPU generation, storage platform, and vendor architecture. What transfers between environments is the method: measure peak, size against the burst, separate the tiers, reserve the resources, and re-measure after go-live.

7. Post-Go-Live: The Step Everyone Skips

Sizing is not a procurement activity that ends at purchase order. Two checkpoints prevent most year-two surprises:

Thirty days after go-live, re-measure everything: CPU ready, storage latency at peak, cache hit ratios, queue depths, network utilisation. Compare against the assumptions in your sizing document. The gaps you find here are cheap to fix.

Quarterly, review growth against projection. Study volume, average study size, and database growth all drift. Modality upgrades in particular can change average study size dramatically — a CT replacement with thinner default reconstruction can raise per-study size substantially with no change in study count at all.

Keep the sizing document alive and version it. The most valuable artefact is not the original spreadsheet; it is the record of what you assumed, what actually happened, and what you changed as a result.