4 Serial network interface(s)
Configuration register is 0x0
...
------------------ show process cpu ------------------
CPU utilization for five seconds: 99%/97%; one minute: 70%; five minutes: 69%
即使只接受128Kbps的业务，VIP仍以99%的CPU利用率运行。这意味着CPU利用率与每秒传输的数据包数量无关，因为VIP 2能够交换比这多得多的数据包。这只是接收端缓冲的一个标志。
执行以下操作来检查接收端（Rx-side）缓冲在执行哪些功能：
router#show controllers vip 2 accumulator
show vip accumulator from Slot 2:
Buffered RX packets by accumulator:
...
Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in
Limit drops : 2644102 normal pak drops, 80 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
No MEMD buf: 0 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
...
Interface x:
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps
No MEMD acc: i in
Limit drops : j normal pak drops, k high prec pak drops
Buffer drops : l normal pak drops, m high prec pak drops
No MEMD buf: n in
Limit drops : o normal pak drops, p high prec pak drops
Buffer drops : q normal pak drops, r high prec pak drops
|
字符代码 |
说明 |
|
a |
MEMD中txacc的地址。系统中每个txacc（最多可有4096个）都有一个接收端（Rx-side）缓冲器。 |
|
b |
接收端缓冲的数据包数量。 |
|
c |
VIP丢弃的数据包数量。如果有足够的数据包存储器缓冲器，VIP最多可以在接收端将业务缓冲1秒；然而，如果接口连续拥塞，就可能无法避免数据包丢弃。 |
|
d |
目前在接收端被缓冲的数据包数量。 |
|
e |
目前被接收端缓冲的粒子数量。一个数据包可以由多个粒子（particles）组成。 |
|
f |
软限制：VIP存储容量较低时的最大粒子（particle）数量。 |
|
g |
硬限制：任何时候都可用的最大粒子（particle）数量。 |
|
h |
出局接口的速度，单位：kbps。 |
|
i |
由于MEMD中无txacc可用而被接收端缓冲的数据包数量。这表示输出队列被拥塞(tx.queue中没有更多空闲缓冲器)。解决这一问题的解决方案是增加输出接口带宽(如果可能的话)。 |
|
j |
IP优先级不是6或7的数据包数量，这些数据包由于没有MEMD帐号而不能被发送，而且会由于达到粒子的软或硬限制而被丢弃。 |
|
k |
与 j一样，但适用于IP优先级为6或7(互联网络和网络)的数据包。 |
|
l |
IP优先级不是6或7的数据包数量，VIP希望在接收端缓冲这些数据包，但是由于数据包存储器中没有空闲的缓冲器而被丢弃。从Cisco IOS软件版本12.0(13)S和12.1(4)以后，你还可以使用 show controller vip [all / slot#] packet-memory-drops 命令来查看丢弃的数据包数量。在这种情况下，升级数据包存储器会很有帮助。 |
|
m |
与 l一样，但适用于IP优先级为6或7(互联网络和网络)的数据包。 |
|
n |
VIP中由于没有MEMD缓冲器而试图在接收端进行缓冲但由于没有数据包存储器缓冲器而不能这样处理的数据包数量。在这种情况下，升级数据包存储器会很有帮助。从Cisco IOS软件版本12.0(13)S和12.1(4)以后，你还可以使用 show controllers vip [all / slot#] packet-memory-drops 命令来更好地了解这些数据包为何被丢弃。 |
|
o |
由于没有MEMD缓冲器而在接收端被缓冲的IP优先级不为6或7的数据包数量，这些数据包由于达到粒子的软或硬限制而被丢弃。在这种情况下，使用RSP16会很有帮助，因为它有更大的MEMD存储空间(8MB，而RSP1、RSP2、RSP4和RSP7000为2 MB)。减小某些接口(如ATM、POS或FDDI)的MTU也很有帮助。这些接口的MTU一般为4470个字节，而且可分配的MEMD缓冲器更少，因为这些缓冲器必须比较大。 |
|
p |
与 o一样，但适用于IP优先级为6或7(互联网络和网络)的数据包。 |
|
q |
VIP中由于没有MEMD缓冲器而试图在接收端进行缓冲但由于没有数据包存储器缓冲器而不能这样处理的数据包数量。这些数据包的IP优先级不是6或7。在这种情况下，升级数据包存储器会很有帮助。从Cisco IOS软件版本12.0(13)S和12.1(4)以后，你还可以使用 show controllers vip [all / slot#] packet-memory-drops 命令来更好地了解这些数据包为何被丢弃。 |
|
r |
与 q一样，但适用于IP优先级为6或7(互联网络和网络)的数据包。 |
如果路由器运行的Cisco IOS软件版本早于12.0(13)ST、12.1(04)DB、12.1(04)DC、12.0(13)S、12.1(4)、12.1(4)AA、12.1(4)T0、12.0(13)或12.0(13)SC，那么 show controllers vip [all / slot#] 累计器的输出就会显示以上信息的简化版本。它不会考虑由于接收端（Rx-side）缓冲而被丢弃的数据包的不同IP优先级。
输出显示如下：
Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in, 2644182 limit drops, 0 no buffer
No MEMD buf: 0 in, 0 limit drops, 0 no buffer
Interface x:
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps
No MEMD acc: i in, j+k limit drops, l+m no buffer
No MEMD buf: n in, o+p limit drops, q+r no buffer
[page]
接收端（Rx-side）缓冲实例
实例1：在该例中，插槽2中的VIP接收到128Kbps的业务并将它路由到串行10/0(64Kbps)。
Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in
Limit drops : 2644102 normal pak drops, 80 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
No MEMD buf: 0 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
544980个数据包成功地在接收端被缓冲，有2644182个被丢弃。被丢弃的2644182个数据包中有80个的IP优先级为6或7。
126个数据包目前正在接收端被缓冲，他们使用378个粒子。
由于MEMD的tx.queue中没有空闲的缓冲器，所以所有数据包都在接收端被缓冲。这意味着输出接口被拥塞。数据包被丢弃是因为达到了接收缓冲数据包的最大数量限制。这种情况下，一般的解决方案是升级出局接口带宽，重新路由一部分业务，从而减轻出局接口上的拥塞或使某些队列可以丢弃不太重要的业务。
实例2： 无数据包丢弃的接收端（Rx-side）缓冲
ATM1/0:
MEMD txacc 0x0082: 203504 in, 0 drops (0 paks, 0/81/37968 bufs) 155520kbps
No MEMD acc: 85709 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
No MEMD buf: 117795 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
在该例中，85709个数据包在接收端被缓冲，因为ATM 1/0被拥塞但没有数据包被丢弃。
117795个数据包在接收端被缓冲，因为VIP不能得到MEMD缓冲器。没有数据包被丢弃。一般的解决方案是减小某些MTU的大小以分配更多MEMD缓冲器。使用RSP8将很有帮助。
实例3： 本地交换
SRP0/0/0:
local txacc 0x1A02: 2529 in, 0 drops (29 paks, 32/322/151855 bufs) 622000kbps
本地txacc意味着该输出接口与接收数据包的接口位于同一VIP上。这些数据包在本地交换，但出局接口(在该例中为srp 0/0/0)被拥塞。2529个数据包在接收端被缓冲，但是没有数据包被丢弃。
实例4： 前向队列
router#show controllers vip 2 accumulator
Buffered RX packets by accumulator:
Forward queue 0 : 142041 in, 3 drops (0 paks, 0/24414/24414 bufs) 100000kbps
No MEMD buf: 142041 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 3 normal pak drops, 0 high prec pak drops
Forward queue 9 : 68 in, 0 drops (0 paks, 0/15/484 bufs) 1984kbps
No MEMD buf: 68 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
Forward queue 13: 414 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps
No MEMD buf: 414 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
Forward queue 14: 46 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps
No MEMD buf: 46 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
某些数据包不能被分配交换。在这种情况下，VIP必须将这些数据包转发到原始的RSP队列中。在数据包不能被立即复制到MEMD的情况下，VIP对它们进行接收缓冲并跟踪每个入局接口上接收缓冲的数据包数量。
前向队列0.7用于第一个端口适配器(PA)，而8.15用于第二个PA。
|
前向队列编号 |
...显示...上接收到的被接收缓冲的数据包数量 |
|
0 |
第一个端口适配器(PA)的第一个塞孔（plughole） |
|
8 |
第二个PA的第一个塞孔（plughole） |
|
9 |
第二个PA的第二个塞孔（plughole） |
[page]
导致VIP上CPU利用率较高的其他原因
当发现接收端（Rx-side）缓冲不再运行但VIP上CPU利用率仍然较高时，应检查以下内容：
由分布式业务整形导致的VIP上CPU利用率高达99%
如果配置了分布式业务整形(dTS)，数据包一进入dTS队列，VIP CPU的利用率就会迅速上升到99%。
这是正常的也是预料之中的行为。配置了dTS时，VIP CPU就会在CPU处于空闲状态（无业务通过）的下一时间间隔(Tc)到来时进行检查。否则，检查就会在发送/接收过程中捎带进行。由于我们只在CPU空闲时对其进行检查，因此不会影响性能。
如想了解何为“下一时间间隔（next time interval）”，请参见《 What Is a Token Bucket?》
注： 整形必须在整形队列中对一个数据包进行排队时进行，换句话说，当业务数量超过整形速率时。这就说明了配置了dTS时为何VIP CPU的利用率始终为99%。有关dTS的更详尽信息可通过以下链接获得：
分布式业务整形
配置分布式业务整形
欺骗性内存访问和校正错误引起的高VIP CPU利用率
校正错误和欺骗性内存访问属于软件故障，可通过Cisco IOS软件纠正而不会导致VIP崩溃。如果这种错误频繁出现，就会导致操作系统进行大量纠正操作，从而使CPU利用率很高。
有关校正错误和欺骗性内存访问的更详尽信息请参见《 排除欺骗性访问、校正错误和欺骗性中断故障》。
使用 show alignment 命令来检查欺骗性内存访问和校正错误。这样的错误举例如下：
VIP-Slot1#show alignment
No alignment data has been recorded.
No spurious memory references have been recorded.
导致CPU利用率高的其他原因包括激活的分布式特性的数量和程度。如果您怀疑这是导致利用率高的原因，或不能确定是本文所描述的原因导致CPU利用率较高，我们建议您联系Cisco技术援助中心以进行进一步的故障排除。
在TAC开立案例需要收集的信息
通过使用 案例更新工具 ( 只适用于 注册客户) 进行加载，您可以将信息附在案例后面。如果您不能访问案例更新工具，您可以将信息以电子邮件附件的形式发往 attach@cisco.com ，在所发信息的主题行标明案例号，从而将相关信息附在案例中发送。 注：?/B>在收集上述信息之前请不要手工重新启动或加电启动路由器（除非恢复网络正常运行需要），因为这可能会导致确定故障根本原因所需重要信息的丢失。 |
转载地址：http://www.net130.com/CMS/Pub/Tech/tech_config/85055.htm
