Introduction
Here I have documented a scenario where periodic spikes are seen on Nexus 7000. The processes observed during such time causing spikes are routine processes which are run during general operation of the device.
Problem description
Periodic spikes registered on Nexus 7000 switch.
Analysis
Capturing 'show system internal process cpu' outputs several times shows that processes which are taking many CPU cycles are these:
- Dc3_sensor
- Octopus
- Xbar_driver
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3654 root 20 0 84188 5068 3316 S 23.2 0.1 804:53.41 dc3_sensor
3703 root -2 0 81652 5432 3332 R 23.2 0.1 1029:32 octopus
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3655 root -2 0 82732 6608 3332 S 40.3 0.1 3058:25 xbar_driver
Explanation
The processes listed are user-space drivers and are expected to perform periodic tasks
such as statistics collection, temp sensor reads, interrupt handling, status monitoring,
etc.
dc3_sensor: Polls all temp sensors. On the SUP it also polls the SPINE sensors.
Octopus: is the diver for theMidplane Interface and Abritration ASIC
xbar_driver: is the driver for the Fabric ASIC
In some cases accesses over slow two-wire buses such as the ones dc3_sensor & xbar_driver may take longer in the kernel than a normal ASIC access. The relative priority of all user-space drivers has been set such that drivers handling slower buses and performing non-time critical tasks (e.g. dc3_sensor) have a lower priority and will run when the others are done.
In the case of the Octopus driver, the ASIC hosts thousands of statistics that are collected periodically.
So basically spikes in these processes are normal to be seen when processor is not busy with control plane functions. When you configure more features in the system you may see more utilization from control plane packets/processes (which are of higher priority then these diagnostic processes) like routing updates.
Related Information
