Wireless Access

last person joined: 18 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

High CPU on controller

This thread has been viewed 7 times
  • 1.  High CPU on controller

    Posted Jul 27, 2016 08:59 AM
      |   view attached

    We are seeing High CPU on the controller randomly ( 2or 3 minutes) and effecting the connectivty of the users and performance

     

    Do we have any inputs what are the CPU Queues 25 ,13, 17 and 23 from the show datapath utilization?

     

    Do we have any document speaking the about different queues (like STM - a brief descirption about it) of CPU 8 to 31 of the command output show datapath utilization?

     

    We did try changing snmp interval and moving to amon. BC/MC optimization on VAP and disabling ipv6 etc on the controller.

     

    I diid attach output of the log.

    Attachment(s)

    txt
    ouptut.txt   3 KB 1 version


  • 2.  RE: High CPU on controller

    EMPLOYEE
    Posted Jul 27, 2016 10:18 AM

    You could have spikes up to 80% with no material affect on user performance.  If the 80% is not sustained, it might not be an issue.  That message might or might not be important.  If you PM me, I can send you a link so that I can take a look at your logs.tar and see if anything seems wrong.

     

    When you say "connectivity and performance issue", what do you mean?



  • 3.  RE: High CPU on controller

    Posted Jul 27, 2016 10:43 AM

    Sure Colin. at the that specific moment when see the High CPU users loose connectivity and having trouble in connecting. if they are connected they have packet loss.



  • 4.  RE: High CPU on controller

    EMPLOYEE
    Posted Jul 27, 2016 10:50 AM

    Have you already opened a TAC case for this behavior?



  • 5.  RE: High CPU on controller

    EMPLOYEE
    Posted Jul 27, 2016 10:50 AM

    I personally would open a TAC case, as 99% actual is very unusual. TAC can look at the individual system logs from the debug tar logs and see what within fpapps is causing the issue. 



  • 6.  RE: High CPU on controller

    Posted Jul 27, 2016 10:58 AM

    i did open a case with TAC for the same seeing the CPU values going above 95% but trying to understand anything i can do by knowing the CPU queues to narrow done as its also effecting production.



  • 7.  RE: High CPU on controller

    EMPLOYEE
    Posted Jul 27, 2016 11:01 AM

    You should direct those questions to TAC, because they can see the full picture.



  • 8.  RE: High CPU on controller

    Posted Jul 27, 2016 11:04 AM

    ok Thanks Colin. Will work with TAC on the same . I was just trying see if anyone had seen any similar issues due to any specific traffic or anyother things etc.



  • 9.  RE: High CPU on controller

    EMPLOYEE
    Posted Jul 27, 2016 11:10 AM

    I wish we did know some of those more detailed investigative tips and tricks, but unfortunately most of us field facing guys are grunts. It's the guys in TAC that have the much needed deeper understanding of the CPU and control plane and usually they've seen previous cases to know what to look for right off the bat. Definatley though, as TAC how to narrow down/detail out CPU resource issues, most of the time they are happy to explain what to look for. Good luck!



  • 10.  RE: High CPU on controller

    EMPLOYEE
    Posted Jul 27, 2016 11:11 AM

    It is a good idea to post here to see if anyone has seen similar symptoms.  In this case, you have quite a few things that could cause what you are seeing.  Some of those things are known and in your case, it might be something that has never been seen before...



  • 11.  RE: High CPU on controller

    Posted Aug 18, 2016 02:04 AM

    We are still working with TAC on the same as it is Random Spike in CPU. Will keep you all posted if any good news



  • 12.  RE: High CPU on controller

    Posted Nov 16, 2017 08:41 AM

    Did you ever find resolution to those datapath spikes? Did TAC share a workflow for you to determine what traffic was causing the spikes?