HPE Server Sizing Guide: How to Choose the Right CPU, RAM & Storage

Choosing an HPE server is not simply about finding the model with the highest specifications.

An undersized server can lead to performance bottlenecks, limited virtual-machine capacity, storage problems and the need for an early upgrade. At the same time, oversizing can increase the purchase cost while leaving expensive CPU, memory and storage resources unused.

Server sizing should therefore start with the workload and expected growth.

A practical way to approach it is:

Workload → CPU → RAM → Storage → Networking & Redundancy → HPE ProLiant Model

Following this process helps businesses narrow down suitable HPE server configurations before requesting a final quotation.

Why Server Sizing Matters Before You Choose an HPE Server

Server sizing is a balance between performance, cost and future scalability.

Two businesses running the same software may still need very different servers because they have different numbers of users, transaction volumes, databases, virtual machines, storage requirements and peak workloads.

A company running dozens of virtual machines does not have the same requirements as a small business running a few office applications and file shares.

The better approach is to:

1. assess the workload
2. estimate CPU requirements
3. calculate memory requirements
4. plan storage capacity and performance
5. consider networking and redundancy
6. decide between tower and rack infrastructure; and
7. shortlist suitable HPE ProLiant servers.

Once those requirements are clear, it becomes much easier to request the correct configuration instead of simply choosing a server based on the model name.

Step 1 — Define Your Server Workload

Identify the Primary Workload

Start by identifying what the server will actually run.

Different workloads place very different demands on CPU, RAM, storage and networking. For example:

• Virtualisation needs a good balance of CPU cores, RAM, storage performance and networking.
• Databases and SQL applications can be sensitive to memory capacity, storage latency and IOPS.
• ERP and business applications should be sized according to the software vendor’s recommendations, number of users and expected transaction volume.
• File and print servers usually depend more on storage capacity and network performance than extreme CPU performance.
• Backup and archival systems often require large storage capacity and good sequential throughput.
• VDI environments can require substantial CPU, RAM, storage IOPS and networking depending on the number and type of users.
• AI, rendering and engineering applications may also require GPUs or other accelerators.

This is why the workload should always come before the server model.

Estimate Users and Concurrent Usage

The total number of employees does not tell you how much server capacity is required.

Concurrent usage matters more.

A company may have 500 employees but only 100 people actively using a particular application at the same time. Another company may have 150 employees with almost everyone using the same system during business hours.

Consider:

• total users
• concurrent users
• peak usage periods
• applications running at the same time
• transactions per user
• number of VMs; and
• expected future usage.

Sizing around peak realistic demand is usually more useful than sizing around the total number of employees.

Plan for Future Growth

A server should not be sized only for today’s requirements.

Consider what may change during the expected life of the system:

• additional employees
• larger databases
• more virtual machines
• new applications
• increased storage requirements
• higher network traffic; and
• new business locations or services.

You do not necessarily need to buy all future capacity on day one.

However, the selected server should provide enough expansion room so that additional RAM, storage, networking or other components can be added later.

Step 2 — How to Size the CPU for an HPE Server

CPU Cores vs Clock Speed

More CPU cores can help virtualisation and heavily parallel workloads.

Higher clock speeds can be important for applications that depend strongly on single-thread performance.

For this reason, choosing the processor with the highest core count is not always the best option.

Consider:

• application behaviour
• number of concurrent users
• VM requirements
• CPU utilisation during peak periods
• core count
• clock performance
• software licensing; and
• expected growth.

Software licensing is especially important because some enterprise applications are licensed per processor, per core or according to other hardware metrics. Adding more CPU cores can therefore increase software costs as well as hardware costs.

Single-Socket vs Dual-Socket Servers

A single-processor server can be enough for many small and medium business workloads.

Dual-socket platforms become more useful when the business needs:

• greater CPU capacity
• more VM density
• higher memory capacity
• additional memory bandwidth; or
• more demanding enterprise workloads.

However, adding a second processor can also increase:

• acquisition cost
• power consumption
• cooling requirements; and
• software licensing costs.

The goal is not to use two CPUs simply because the server supports them. The additional processor should solve an actual capacity or performance requirement.

CPU Sizing for Virtualisation

For virtualisation, distinguish between physical CPU cores and virtual CPUs (vCPUs) assigned to virtual machines.

