# What is a noisy neighbor?

A noisy neighbor is another tenant on shared hardware. Its heavy use of CPU,
memory, disk or network slows down your workload.

**On Runtime, every sandbox has a guaranteed CPU floor and its own memory. It
also gets a fair share of the disk and network limits. The host enforces all
of these outside the guest.** A sandbox's disk gets at least about
40 MB/s, however busy its neighbors are. When they are idle, it can
reach about 1 GB/s. One busy sandbox cannot starve the others on its
server ([the sandbox environment](/docs/sandbox-environment#disk-cpu-and-memory)).

## Where the term comes from

Microsoft's Azure Architecture Center describes it as an antipattern of
multitenant systems. The problem "occurs when one tenant's performance is
degraded because of the activities of another tenant". It can happen when one
tenant uses a disproportionate share. It can also happen when many small
tenants peak at the same time. From the outside, the symptom is a request that
usually succeeds but sometimes fails or slows down with no clear cause.

## What a neighbor can take from you

| Shared resource      | What goes wrong                         | How a platform limits it                     |
| -------------------- | --------------------------------------- | -------------------------------------------- |
| CPU time             | Your threads wait for a core            | A guaranteed share per tenant, capped bursts |
| A core's two threads | Cache and execution units are contested | Core scheduling keeps strangers off one core |
| Memory               | The host swaps or kills processes       | Fixed memory per tenant                      |
| Disk I/O             | Latency spikes behind someone's writes  | A rate limit with a burst allowance          |
| Network              | Throughput drops                        | Per-tenant bandwidth caps                    |

The Linux kernel documentation describes core scheduling. It lets userspace
"define groups of tasks that can share a core". Only trusted tasks run side by
side on the two threads of one core.

## The Runtime answer, in numbers

- **CPU:** a floor of a twentieth of a vCPU by default. Set `cpuFloorMillis` to
  change it, or set `cpu: "reserved"` to reserve every vCPU
  ([shared vs reserved CPU](/glossary/shared-vs-reserved-cpu)).
- **Memory:** the memory the sandbox asks for, up to 64 GiB on a paid
  sandbox.
- **Disk:** the host's kernel divides the drives between busy sandboxes in
  proportion. It keeps every read and write near a latency target. A heavy
  writer next door slows your writes a little. It never stops them.
- **Network:** each server's link is shared fairly among the sandboxes that use
  it. A paid sandbox gets four times of the share given to a sandbox without
  credit. A paid sandbox moves up to 500 GiB a day
  ([the network](/docs/sandbox-environment#the-network)).

## Related

- [What is a CPU floor?](/glossary/cpu-floor)
- [What is CPU overcommitment?](/glossary/cpu-overcommitment)
- [What are cgroups?](/glossary/cgroups)
- [What is a vCPU?](/glossary/vcpu)

## Sources

Checked 25 October 2026.

- [Noisy Neighbor antipattern, Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/noisy-neighbor/noisy-neighbor)
- [Core scheduling, the Linux kernel documentation](https://docs.kernel.org/admin-guide/hw-vuln/core-scheduling.html)