VMware ESXi and vSphere Cluster Management

Show Running Processes on Cisco IOS Devices

Learn how to use Cisco IOS show processes to interpret CPU utilization, process fields, scheduler states, and investigate sustained high CPU.

Cisco IOS runs many internal processes for routing, switching, protocol handling, management access, logging, and background operating-system tasks. The show processes command displays these processes and provides CPU-related counters that help you investigate device performance.

This lesson is useful when a router or switch has unusually high CPU utilization, slow CLI or remote-management access, delayed routing-protocol convergence, or degraded forwarding performance. A process list identifies candidates for further investigation; it does not prove the root cause by itself.

Prerequisites

Know how to enter Cisco IOS privileged EXEC mode.
Understand basic CPU utilization and IOS show commands.
Use a methodical troubleshooting process: observe, compare with a baseline, correlate symptoms, and then make changes.

Run show processes

Enter the following command from privileged EXEC mode:

Router# show processes

The output begins with overall CPU utilization measurements and then lists active IOS processes. Exact columns, process names, and available details vary by IOS release, hardware platform, enabled features, and device role.

Some platforms and releases also support the related command below:

Router# show processes cpu

show processes cpu is an optional, more focused CPU diagnostic view. Use it only where the platform and IOS release support it; do not assume that every device presents the same output.

Read the CPU utilization summary

The CPU summary normally reports rolling utilization for three intervals:

Last 5 seconds: shows recent activity and can expose a short burst.
Last 1 minute: provides a view of more sustained activity.
Last 5 minutes: helps reveal whether the device has remained busy over a longer period.

Interpret all three values together. A high 5-second value with much lower 1-minute and 5-minute values usually indicates a recent or temporary spike. High values across all three intervals indicate sustained load and deserve deeper investigation.

Some platforms also show interrupt CPU information. Total CPU utilization represents processor use across the reported activity, while interrupt CPU is the portion spent handling hardware or packet-related interrupts. A high interrupt value points toward a different investigation path than a high process-level value, so keep the two measurements distinct when the platform reports both.

Observation	Likely Interpretation	Recommended Next Step
High 5-second value with lower 1-minute and 5-minute values	A brief CPU burst is more likely than sustained exhaustion.	Repeat the command and look for a temporary traffic, logging, or management event.
High values across all time windows	The device is under sustained CPU load.	Compare process counters and correlate them with interfaces, protocols, logs, and traffic.
High Runtime for a process	The process has accumulated substantial CPU time.	Check whether Runtime is growing unusually quickly during repeated captures.
High Invoked with low microSecs	The process runs frequently, but each execution is brief.	Do not label it faulty from invocation count alone; compare total Runtime and expected workload.
High microSecs per invocation	Each execution is relatively expensive.	Correlate the process with configuration, traffic, protocol, and logging changes.
`hg` scheduler state	The process is reported as hung.	Record diagnostic details and use platform-appropriate escalation procedures.

Understand the process-list columns

Process entries commonly include fields such as PID, Q, Ty, PC, Runtime, Invoked, microSecs, Stacks, TTY, and Process. Treat these fields as a set: one large value is not automatically evidence of a fault.

Field	Meaning	How to Use It During Troubleshooting
PID	Process ID, the internal numeric identifier assigned to the process.	Use it to distinguish processes and identify the exact entry in repeated captures or support records.
Q	Queue priority used by the scheduler.	Shows scheduling treatment, but priority alone does not identify a faulty process.
Ty	Scheduler state, such as running, waiting, ready, sleeping, hung, or terminated.	Use it with CPU counters and repeated observations. A waiting or sleeping state is often normal.
PC	Program Counter, an internal execution address or code-location value.	Primarily useful for advanced diagnostics and Cisco support, not routine fault identification.
Runtime	Cumulative CPU time consumed by the process.	Compare it across processes and over time. A rapidly increasing value can identify an active CPU consumer.
Invoked	The number of times the scheduler has executed the process.	Use with microSecs. A high count can be normal when each invocation is very brief.
microSecs	Average CPU time consumed per invocation, expressed in microseconds.	A high value indicates expensive individual executions, even when the process runs infrequently.
Stacks	Process stack-related information, such as low-water or available stack values depending on the IOS output.	Use as supporting information, especially when investigating stack exhaustion or advanced software issues.
TTY	The controlling terminal associated with the process, when one exists.	Can help relate a task to a terminal or management session; many system processes have no useful terminal association.
Process	The human-readable process name.	Relate the name to enabled features, recent changes, traffic conditions, and device logs.

Process queue-priority values

Queue priority describes how IOS classifies a process for scheduling. It is context, not a fault diagnosis.

Value	Priority Meaning
C - Critical	Critical priority.
H - High	High priority.
M - Medium	Medium priority.
L - Low	Low priority.

A critical or high-priority process is not automatically defective. Important operating-system and control-plane work may appropriately receive higher scheduling priority.

Process scheduler states

The Ty field reports a scheduler state. State abbreviations can vary by platform or software release, so use the device's displayed legend when available.

