[c-nsp] RE: Unknown reason for High CPU 3620
Rodney Dunn
rodunn at cisco.com
Wed Nov 3 12:14:42 EST 2004
btw, I missed the fact that you said it's all
bridging traffic. Without testing it in the lab
I can't say if that's expected or not. The bridging
code is not as good as the performance for normal packet
switching code.
Rodney
On Wed, Nov 03, 2004 at 11:08:14AM -0500, Rodney Dunn wrote:
> CPU load at interrupt level is almost always packet
> switching/features or alignment/spurious access corrections.
>
> This CPU sounds high for that amount of traffic.
>
> Can you list the full configuration /*taking out
> any confidential stuff*/ so we can see the features
> enabled?
>
> 2nd, you really need to clean up that ethernet
> segement with all the collisions. Can you convert
> it to full-duplex? I don't recall if you can do it
> with the 3620 in later code.
>
> Most likely it's not an issue with the ATM side.
>
> Rodney
>
>
> On Wed, Nov 03, 2004 at 03:44:07PM -0000, Alex Foster wrote:
> > Thanks to the guys who responded - I have managed to narrow down the
> > cause to high interrupt utilization and not processor utilization - but
> > Im still a little unclear as to what is causing the high interrupt util.
> > - is the ATM interface causing this ? Again the traffic load is little
> > over 1.5 meg (in/out) - but constant - so I am wondering if the
> > continual SARing is maybe having a negative effect on the CPU ? If so -
> > is there a workaround or am I looking at a bigger platform to solve the
> > issue - if so any recommendations (I have a 3640 available but don't
> > know if this will provide much of an improvement).
> >
> >
> >
> > Regards
> >
> >
> >
> > Alex
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Alex Foster
> > Sent: 03 November 2004 13:37
> > To: 'cisco-nsp at puck.nether.net'
> > Subject: Unknown reason for High CPU 3620
> >
> >
> >
> > I have a 3620 that is currently maxing out its CPU for no apparent
> > reason - the traffic load on it at the moment is about 1 to 2 meg - and
> > sh proc cpu doesn't indicate any process that is causing the high CPU
> > util. Most of the traffic is SIP but I wouldn't have thought this would
> > have any bearing. There are only two interfaces on the box in use - an
> > ATM 155 and a 10bt. The traffic from the 10bt is bridged to a PVC on
> > the ATM interface - nothing complicated.
> >
> >
> >
> > #sh proc cpu
> >
> > CPU utilization for five seconds: 96%/93%; one minute: 90%; five
> > minutes: 91%
> >
> > PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
> >
> > 1 194708 9899756 19 0.00% 0.00% 0.00% 0
> > Load Meter
> >
> > 2 2008 223 9004 1.41% 0.13% 0.03%
> > 66 Virtual Exec
> >
> >
> >
> > #sh mem sum
> >
> > Head Total(b) Used(b) Free(b) Lowest(b)
> > Largest(b)
> >
> > Processor 61D70EA0 12120416 6616992 5503424 5303744
> > 5305428
> >
> > I/O 2900000 7340032 4387068 2952964 2920520
> > 2947260
> >
> >
> >
> > #sh int e1/0
> >
> > Ethernet1/0 is up, line protocol is up
> >
> > Hardware is AmdP2, address is 0005.3245.e070 (bia 0005.3245.e070)
> >
> > Description:
> >
> > MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
> >
> > reliability 255/255, txload 34/255, rxload 37/255
> >
> > Encapsulation ARPA, loopback not set
> >
> > Keepalive set (10 sec)
> >
> > ARP type: ARPA, ARP Timeout 04:00:00
> >
> > Last input 00:00:00, output 00:00:00, output hang never
> >
> > Last clearing of "show interface" counters 1y4w
> >
> > Queueing strategy: fifo
> >
> > Output queue 0/40, 0 drops; input queue 0/75, 103522 drops
> >
> > 5 minute input rate 1470000 bits/sec, 1984 packets/sec
> >
> > 5 minute output rate 1355000 bits/sec, 2166 packets/sec
> >
> > 2150894411 packets input, 1646909945 bytes, 0 no buffer
> >
> > Received 88151770 broadcasts, 0 runts, 0 giants, 0 throttles
> >
> > 6397644 input errors, 42166 CRC, 32878 frame, 0 overrun, 6355422
> > ignored
> >
> > 0 input packets with dribble condition detected
> >
> > 2681876495 packets output, 1769855380 bytes, 0
> > underruns(556991/1663306/0)
> >
> > 165 output errors, 2220297 collisions, 50 interface resets
> >
> > 0 babbles, 47 late collision, 1067254 deferred
> >
> > 118 lost carrier, 0 no carrier
> >
> > 0 output buffer failures, 0 output buffers swapped out
> >
> >
> >
> > #sh int atm 0/0.2
> >
> > ATM0/0.2 is up, line protocol is up
> >
> > Hardware is RS8234 ATMOC3
> >
> > MTU 4470 bytes, BW 155000 Kbit, DLY 80 usec,
> >
> > reliability 255/255, txload 2/255, rxload 2/255
> >
> > Encapsulation ATM
> >
> > 3075506957 packets input, 1094442885139 bytes
> >
> > 2362546968 packets output,988686523562 bytes
> >
> > 0 OAM cells input, 0 OAM cells output
> >
> > AAL5 CRC errors : 81
> >
> > AAL5 SAR Timeouts : 0
> >
> > AAL5 Oversized SDUs : 0
> >
> > AAL5 length violation : 26
> >
> > AAL5 CPI Error : 0
> >
> >
> >
> > Thanks
> >
> >
> >
> > Alex
> >
> >
> >
> > The information in this e-mail and any attachments is confidential and may be subject to legal professional privilege. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are prohibited from, and therefore must not, read, copy, distribute, use or retain this message or any part of it. The views expressed in this e-mail may not represent those of Gamma Telecom.
> >
> > This message has been scanned for viruses by MailController
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list