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.

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.

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 covers it.

1. Locate the swap row by walking the description column:

   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):

   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:

   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 and system load. 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: 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.