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.
Periodic spikes registered on Nexus 7000 switch.
Capturing 'show system internal process cpu' outputs several times shows that processes which are taking many CPU cycles are these:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
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,
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.