VM count alone is not enough to size the processor.

Consider:

• number of VMs
• vCPUs allocated to each VM
• actual CPU utilisation
• hypervisor overhead
• peak demand
• CPU oversubscription
• workload behaviour; and
• expected VM growth.

A server hosting 20 lightly used VMs may need less CPU capacity than one hosting 8 heavily used database or application VMs.

This is why historical utilisation data from an existing environment can be especially useful when sizing a replacement server.

CPU Generation and Platform Compatibility

Processor choices vary by HPE ProLiant generation and model.

Before finalising a configuration, check:

• supported processor families
• maximum processor count
• available core counts
• memory support
• processor power requirements
• cooling requirements; and
• upgrade possibilities.

HPE QuickSpecs for the specific server should be checked because processor support can change between models and generations.

Step 3 — How Much RAM Does Your HPE Server Need?

Estimate RAM Based on the Workload

RAM should be calculated from workload requirements rather than choosing an arbitrary amount such as 32GB, 64GB or 128GB.

Different workloads behave differently.

File servers may have relatively modest memory requirements, while databases can benefit from additional RAM for caching.

Virtualisation and VDI environments require memory to be calculated across all VMs or desktops running on the host.

Memory-intensive business applications should be sized according to the software vendor’s recommendations.

RAM Sizing for Virtualisation

A useful planning framework is:

Host memory requirement ≈ VM memory + hypervisor overhead + host reserve + growth headroom

This is not a fixed sizing formula, but it is a useful starting point.

For example, consider:

• RAM allocated to each VM
• number of active VMs
• hypervisor requirements
• host operating requirements
• HA or failover planning
• future VM growth; and
• memory utilisation during peak periods.

Avoid sizing memory so tightly that adding even a few new VMs immediately requires a server upgrade.

Memory Channels, DIMMs and Server Performance

Server memory configuration is not only about total capacity.

How the DIMMs are installed can affect memory-channel utilisation and bandwidth.

A balanced DIMM configuration can perform better than simply reaching the required memory capacity without considering the platform’s memory architecture.

HPE provides memory-population guidelines for each ProLiant model.

These should be followed when configuring the server, particularly on systems with multiple memory channels and processors.

Leave Memory Headroom for Growth

Consider future requirements such as:

• larger databases
• additional VMs
• additional users
• new applications; and
• greater caching requirements.

Also check how many DIMM slots will remain free after the initial configuration.

For example, filling every available slot with small DIMMs may make a future memory upgrade more expensive than starting with fewer higher-capacity modules where the platform supports it.

Step 4 — How to Size Server Storage

Calculate Required Storage Capacity

A useful starting framework is:

Required usable capacity = current data + OS/application requirements + retention + expected growth + operational headroom

The important word here is usable.

Raw disk capacity is not the same as usable capacity after RAID, formatting and other storage requirements are considered.

Businesses should also account for:

• current data
• database growth
• user files
• VM storage
• application files
• logs
• backups and retention where stored locally
• temporary or scratch data; and
• expected future growth.

HDD vs SSD vs NVMe

Different storage technologies suit different requirements.

HDDs can provide large capacity at a lower cost per terabyte and may suit backup, archive and capacity-focused workloads.

SSDs offer much lower latency and higher IOPS than hard drives, making them suitable for applications, databases, virtual machines and other active workloads.

NVMe SSDs can provide even greater performance and lower latency on supported systems, making them particularly useful for demanding databases, analytics, virtualisation and other high-I/O workloads.

The fastest drive is not automatically the right drive.

Storage should be selected according to workload behaviour, performance requirements, capacity and budget.

Consider IOPS and Storage Performance

Storage sizing should not be based on capacity alone.

Databases and virtualisation environments can generate large amounts of random I/O, while backups may generate more sequential traffic.

Important storage-performance factors include:

• IOPS
• latency
• sequential throughput
• random read/write performance
• workload read/write ratio; and
• peak activity.

A server can have enough storage capacity and still perform poorly if the storage subsystem cannot handle the required I/O.

Choose the Appropriate RAID Level

RAID provides different combinations of redundancy, performance and usable capacity.

Some common examples include:

