About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
On shared cloud hardware, your server runs alongside other customers' servers on the same physical hosts and storage. When one of them makes heavy demands, others can slow down. This is called the noisy neighbour problem. From inside your own server, it can look the same as your server simply being too small.
This article explains how contention arises, what you can measure yourself, and which controls a provider using VMware vSphere has to limit it.
Why it matters
If the cause is your own load, the answer is a bigger server or a change in the application. If the cause is contention, a bigger server may not help and the conversation is with the provider. Measuring before asking saves both sides time and money.
How it works
Shared processors
A host has a fixed number of physical processor cores. When the virtual processors of all its VMs need more than that, the hypervisor shares them out. Broadcom's vSphere documentation describes it: when processors are overcommitted, the host time-slices the physical processors across all virtual machines so each runs as if it had its configured number. A VM waiting for its turn is not running, and the guest operating system does not see that wait as busy time.
By default, Broadcom states, all VMs on a host get an equal share of processor per virtual CPU.
Shared storage
Several VMs can use the same datastore. When the storage behind it is busy, every VM's disk requests take longer. vSphere's Storage I/O Control is designed for this: once enabled on a datastore, the host monitors device latency, and when latency passes a threshold, each VM gets I/O in proportion to its shares. By default, Broadcom states, all VMs have Normal shares (1000) and unlimited IOPS.
The threshold is a trade-off the provider makes. Broadcom explains that a lower value gives stronger isolation between VMs and lower latency for the VMs with the highest shares, at the cost of higher latency for those with fewer shares, while a higher value favours total throughput with weaker isolation. Broadcom also notes that most environments do not need the threshold adjusted, and that throttling does not start until average latency passes it. Below that point, VMs share the storage without priority, so a busy neighbour can still raise your latency up to the threshold.
The provider's controls
For CPU and memory, vSphere provides three allocation controls:
- Shares: relative priority when resources are contended.
- Reservation: a guaranteed minimum of CPU or memory, as described in Broadcom's reservation guidance.
- Limit: an upper bound. Broadcom states that a host never allocates more than the limit, even if there are unused resources on the system.
The datastore Storage I/O Control described here uses shares and IOPS limits. Those controls do not establish a universal guaranteed IOPS reservation for every shared datastore. If a provider offers a storage performance reservation, ask which supported storage or policy mechanism supplies it and under what conditions.
Limits cut both ways. A per-VM IOPS limit stops one tenant from flooding shared storage, but it also caps your own server when the storage is idle. Broadcom notes that limits can waste idle resources, and advises setting them only with good reason.
A provider's tenant isolation therefore depends on how these are set: whether processors are overcommitted and by how much, whether Storage I/O Control is enabled, and whether per-VM limits or reservations exist. Other hypervisors have equivalent controls under different names.
What a tenant can measure
From inside a Windows server, Performance Monitor gives the signs. Record them over a period that includes slow times and normal times.
| Sign | Possible cause and next check |
|---|---|
| Disk latency rises while your own disk operations per second stay flat | Compare request size, read/write mix, queue length, cache behaviour and local filters/jobs before attributing shared-storage contention |
| Disk operations per second flatten at a fixed ceiling | Check effective VM/disk limits, throughput caps and whether the workload is actually issuing more requests |
| Processor time is moderate, yet work takes longer at certain times of day | Correlate host ready time, limit-induced waiting and local application waits |
| Processor time is near 100% across all cores during slow periods | Check workload efficiency, application demand and effective CPU caps before deciding more processors would help |
| Memory shows little available and paging rises | Check working sets, application growth and guest paging alongside host pressure and VM/resource-pool memory policies |
Processor contention is harder to see from inside than storage contention, because ordinary guest CPU counters do not expose the hypervisor's scheduling wait. The hypervisor records CPU ready time, but Broadcom's CPU counter definitions include limit-induced waiting within that figure. Ask the provider to distinguish caps from contention. Broadcom also documents ballooning caused by resource-pool settings while host or cluster resources remain available. Neither signal alone proves that a neighbour consumed the host's capacity.
Keep the comparison fair: note the times when users reported slowness, and compare like with like, for example the same report run at a quiet time and at a slow time.
What to choose and why
Questions to ask a provider, with your measurements in hand:
- Are processors overcommitted on the hosts my servers run on, and to what ratio?
- Is Storage I/O Control or an equivalent enabled on the storage my servers use?
- Are there per-VM limits on processor, memory or IOPS, and what are they?
- Can you show my VMs' ready time and storage latency for the periods I measured?
- What reservation or dedicated option exists if contention is confirmed?
Choose a remedy after those checks identify the constraint. Resize only when measured demand and the application's ability to use extra resources support it; otherwise address workload behaviour, limits or confirmed shared-resource contention.
Risks and limits
- Inside-the-guest signs are indirect. They suggest contention; the provider's hypervisor data confirms it.
- Your own scheduled jobs can look like neighbours. Backups, antivirus scans and index maintenance at fixed times can produce the same pattern; check your own schedule first.
- Dedicated hosts can remove other customers from CPU and memory. Shared storage and network may remain; correct sizing and workload checks are still needed.
- Settings are the provider's. A tenant cannot change shares, limits or overcommitment; the questions above are the route.
- No commands are given here.
Sources
Opened 14 November 2026.
- Broadcom TechDocs: CPU Virtualization in vSphere, vSphere 8.0.
- Broadcom TechDocs: Manage Storage I/O Resources with vSphere, vSphere 8.0.
- Broadcom TechDocs: Set Storage I/O Control Threshold Value, vSphere 8.0.
- Broadcom TechDocs: Configure Your Resource Allocation Settings in vSphere, updated 28 October 2026.
- Broadcom TechDocs: Resource Allocation Limit, updated 28 October 2026.
Related service: Cloud hosting.
Related future topics
- Why the provider's dashboard and your server disagree.
- Reading a storage specification.
- What "private cloud" means: shared hardware and dedicated hosts.
Learning notes
- Contention on shared hosts can look like an undersized server from inside.
- vSphere time-slices processors when overcommitted; the guest does not see the wait.
- Storage I/O Control shares storage by priority when latency passes a threshold.
- Limits cap a VM even when the host is idle.
- Measure first, then ask the provider specific questions.
This article was originally published on .