I don't have hard numbers on CPU usage or memory usage.
But let's begin with the understanding that SCH was designed not to impact the normal functioning of the device. This includes rate-limiting the messages from the device and making sure that the callhome code sleeps between each command it is collecting for the message and has multiple breakpoints to allow other processes to assume control of the CPU.
Second, Callhome on the device typically sleeps until it is informed that it is needed. Essentially it sets an event flag and when the event occurs, the SCH process is triggered. So when no messages need to be sent, the process sleeps.
Also, most devices today forward data via hardware with the CPU simply updating the hardware forwarding table. So we are talking about how much does SCH affect the control plane - not the data plane (except on router platforms using CEF in software).
When an IOS device sends in a message, it has this output
router#call-home send alert-group inventory profile CiscoTAC-1
Sending inventory info call-home message ...
Please wait. This may take some time ...
The reason it says it might take some time is because it doesn't want to overwhelm the supervisor CPU or use it continuously.
When the Nexus sends a message, it does not give the same output
Nexus7000# callhome test inventory
trying to send test callhome inventory message
successfully sent test callhome inventory message
But since the Nexus forwarding is hardware based, it never affects data forwarding.
For rate-limiting SCH messages in IOS, we have the command
Router(cfg-call-home)# rate-limit 40
which rate limits from 1 to 60 messages per minute without regard to alert type. The default value is 20 messages per minute
Rate-limit: 20 message(s) per minute
For the Nexus 7000, we have the command
duplicate-message throttle
which rate limits messages according to each alert type. The number of messages for each alert group is set in software and can't be changed.
30 messages for *each* alert type can be sent every 2 hours from the time the first message is sent. Essentially it is a list of timers, one for each alert type, each timer has a counter initially set to 30. As soon as an alert type is sent, the countdown timer is set to 2 hours and the associated counter is decremented. 29 messages of the same alert type will be created and sent before the nexus 7000 will block anymore message of that alert type while the timer is still running. Once the timer has expired, it starts over and the first message sets the 2 hour timer again and decrements the counter that is reset to 30.
Most of the time very few messages are sent to SCH since it either goes bad and stays bad or it is a periodic message that is sent only once.
Finally, If the callhome message can't be sent at the time it is generated, the device will periodically try to resend the message stored in memory but it will sleep between retries.
