Intermittent CPU usage on Cisco 2960?

Question

Computer networks

Good afternoon,
I encountered the following problem:
several Cisco Catalyst 2960 (WS-C2960X-48FPS-L) switches (stacks) began to periodically show a high level of CPU load during the day.
At the moment the problem is noticed on 5 switches.
Examples of high values ​​seen in real time from two stacks:

switchname1#show processes cpu sorted | exclude 0.00%
CPU utilization for five seconds: 82%/20%; one minute: 74%; five minutes: 66%

swithcname2#show processes cpu sorted
CPU utilization for five seconds: 82%/19%; one minute: 89%; five minutes: 78%

As you can see, both there and there a high level of itterupt-loading, i.e. maybe TCAM can't handle it and the packets are being processed on the CPU.
But, firstly, there are no entries related to TCAM in the logs (debbuging level), and secondly, if you look at TCAM utilization, at the time of high load, I see the following:

switchname1#show platform tcam utilization asic all

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

 Unicast mac addresses:                      16604/16604      3217/3217
 IPv4 IGMP groups + multicast routes:         1072/1072          1/1
 IPv4 unicast directly-connected routes:      2048/2048          0/0
 IPv4 unicast indirectly-connected routes:    1024/1024         34/34
 IPv6 Multicast groups:                       1072/1072         11/11
 IPv6 unicast directly-connected routes:      2048/2048          0/0
 IPv6 unicast indirectly-connected routes:    1024/1024          3/3
 IPv4 policy based routing aces:               504/504          13/13
 IPv4 qos aces:                                504/504          51/51
 IPv4 security aces:                           600/600         581/581
 IPv6 policy based routing aces:                20/20            8/8
 IPv6 qos aces:                                500/500          44/44
 IPv6 security aces:                           600/600          17/17

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization


CAM Utilization for ASIC# 1                      Max            Used
                                             Masks/Values    Masks/values

 Unicast mac addresses:                      16604/16604      3217/3217
 IPv4 IGMP groups + multicast routes:         1072/1072          1/1
 IPv4 unicast directly-connected routes:      2048/2048          0/0
 IPv4 unicast indirectly-connected routes:    1024/1024         34/34
 IPv6 Multicast groups:                       1072/1072         11/11
 IPv6 unicast directly-connected routes:      2048/2048          0/0
 IPv6 unicast indirectly-connected routes:    1024/1024          3/3
 IPv4 policy based routing aces:               504/504           0/0
 IPv4 qos aces:                                504/504          51/51
 IPv4 security aces:                           600/600         491/491
 IPv6 policy based routing aces:                20/20            0/0
 IPv6 qos aces:                                500/500          44/44
 IPv6 security aces:                           600/600          17/17

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization

  
swithcname2#show platform tcam utilization asic all

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

 Unicast mac addresses:                      16604/16604      1219/1219
 IPv4 IGMP groups + multicast routes:         1072/1072          1/1
 IPv4 unicast directly-connected routes:      2048/2048          0/0
 IPv4 unicast indirectly-connected routes:    1024/1024         34/34
 IPv6 Multicast groups:                       1072/1072         11/11
 IPv6 unicast directly-connected routes:      2048/2048          0/0
 IPv6 unicast indirectly-connected routes:    1024/1024          3/3
 IPv4 policy based routing aces:               504/504          13/13
 IPv4 qos aces:                                504/504          51/51
 IPv4 security aces:                           600/600         568/568
 IPv6 policy based routing aces:                20/20            8/8
 IPv6 qos aces:                                500/500          44/44
 IPv6 security aces:                           600/600          17/17

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization


CAM Utilization for ASIC# 1                      Max            Used
                                             Masks/Values    Masks/values

 Unicast mac addresses:                      16604/16604      1219/1219
 IPv4 IGMP groups + multicast routes:         1072/1072          1/1
 IPv4 unicast directly-connected routes:      2048/2048          0/0
 IPv4 unicast indirectly-connected routes:    1024/1024         34/34
 IPv6 Multicast groups:                       1072/1072         11/11
 IPv6 unicast directly-connected routes:      2048/2048          0/0
 IPv6 unicast indirectly-connected routes:    1024/1024          3/3
 IPv4 policy based routing aces:               504/504           0/0
 IPv4 qos aces:                                504/504          51/51
 IPv4 security aces:                           600/600         583/583
 IPv6 policy based routing aces:                20/20            0/0
 IPv6 qos aces:                                500/500          44/44
 IPv6 security aces:                           600/600          17/17

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization

What I think: these switches use per-user DACLs, which are loaded from ISE. On the same absolutely stacks, but where VACLs are used, the CPU is not loaded like that, and interrupts on them are 0-4% on average.
Can dacl clog TCAM in such a way that traffic processing goes to the processor?
Or dig in a different direction?
UPD. these switches do not participate in routing, debugging, which can load the CPU, is not running.

Answer 1

1) Yes Dacl can put a piece of iron. I met situations when 6500K hung, due to the use of DACL.
2) Look at the moment of loading which process eats up the most show proc cpu resources if I remember the command correctly.