• RAID 1 — Mirrors data across drives. Simple and commonly used where redundancy is required with a small number of drives.
• RAID 5 — Provides single-drive fault tolerance with more usable capacity than mirroring, but write performance and rebuild behaviour should be considered carefully, especially with larger drives and demanding workloads.
• RAID 6 — Provides protection against two drive failures, with additional capacity and write-performance overhead.
• RAID 10 — Combines mirroring and striping and can provide strong performance and redundancy, but uses more raw drive capacity.

The right RAID level depends on the workload, required availability, performance and number of drives.

Most importantly, RAID is not a backup.

A separate backup strategy is still necessary to protect against deletion, corruption, ransomware, disaster and other failures that RAID cannot prevent.

SFF vs LFF Drive Bays

SFF (2.5-inch) drive configurations can provide greater drive density and are commonly used with enterprise SSD and SAS configurations.

LFF (3.5-inch) bays can be useful where large-capacity hard drives are the priority.

The choice depends on:

• required capacity
• performance
• number of drives
• future expansion; and
• server chassis.

Check the drive-bay configuration before buying because different versions of the same HPE server may support different storage layouts. You can read this buying guide for HPE servers.

Storage Controller and RAID Controller Considerations

The storage controller can have a significant effect on performance and available RAID options.

Check:

• supported RAID levels
• controller cache
• cache protection
• SAS/SATA/NVMe compatibility
• number of supported drives
• performance requirements; and
• HPE drive compatibility.

Do not treat the RAID controller as a minor specification if storage performance or availability is important to the workload.

Step 5 — Don’t Forget Networking, Power and Redundancy

Network Requirements

For basic file sharing and smaller applications, 1GbE may still be sufficient.

Virtualisation, backup, large data transfers and storage traffic may benefit from:

• 10GbE
• 25GbE
• 40GbE
• 100GbE or faster networking where justified.

The correct choice depends on the network infrastructure around the server as well.

There is little benefit in purchasing very high-speed server NICs if the switches, storage and rest of the network cannot support those speeds.

Also check:

• onboard NICs
• OCP network adapters
• PCIe network expansion
• port redundancy; and
• future networking requirements.

Power Supply Redundancy

Redundant power supplies can help keep a server operating if one PSU fails, provided the system is correctly configured for redundancy.

This can be important for business-critical workloads.

Power requirements should consider the complete configuration, including:

• processors
• RAM
• storage
• network adapters
• GPUs
• PCIe cards; and
• future upgrades.

Servers running important workloads should also be considered as part of a wider power strategy that may include UPS systems and redundant power sources.

GPU and PCIe Expansion Requirements

Some workloads may require GPUs or other accelerator cards.

Examples include:

• AI inference
• VDI
• rendering
• engineering applications; and
• specialised compute workloads.

GPU support can affect:

• chassis choice
• riser configuration
• PCIe availability
• power-supply selection
• cooling; and
• processor requirements.

If GPU capability may be required later, check it before selecting the server rather than assuming a GPU can simply be added to any ProLiant model.

Step 6 — Match Your Requirements to the Right HPE ProLiant Server

Once the CPU, RAM, storage, networking and expansion requirements are clear, you can start matching them to an HPE ProLiant platform.

The following models cover several common business requirements.

HPE ProLiant ML30 Gen11 — Small Businesses and Branch Offices

The HPE ProLiant ML30 Gen11 is a compact tower server suited to smaller businesses and branch-office environments where rack infrastructure is not required.

It can be considered for workloads such as:

• file and print services
• basic business applications
• directory and infrastructure services
• smaller databases; and
• lighter server workloads.

The platform uses Intel Xeon E-2400-series processors and supports DDR5 ECC memory. HPE’s platform specification supports up to 128GB of memory, although the exact installed configuration will depend on the system being purchased.

This makes the ML30 Gen11 a practical starting point for businesses that need a dedicated server but do not require the expansion of a larger tower or rack platform.

HPE ProLiant ML110 Gen11 — Growing Businesses

The HPE ProLiant ML110 Gen11 provides more memory and expansion capability than an entry-level tower.

It can suit growing businesses running:

• ERP or CRM applications
• business databases
• file services
• multiple business applications
• moderate virtualisation; and
• workloads likely to expand over time.

HPE’s current ML110 Gen11 platform uses Intel Xeon Scalable processors, provides 16 DDR5 DIMM slots and supports PCIe Gen5.