State	Meaning	Troubleshooting Interpretation
*	Currently running.	The process is executing at the time represented by the output.
E	Event-waiting.	The process is waiting for an event or condition rather than continuously using the CPU.
S	Sleeping.	The process is inactive until its work or wake-up condition occurs; this is commonly normal.
rd	Ready to run, including a process that voluntarily yielded the processor.	The process can run when the scheduler gives it CPU time.
we	Waiting for an event, with the wake-up condition involved in its scheduling state.	Interpret with the process name and counters; waiting does not by itself indicate failure.
sa	Sleeping until an absolute time.	The process is scheduled to wake at a particular time.
si	Sleeping for a time interval.	The process is waiting for its interval to expire.
sp	Sleeping through an alternate or interruptible interval mechanism.	Usually indicates a wait condition, not CPU exhaustion by itself.
st	Sleeping until a timer expires.	Review repeated output if the process remains unexpectedly stuck.
hg	Hung.	The process is reported as not expected to run again. Record details and escalate persistent or recurring cases.
xx	Terminated or dead, but not yet removed.	A short-lived entry may be normal; recurring or accumulating terminated entries require further investigation.

Find a potentially CPU-intensive process

Start with the 5-second, 1-minute, and 5-minute CPU values. Decide whether the load is transient or persistent.
Compare Runtime across process entries. Runtime is cumulative, so it is most useful when captured repeatedly and compared over time.
Review Invoked and microSecs together. A process with many brief invocations may be normal, while a process with fewer but expensive invocations can still consume significant CPU.
Use the process name as a clue. Correlate it with recent configuration changes, traffic bursts, enabled routing or switching features, protocol activity, management access, and logs.
Repeat the command during the problem. A single snapshot cannot show whether counters are growing rapidly or remaining stable.

Example: frequent lightweight work versus expensive work

Suppose process A has a very high invocation count but a low average microseconds-per-invocation value. Process B runs less often but has a much higher microSecs value. Process A may be performing expected, lightweight periodic work, while process B may be doing expensive work each time it runs. Compare both processes' Runtime values and observe how they change across repeated captures before drawing a conclusion.

Example: interpreting a waiting process

A process shown in an event-waiting or sleeping state is often idle while it awaits work, a timer, or an event. Do not treat the state alone as an error. Consider the process name, CPU counters, state changes, and overall CPU trend.

Safe troubleshooting workflow

Build a baseline. Capture show processes during normal operation when possible. Record the software version, platform, time, and relevant traffic or protocol conditions.
Capture during the incident. Run the command repeatedly during reported slowness or high CPU. Compare all three CPU intervals and note process counters that change significantly.
Correlate symptoms. Check interface statistics, traffic conditions, routing-protocol neighbors, protocol changes, logging activity, and management access at the same time.
Form a hypothesis. Decide whether the evidence points toward process-level work, interrupt activity, a protocol event, traffic handling, logging, or another platform-specific condition.
Avoid disruptive guesses. Do not disable a feature, clear sessions, reload a device, or otherwise make a disruptive change solely because a process appears in the list.
Escalate when appropriate. Persistent high CPU, unknown process behavior, recurring hung states, or unexplained performance degradation should be documented and escalated through established, platform-appropriate support procedures.

Worked troubleshooting scenarios

Only the 5-second CPU value is high

The device is slow to respond, but the 1-minute and 5-minute values are much lower. This suggests a brief burst rather than sustained CPU exhaustion.

Repeat show processes after a short interval.
Compare the three rolling values again.
Look for a temporary traffic burst, logging event, routing update, or management operation.

All CPU intervals remain high

Elevated 5-second, 1-minute, and 5-minute values indicate sustained load. Identify processes with rapidly growing Runtime or unusually high microSecs values, then correlate their names with interface activity, routing changes, control-plane events, traffic, and logs. Collect additional platform diagnostics before making changes.

A process has a very high invocation count

Invocation frequency alone does not establish excessive CPU consumption. Compare the process's microSecs and Runtime values with other processes and determine whether it is handling expected high-volume work.

A process is reported as hung

The hg state indicates that the process is reported as hung and is not expected to run again. Record the process name, PID, CPU summary, software version, device time, repeated command output, and relevant logs. Check for recurring symptoms and use established escalation procedures because remediation can be platform- and defect-specific.

Exam-relevant notes

show processes is a privileged EXEC command used to display IOS processes and CPU information.
The 5-second value shows recent activity; the 1-minute and 5-minute values help distinguish a spike from sustained load.
Runtime is cumulative CPU time, Invoked is execution count, and microSecs is average CPU time per invocation.
A high invocation count with a low per-invocation time is not automatically a problem.
Priority and scheduler state provide context; neither should be used alone to identify the root cause.
A waiting or sleeping process is often normal, while a hung state requires additional investigation.
Process output identifies candidates for investigation; it does not independently prove the cause of high CPU.

For a concise reference, return to Show Running Processes.