FreeBSD systat Operations: Read Live CPU, Memory, Network, and I/O Views

systat is a curses-based, screen-oriented monitor that presents several live FreeBSD statistics displays in one terminal. It is useful during interactive triage because CPU, virtual memory, disk, network, process, swap, and ZFS ARC views are available through one tool. It is not a historical metrics system, and a screen snapshot is not enough to establish a long-term performance trend.

The most important operational discipline is to interpret each display as a time sample with a defined refresh interval. Some counters are cumulative, some views show rates, and a display can hide rows when a terminal is too small. Use systat to form and test a hypothesis, then capture durable evidence with appropriate commands, logs, or a metrics collector.

Start with a controlled view

Run systat in an interactive terminal with a sensible refresh interval:

systat -vmstat 1
systat -iostat 1
systat -ifstat 1
systat -zarc 1

Each command launches a particular display and refreshes it once per second. The installed systat(1) manual lists available displays and options for the current release. The terminal size matters: some displays have minimum-width assumptions, and rows or disks may be omitted or truncated when there is insufficient screen space.

The global command interpreter accepts help, load, stop, start, and quit commands. Press q to quit. Control-L redraws the screen. The command interface can switch to other displays interactively; consult the manual for display-specific commands instead of assuming that a Linux top-style key binding exists.

If the display does not start, verify that the session has a usable terminal type and dimensions. A serial terminal, SSH client, multiplexer pane, or logging wrapper may have limited dimensions or unsupported control sequences. Resize the terminal or use a non-interactive tool where a durable report is more important than a live screen.

Read vmstat as a system-wide symptom view

The vmstat display summarizes memory and scheduler activity alongside CPU state. Use it to identify patterns that deserve a closer look: sustained runnable work, blocked processes, paging or page-daemon activity, high system time, or a CPU state that changes under load. Do not interpret a single refresh as a diagnosis. Compare several intervals under a known workload and record whether the signal is persistent.

Memory counters require context. Free memory alone is not a complete measure of health on a caching system. Swap activity, page-daemon behavior, process memory, ARC size, and workload latency should be interpreted together. If a workload stalls while swap is active, inspect which processes and resources are involved rather than concluding from one bar or counter that the machine is out of RAM.

Use process tools such as top, ps, procstat, and vmstat when the screen suggests contention. systat shows a useful aggregate picture, but it does not identify every application cause or provide a complete per-process allocation timeline. Preserve the command line, interval, time, and workload conditions along with any screenshot or copied output.

Use iostat to frame storage questions

The iostat display helps identify which devices are busy and how I/O load changes over time. The exact fields depend on display mode and terminal space. A busy disk can indicate normal throughput, queueing, background maintenance, or an application bottleneck; it is not automatically a fault. Compare activity with application latency, queue depth where available, device errors, and GEOM topology.

An interval avoids relying solely on lifetime averages. At the command line, systat -iostat 1 refreshes the display every second. For a bounded non-interactive sample, use iostat(8) with an explicit wait and repeat count after checking its man page. Do not compare one tool’s aggregation window directly with another’s without noting the intervals.

For ZFS, the zarc display shows ARC statistics. It does not replace zpool iostat or a pool status check. The ARC cache can respond to memory pressure and workload changes; a large ARC is not itself evidence of a leak. Correlate the view with application response, swap activity, ZFS workload, and the FreeBSD memory-management behavior documented for the installed release.

Avoid making a storage change based only on apparent device utilization. The GEOM layer can aggregate or transform providers, and a physical device can serve multiple logical consumers. Map the device names back to the GEOM topology and compare with application-level operations before changing striping, queue settings, or filesystem layout.

Use ifstat for interface traffic, not path quality

The ifstat display reports traffic through active interfaces and normally presents current, peak, and total receive and transmit statistics. Idle interfaces may not be shown until they receive traffic. The manual documents display-specific match patterns and a packets-per-second toggle, which can be useful when byte rates hide small-packet load.

Example commands can constrain the view to known interfaces:

systat -ifstat -match em0,igc0 -- 1
systat -ifstat -pps -- 1

Replace em0 and igc0 with interfaces that actually exist. The systat manual notes that ifstat does not detect new interfaces while running; restart it after hot-plug or interface creation if the desired row is missing.

Traffic volume does not prove packet loss, latency, or useful application throughput. A high byte rate may be healthy, and a low rate may mean either idle demand or a broken path. Correlate with link state, error counters, retransmissions, route selection, firewall counters, and a bounded end-to-end test. Use packet capture only when the question requires it and capture filters are scoped.

Triage through a repeatable sequence

When a host is slow, record the time, host role, workload, recent changes, uptime, and symptom before interpreting the screen. Start with vmstat to see whether the contention appears CPU-, memory-, or scheduler-related. Switch to iostat or ifstat only after a signal suggests a subsystem. Compare multiple one-second samples and watch whether the behavior tracks a known request burst or background job.

Avoid switching among views so quickly that no interval is observed. If one view suggests disk pressure, check device and GEOM status, system logs, and application latency. If network traffic is unexpectedly absent, check interface state, routes, and host firewall counters. If ARC is large, compare memory pressure and workload rather than trying to shrink it as a reflex.

Collect durable evidence with commands designed for the relevant layer. Examples include vmstat with an interval and count, iostat with an interval and count, netstat snapshots, zpool iostat, top, and log timestamps. Validate the command syntax for the current FreeBSD release. Keep raw samples so another operator can reproduce the interpretation.

Know the measurement limits

A curses screen is transient and can be altered by terminal geometry, refresh timing, load, and the observer’s switching between displays. It may not preserve a baseline, correlate events across hosts, or make an audit trail. For production service levels, export metrics to a time-series system and define retention, labels, alert thresholds, and clock synchronization.

Do not treat percentages as absolute capacity. CPU user/system/interrupt/idle proportions say how time was accounted during the interval, not whether the application met its latency target. Disk I/O rates do not reveal all queueing or tail latency. Network rates do not identify congestion location. Each statistic should be paired with the question it can answer and a second measurement that checks the suspected cause.

The terminal itself can introduce blind spots. A 24-line display may omit devices, and a narrow terminal may truncate labels. If the expected CPU or disk does not appear, enlarge the terminal or use a machine-readable command. A clean-looking screen is not evidence that hidden devices or counters are healthy.

Operational handoff and acceptance

For an incident handoff, record the exact systat command, FreeBSD release, refresh interval, terminal size, workload, start/end time, and notable changes. Include associated command output and logs. Avoid documenting only a visual impression such as “CPU high” without the interval, percentage, and application effect.

Acceptance of a diagnostic session means that the view matches the intended host and interval, its key metrics are corroborated by subsystem-specific tools, and the next action is based on repeatable observations. Use systat as an interactive observability console, not as a replacement for alerting, historical telemetry, or a causal performance analysis.

Related:

Sources: