---
type: Article
title: "SNMP Swap Monitoring"
description: "Swap is the pressure gauge for memory — when it fills, RAM already went wrong. The hrStorage OID that reports it, where to set thresholds, and how to read it."
resource: "https://snmp-monitoring.com/sensors/server-resources/swap/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# SNMP Swap Monitoring

SNMP swap monitoring is one of those checks that looks minor until the day it saves you. Swap is the pressure gauge for memory: when it starts filling, something has already gone wrong with RAM, and performance is usually about to follow it down. The good news is that the reading sits in the same standard MIB table as your disks and physical memory, so any Net-SNMP agent already serves it. This guide covers what swap actually is, the exact `hrStorage` OID that reports it, how to read it, where to draw thresholds, and why watching it from outside the box beats trusting the box to tell on itself.

## What is Swap and why monitor it

Swap is disk space the operating system uses as an overflow area for memory. When physical RAM runs short, the kernel moves inactive memory pages out to the swap area to free room for whatever needs it now. It's a safety valve — the system keeps running instead of killing processes outright — but it's a slow one. Disk is orders of magnitude slower than RAM, so pages that get swapped out and then needed again cost real time.

That trade-off is exactly why you monitor swap usage. A little swap in use is normal and harmless; the kernel parks genuinely idle pages there and never looks at them again. Sustained, growing swap is the alarm. It means RAM is exhausted and the machine is falling back on its slow reserve to stay alive.

The symptom that follows is *swap thrashing*: the system spends more time shuffling pages between RAM and disk than doing useful work. Latency spikes, load climbs, throughput collapses, and the box can feel hung while its CPU sits mostly idle — because it's waiting on disk, not compute. Catching the swap trend early is what lets you add memory, tune the workload, or restart a leaking process before users notice.

Monitoring it over SNMP is cheap. The agent already tracks the swap area's size and usage and publishes both through the Host Resources MIB. No extra software on the host — you just poll it.

