An NVR that’s dropping frames has usually been failing quietly for months. It gets slow in small, deniable ways, and nobody files a ticket for slow. Then someone pulls footage of an incident and finds a gap.
The symptoms below show up long before that, and they’re all visible without special tooling.
How to Tell Your Recording Server Is Out of Headroom Before It Drops Frames
What actually limits a recording server?
Almost every recording server problem traces back to one of four ceilings. Knowing which one you’re near tells you whether the fix is a setting, a drive shelf, or a second server.
What does CPU load on an NVR come from?
Decode, mostly. The server has to decode any stream it looks at rather than simply writes, which means server-side motion detection, analytics, and anything rendered for a client. H.264 and H.265 have very different costs here, and modern processors handle H.265 far better than the generation that gave it a bad reputation. Turning on server-side VMD or analytics changes this math immediately.
What limits disk write throughput on an NVR?
Sustained megabytes per second the array can absorb. Recording is close to sequential, which is the friendliest workload spinning disks ever get, right up until playback and export start competing for the same spindles. Capacity and throughput are separate problems, and the number of drives matters more than the size of them.
Does network bandwidth limit NVR recording?
Usually not, and it’s the easiest of the four to measure. Compare utilization on the recording NIC against the sum of your camera bitrates. If those two numbers disagree badly, your assumed bitrates are wrong and every calculation downstream is wrong with them.
What does RAM affect on a recording server?
Whether the VMS database and index stay in memory or fall back to disk reads. Problems here show up in search and playback rather than in recording, which is why they get misdiagnosed as storage problems.
Which symptoms actually mean something?
Why does live view stutter when someone opens playback?
The array is at its limit. Recording writes sequentially while playback and export read randomly, and both hit the same drives. When one operator scrubbing through yesterday afternoon degrades live view for everyone else, that’s storage contention rather than a network problem. This is the most common early warning and the most commonly dismissed.
Why is my archive job falling behind?
The array can’t absorb the incoming write load plus the archive move. If the archive job is still running when the next one starts, you’re already past the throughput ceiling. Watch for schedules that quietly stopped completing overnight.
Why are there recording gaps with no camera offline event?
Because the gap is server-side. Camera dropouts, PoE resets, and switch reboots all leave traces in the logs. A gap with no corresponding camera or network event usually means the write path stalled long enough for the VMS to drop frames instead of buffering them.
Why does CPU spike to 100% during motion but look fine otherwise?
Because baseline CPU looks healthy on most undersized servers. The problem appears when motion fires across many cameras at once, which is exactly when you need the footage. Average CPU tells you nothing here. If peak CPU hits the ceiling during a busy period and stays there, decode load is oversubscribed.
Why do video exports take longer than they used to?
Same camera count and same clip length producing a much longer export means the array is saturated. Export slowdown tends to appear before recording gaps do, which makes it one of the more useful early signals.
Why is my RAID rebuild taking longer than it used to?
A rebuild competes with recording for the same drives. If a rebuild that took a day now takes three, the array is carrying more sustained load than it was, and your exposure window during a second drive failure has grown with it. Drive count per RAID set drives this, and arrays past twelve drives generally belong in RAID 60 rather than one wide RAID 6.
Why are smart searches slow when playback is fine?
That points at RAM and the database volume rather than the video array. Recording works, playback works, and searching crawls. If the VMS database shares a volume with the OS or with video, separating it is usually the fix.
Why did adding a few cameras cause problems out of proportion?
Because the server was already sitting at the edge. Ten more cameras on a comfortable server shouldn’t change its behavior much. When it does, those ten didn’t cause the problem so much as expose it.
How do you confirm which ceiling you hit?
Look at peaks rather than averages. A daily average CPU of 40% means nothing if the server spends 6pm to 8pm pinned. Sample during your busiest recording window.
On storage, write latency and disk queue depth tell you more than throughput alone. Throughput can look reasonable while latency climbs, and latency is what actually causes dropped frames. Watch both while someone runs a playback session.
Track free space and the rate it’s being consumed as two separate numbers. A server that’s fine on capacity today but filling faster than it did six months ago is telling you camera bitrates went up, usually because someone raised resolution or frame rate on a handful of cameras without recalculating anything.
Was the server ever sized for this?
Most of the time the answer is that the system grew. Cameras got added, resolution went from 2MP to 5MP, retention went from 30 days to 60 after an incident, someone turned on analytics. Each change was small. Together they moved the server past its specification and nobody redid the math.
Running the current configuration through a sizing calculator takes a few minutes and tells you whether you have a tuning problem or a capacity problem. Our public bandwidth and storage calculator covers the camera-side math: resolution, frame rate, codec, motion duty cycle, and retention, out to required storage and bandwidth.
Arxys partners have a fuller version in the Arxys Partner Portal, which carries compute sizing alongside storage and bandwidth. Both are free, and neither requires you to buy anything to get an answer. Your VMS vendor publishes hardware sizing guidance too, and it’s worth checking your configuration against both.
What’s the fix?
If CPU peaks are the ceiling, start with the cheap changes. Check whether server-side motion detection is doing work the cameras could do at the edge, and confirm you aren’t decoding streams nobody watches. Codec choice and decode hardware matter more than most people expect.
If disk throughput is the ceiling, more drives usually beats bigger drives. Swapping twelve 8TB drives for twelve 20TB drives triples your capacity without adding a single spindle of write performance.
If you’re past both, you need another recording server. The useful part is finding that out during a planning cycle rather than during an investigation.
