I know this is an old thread, but it's the first that comes up in my google search, so I'm updating it to get the most attention. After investigating lots of TAC cases for this error, it seems the root cause is almost never related to too many snmp polls. The queue size is fixed at 1000 (it cannot be changed, even with the snmp queue-length command) which should be plenty for most cases. The reason for the queue backing up is most commonly a specific OID, taking too long, which causes all subsequent snmp requests to backup on the queue.
There are ways for TAC to find the guilty OID, and there are workarounds, as discussed on the thread, but users should beware of blocking the guilty OID's, because it will prevent NMS stations from getting full data from the Cisco devices. Restarting the snmp process is only a temporary measure, and the problem is expected to return eventually.
We are working on an enhancement, CSCuz93302, initially for catalyst 6500 that will make this error less vague and identify the SNMP that is taking too long to run. That should allow users to solve these cases reliably through google searches.