![Diagram of an external SNMP poller reading the hrStorage swap-used OID from a server's agent over UDP](https://snmp-monitoring.com/img/sensors/snmp-swap-monitoring-poll.webp)

## The OID: 1.3.6.1.2.1.25.2.3.1.x (hrStorage, swap index)

Swap is reported through the `hrStorage` table in the Host Resources MIB (RFC 2790) — the same table that lists filesystems and physical memory. Swap is simply another row. You identify its index from the description column, then read size and used at that index.

| Column | OID | Object name | Meaning |
|---|---|---|---|
| Description | `1.3.6.1.2.1.25.2.3.1.3` | `hrStorageDescr` | Names the area, e.g. "Swap Space" |
| Allocation unit | `1.3.6.1.2.1.25.2.3.1.4` | `hrStorageAllocationUnits` | Bytes per unit |
| Size | `1.3.6.1.2.1.25.2.3.1.5` | `hrStorageSize` | Total swap, in allocation units |
| Used | `1.3.6.1.2.1.25.2.3.1.6` | `hrStorageUsed` | Swap in use, in allocation units |

Same mechanics as any storage row. `hrStorageSize` and `hrStorageUsed` are counts of allocation units, not bytes — multiply by `hrStorageAllocationUnits` (`1.3.6.1.2.1.25.2.3.1.4`) to convert. Percent swap used is `hrStorageUsed` ÷ `hrStorageSize` × 100. The swap OID you'll actually chart is `hrStorageUsed` (`1.3.6.1.2.1.25.2.3.1.6`) at the swap index. Finding that index is the first job: walk `hrStorageDescr` and look for "Swap Space" or "Virtual Memory" — the label varies a little between agents, but it's unambiguous once you see it.

## How to query it

Any Net-SNMP client will do. These assume an SNMPv2c agent with a read-only community string; if that's not set up, the [snmpd.conf guide](/setup/snmpd-conf.md) covers it.

1. **Locate the swap row** by walking the description column:
   ```bash
   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.3
   ```
   Look for the swap line and note its index:
   ```
   HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical Memory
   HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: Swap Space
   HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: /
   ```
2. **Read size and used** for that index (here, `.3`):
   ```bash
   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.5.3 1.3.6.1.2.1.25.2.3.1.6.3
   ```
   ```
   HOST-RESOURCES-MIB::hrStorageSize.3 = INTEGER: 2097152
   HOST-RESOURCES-MIB::hrStorageUsed.3 = INTEGER: 131072
   ```
3. **Force numeric output** if the MIB isn't installed locally:
   ```bash
   snmpwalk -v2c -c public -On 10.0.0.5 1.3.6.1.2.1.25.2.3.1
   ```

Divide used by size for the percentage, or multiply by the allocation unit for bytes. In the sample above that's roughly 6% swap in use — nothing to worry about.

## Normal vs alarming values & thresholds

Swap thresholds are less about a fixed line and more about direction. A few bands to monitor swap usage against:

- **0–10% used, flat** — normal. Idle pages parked; ignore it.
- **10–40% used, stable** — acceptable on a memory-tight host, but keep an eye on RAM alongside it.
- **Rising steadily** — the real signal. Swap climbing over minutes to hours means RAM pressure is building; warn on the trend regardless of the absolute figure.
- **Above ~50% and still climbing** — high. Investigate for a leak or an undersized instance before thrashing sets in.
- **Near full** — critical. The safety valve is nearly spent; the next step is failed allocations or the OOM killer.

To turn the raw counter into a percentage, compare `hrStorageUsed` against `hrStorageSize` (`1.3.6.1.2.1.25.2.3.1.5`) for the swap row — used divided by size. A machine that never touches swap is perfectly healthy; what actually matters is how much of the *configured* swap is committed, and whether that share keeps creeping upward from one poll to the next.

The single most useful rule: never read swap in isolation. Swap tells the truth only next to [memory](/sensors/server-resources/ram-memory.md) and [system load](/sensors/server-resources/system-load.md). Full RAM plus rising swap plus climbing load is the unmistakable fingerprint of a machine running out of memory — any one of those alone can mislead you.

## Alerting on this metric externally

Reading `hrStorageUsed` on demand tells you swap is filling right now. Preventing the incident means being told the instant it's been filling too long — and a host deep in swap thrashing is a bad place to run your alerting. The system is so busy moving pages to and from disk that a local agent may not get scheduled to send its warning, or may itself get swapped out. The alert stalls exactly when you need it most.

Polling from outside removes that dependency. That's the point of [double durability](/monitoring/double-durability.md): an independent checker keeps reading `1.3.6.1.2.1.25.2.3.1.6` on its own hardware and clock, so a thrashing or crashed server still trips an alert. SNMP is pull-based, so the external side simply asks on its own schedule — the struggling machine doesn't have to find spare cycles to report itself.

![Chart of SNMP swap usage climbing over time as a server runs low on RAM](https://snmp-monitoring.com/img/sensors/snmp-swap-usage-chart.webp)


## FAQ

**Which OID reports swap usage over SNMP?**
`hrStorageUsed` at `1.3.6.1.2.1.25.2.3.1.6`, read at the swap index, together with `hrStorageSize` (`1.3.6.1.2.1.25.2.3.1.5`). Both are allocation-unit counts; multiply by `hrStorageAllocationUnits` (`1.3.6.1.2.1.25.2.3.1.4`) for bytes.

**How do I find the swap index in the storage table?**
Walk `hrStorageDescr` at `1.3.6.1.2.1.25.2.3.1.3` and find the row labelled "Swap Space" or "Virtual Memory." That row's index is the one you query for size and used.

**Is any swap usage a problem?**
No. A small, stable amount is normal — the kernel parks idle pages there. The warning sign is swap that keeps growing, especially with RAM already full.

**What's the difference between swap and memory monitoring?**
They're separate rows in the same `hrStorage` table. RAM is the fast working memory; swap is the disk-backed overflow. See [SNMP memory monitoring](/sensors/server-resources/ram-memory.md) for the RAM side.

## Conclusion

SNMP swap monitoring is really one row of the `hrStorage` table — `hrStorageUsed` over `hrStorageSize` at the "Swap Space" index — read as a trend, not a single snapshot. Publish those OIDs in your [snmpd.conf](/setup/snmpd-conf.md), keep them in your [OID allowlist](/setup/oid-allowlist.md), and poll them alongside RAM and load; the whole set lives in the [sensor & OID catalog](/sensors/index.md) and [complete OID list](/sensors/all.md). Then watch it from outside — [ostr.io Monitoring](https://ostr.io/service/monitoring) polls swap from beyond your network and alerts by email and SMS, so a thrashing server still gets the message out.