It can be a useful middle ground for organisations that need more capacity than an entry-level tower but do not yet require a large rack-server environment.

HPE ProLiant ML350 Gen11 — Demanding Tower Deployments

The HPE ProLiant ML350 Gen11 is a larger tower platform designed for organisations that need substantially more processing, memory, storage and expansion capability.

It can be considered for:

• larger virtualisation environments
• databases
• business-critical applications
• ERP workloads
• storage-heavy applications; and
• organisations that want significant expansion while retaining a tower form factor.

This is particularly useful for businesses that have demanding on-premises requirements but do not want to move immediately to rack infrastructure.

Empeller Systems currently lists the ML350 Gen11 alongside the ML30 and ML110 as part of its HPE server range.

HPE ProLiant DL360 Gen11 — Dense 1U Compute

The HPE ProLiant DL360 Gen11 is a compact 1U rack server.

Its dense form factor makes it useful where rack space is important while still providing substantial CPU, memory and networking capabilities.

Typical uses can include:

• virtualisation
• application hosting
• compute-intensive workloads
• web infrastructure
• containers; and
• data-centre deployments.

Empeller’s listed DL360 Gen11 configuration uses DDR5 memory and the platform supports 4th and 5th Generation Intel Xeon Scalable processors and PCIe Gen5.

HPE ProLiant DL380 Gen11 — Flexible Enterprise 2U Server

The HPE ProLiant DL380 Gen11 is a 2U rack platform commonly considered when businesses need more room for storage, expansion and demanding enterprise workloads.

It can be suitable for:

• virtualisation
• databases
• ERP
• enterprise applications
• storage-intensive workloads; and
• consolidated infrastructure.

Compared with a compact 1U server such as the DL360, the larger chassis can provide more flexibility for storage and expansion depending on the selected configuration.

Empeller Systems currently carries the DL380 Gen11 as part of its HPE server range.

HPE ProLiant DL385 Gen11 — AMD EPYC Workloads

The HPE ProLiant DL385 Gen11 is an AMD EPYC-based 2U server designed for demanding compute, virtualisation and data-intensive workloads.

Depending on the selected processor and configuration, the platform can provide very high core counts, substantial DDR5 memory capacity and PCIe Gen5 connectivity.

HPE’s current QuickSpecs include 4th and 5th Generation AMD EPYC processor options, with high-core-count configurations available for workloads that can use them effectively.

This can make the DL385 Gen11 worth considering for:

• high-density virtualisation
• analytics
• compute-intensive applications
• large databases; and
• workloads that benefit from high CPU core counts.

Again, a high-core-count processor should be selected because the workload requires it, not simply because the server supports it.

Quick HPE Server Selection Table

Requirement	HPE Server to Consider
Small office and basic server workloads	ML30 Gen11
Growing SMB requiring more expansion	ML110 Gen11
Powerful and expandable tower server	ML350 Gen11
Dense 1U compute and virtualisation	DL360 Gen11
Flexible enterprise 2U platform	DL380 Gen11
High-core-count AMD workloads	DL385 Gen11

This table should be treated as a starting point, not a final configuration recommendation.

A heavily configured ML110 may be more suitable than an under-configured ML350 for one workload, while another business may need a DL380 because of storage or PCIe requirements rather than CPU performance.

The configuration matters as much as the server model.

Example: Sizing an HPE Server for a Small Virtualisation Environment

Consider a business planning to run several virtual machines for:

• Active Directory
• accounting or ERP software
• file services
• a database
• an internal application; and
• one or two additional future VMs.

Rather than immediately choosing a server model, the business should first calculate:

CPU

Estimate the vCPU requirements of each VM and check expected utilisation during busy periods.

RAM

Add the memory required by all VMs, hypervisor overhead, host reserve and extra capacity for future VMs.

Storage

Calculate usable VM storage and then check IOPS, latency, RAID configuration and growth.

Networking

Consider whether 1GbE is enough or whether 10GbE or faster networking is justified by VM traffic, backups or shared storage.

Redundancy

Decide whether the workload requires redundant power supplies, RAID protection, multiple network interfaces and a higher-availability design.

Only after these requirements are known should the business compare platforms such as the ML110, ML350, DL360 or DL380.

This approach reduces the risk of buying a server that looks powerful on paper but is poorly matched to the actual workload.

Frequently Asked Questions