2621xm mounting interrupts causing horrid performance over a month

Unanswered Question
Mar 10th, 2008
User Badges:

I have a strange situation. I had a 1721 out at a site, that had mounting interrupts, degrading VOIP performance until it needed to be rebooted every three weeks. We upgraded it to a 2621xm, and the same thing occured -- although after four weeks, instead of three weeks, and the quality was improved up to the failure point.


The log was full of these


Mar 7 09:06:18.386 PST: %SNMP-4-HIGHCPU: Process exceeds 200ms threshold (200ms IOS quantum) for GETNEXT of rmon.19.15.0--result rmon.19.16.0


Process interrupts went as high as 99%.


Things are better currently, and I've asterixed the changes that have been made recently. The IOS version is c2600-ipbasek9-mz.124-17a.bin with 98 megs/32 megs of memory. I have been through http://www.cisco.com/en/US/customer/products/hw/routers/ps133/products_tech_note09186a00800a70f2.shtml and http://www.cisco.com/en/US/customer/products/hw/routers/ps133/products_tech_note09186a00800a70f2.shtml. There is no process over 2% in show proc cpu. Show ip traffic had nothing interesting. Show int switching had 2:3 process:fast switching on the multilink, and 3:1 p:f for the chars. (After the asterixed changes, things improved to 1:3 and 1:10, so we may be on the path to improvement. Process interrupts have improved as well.)


Any idea what caused this? I'd love to hear theories...



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
paolo bevilacqua Mon, 03/10/2008 - 12:47
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Seems a case of data structure trashing, or memory fragmentation. These are not good things, and can require a lot of time be sorted out. I suggest you seek help from the TAC, be very proactive in sending alla the requested data, ask for escalation and be patient.

Actions

This Discussion