如何排除高数据飞机的故障 CPU

A 许多因素可能导致数据飞机的 CPU 峰值或持续运行高位：由于实施新服务或资源而突然增加，或者由于连接网络、段和主机的添加而随着时间的推移而增加。 这些因素和更多因素可能导致数据包速率、数据包缓冲区利用率或每秒大量新连接的增加，导致数据平面 CPU 达到临界水平。

学习故障排除高数据飞机 CPU 。 本文显示了验证数据平面实际负载并帮助确定对网络的潜在影响的几种方法。

了解高数据飞机的影响 CPU 很重要：高数据飞机 CPU 的使用可能不会立即引起关注，但了解造成高 CPU 和可能后果的原因将有助于您做出适当的响应。 

采取行动前需要确定的几个因素：

• 是一些，全部，或没有通过受影响的交通 firewall ？
• 用户遇到高延迟，并且如果是这样，并延迟影响所有交通或只是某些应用程序吗？
• 如果报告的问题，都这些报告恰逢特定高峰时间的一天，在固定的时间间隔，或在完全随机的时刻吗？

第一步是隔离性能问题发生的位置：

• 数据平面 （ DP ） CPU
• 数据包缓冲区
• 会话
• 管理平面 （ MP ）

当客户报告性能问题时，在问题发生时生成技术支持文件。 在dp-Monitor日志中查找"---panio"字符串（此信息每 10 分钟记录一次），或从 CLI 查看资源使用情况运行运行资源监视器命令 DP 。

显示运行资源监视器

此命令可用于查看数据飞机 CPU 的使用情况。 添加一个时间运算符，以反映出您想要查看的时间。

• "秒"以 CPU 每秒增量显示使用的最后 60 秒
• 分钟显示最后的 60 分钟分钟增量等等
• 如果使用没有时间运算符时，所有视图将都列出在一个长时间输出

>显示运行资源监测
>每天
监测统计数据>每小时监测统计数据
>入站积压显示的统计数据
>分钟每分钟监测统计数据
>每周监测统计>秒第二
次监测统计数据

实际输出看起来与此类似，但可能会略有不同，具体取决于您的系统拥有的数据平面和核心的数量。

>显示运行资源监视器

DP dp0:

资源监测采样数据 （每秒）︰

第一节显示 CPU 数据飞机上运行的过程的利用率

CPU 按组分组进行负载抽样
：flow_lookup：0%flow_fastpath：0%flow_slowpath：0%flow_forwarding：0%flow_mgmt：0%flow_ctrl：1%nac_result：0%flow_np

：




0%
dfa_result ： 0%
module_internal ： 0%
aho_result ： 0%
zip_result ： 0%
pktlog_forwarding ：
0% lwm ： 0%
flow_host ： 1%

输出的这一部分显示了数据飞机上单个内核的利用率。
许多核心经常超过75%值得调查。

CPU负载 （%）during last 60 seconds:
core  0  1  2  3  4  5  6  7  8  9  10  11
0  39 47 38 46 73 81 73 81 82 88  83
0  39 46 38 45 73 82 73 82 82 89  82
0  39 46 39 45 73 81 73 81 83 88  83
0  38 52 37 50 71 81 71 80 82 98  82
0  40 46 39 45 74 82 74 82 83 89  83
0  40 50 39 49 74 85 74 84 83 90  83
0  39 46 38 45 72 81 72 81 81 88  81
0  42 52 41 50 75 86 75 86 84 91  84
0  42 76 79 85 75 10075 100100100 85 >>> indicates actual highCPU
0  44 51 43 50 78 85 78 86 86 91  86
0  42 51 41 50 76 86 76 86 85 92  85
0  43 53 43 52 77 89 77 89 86 93 86
0 38 46 37 45 71 81 72 81 88 81
0 42 50 41 50 76 85 76 85 85 90 85.。。
本


节显示会话表的利用率，这是平台支持的最大活动会话数。                  任何价值超过 80% 的都值得调查。

资源利用率（%）在最后60秒：
会话
：0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

接下来的3个部分显示数据包缓冲区利用率。数据包缓冲区用于确保之前的数据包仍在通过核心或进程处理时不会丢失数据包。 任何超过 80% 的值都需要进行调查。

包缓冲区
：0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

包 描述符
：0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  

数据包描述符 （芯片上）：
2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

要检查输出的事项：

1. 在最后 CPU 60 秒检查负载。 如果任何数字处于或接近 100，则高 CPU 可能是性能问题的原因。
2. 检查"数据包缓冲区"和"数据包描述器"部分。 如果任何数字处于或接近 100，则问题可能是由于数据包缓冲区用完造成的。
3. 检查会话部分。 如果任何数字接近或超过 80，则性能问题很可能与会话相关。

有几个命令，可以帮助确定某些测量是在资源监视器中阈值以上的原因：

显示会话信息

输出与支持多少会话、当前活动次数相关的所有数据，并将通知您有关数据包速率、新连接建立速率和吞吐量的信息。 如果这些参数中的任何一个异常高，则可能导致数据平面 CPU 上升。

> 显示会话信息

目标dp：*.dp0--------------------------------------------------------------------------------

支持的会话数：262142
活动会话 < If this figure rises to the level of the supported sessions,
数：3个活动 TCP 会话数：0平台正在达到最大容量。
活动 UDP 会话数： 1
活动 ICMP 会话数： 0
活动 BCAST 会话
数： MCAST 0 活动会话数：
0 主动预测会话数： 0
会话表利用率：
启动后创建的会话数： 332481
数据包速率：28/s异常和突然的高分组速率可能表示 DoS 攻击。
吞吐量：13 kbps
新连接建立速率：0 cps
--------------------------------------------------------------------------------
会话超时
如果超时值过于激进或过于放松，系统可能会耗尽资源。
TCP默认超时：收到之前3600秒
TCP 会话超时 SYN-ACK
TCP ：3向握手前的5秒会话超时：10秒
TCP 半封闭会话超时
TCP ：120秒会话超时TIME_WAIT：15秒
TCP 会话 未验证的超时 RST ：30秒
UDP 默认超时：30秒
ICMP 默认超时：6秒
其他 IP 默认超时：30秒
俘虏门户会话超时：30秒
会话超时在丢弃状态
TCP ：：90秒， UDP ：60秒， 其他 IP 协议：60 秒
--------------------------------------------------------------------------------
会话加速老化：诚然
，如果加速老化已被关闭，某些会话可能会在会话表中保持活跃
的时间超过需要，并占用资源。
加速老化阈值：80% 的利用
率缩放系数：2 X
--------------------------------------------------------------------------------
会话设置
如果其中任何一个已关闭以进行故障排除且未重新打开，它们可以
消耗额外的资源来检查
本来会丢弃的畸形数据包。
TCP -拒绝非 SYN 第一包：真正的
Hardware 会话卸载：真正的
IPv6防火墙：真正的
严格 TCP / IP 检查：真正的
ICMP 无法访问的数据包率：200 pps--------------------------------------------------------------------------------

应用程序滴答作响扫描参数：
超时以确定应用程序滴答声： 10 秒
资源利用阈值开始扫描
：80% 扫描扩展因子超过常规老化：8
--------------------------------------------------------------------------------
当资源限制达到时会话行为：删除
此表示 firewall 其达到
其极端资源消耗极限时的行为。
--------------------------------------------------------------------------------
Pcap 令牌存储桶速率： 10485760
--------------------------------------------------------------------------------
最大等待排队的 mcast 数据包每会话： 0
--------------------------------------------------------------------------------
 

调试 dataplane 池统计信息

返回系统使用的所有缓冲区的状态及其状态。

• 左边的数字表示多少缓冲区仍可用
• 右边的数字表示的总大小
• 如果数字在左降至 0，耗尽缓冲区

> 调试 dataplane 池统计信息

Hardware 池
[0] 数据包缓冲区 ： 57223/57344 0x8000000030c00000
[1] 工作队列条目 ： 229315/229376 0x8000000037c00000
[2] 输出缓冲区 ： 1007/1024 0x800000000fc00000
[ 3] DFA 结果： 3995/4000 0x8000000039800000
[4] 时间缓冲区 ： 4096/4096 0x8000000039be8000
[5] PAN_FPA_LWM_POOL ： 1024/1024 0x800000000fd00000
[6] ZIP 命令： 1023/1024 0x800000000fd40000
[7] PAN_FPA_BLAST_PO ： 1024/1024 0x800000000ff40000

Software Pools
[ 0] software packet buffer 0 ( 512): 32767/32768 0x8000000043b2a680
[ 1] software packet buffer 1 ( 1024): 32768/32768 0x8000000044b4a780
[ 2] software packet buffer 2 ( 2048): 81920/81920 0x8000000046b6a880
[ 3] software packet buffer 3 (33280): 20480/20480 0x8000000050bba980
[ 4] software packet buffer 4 (66048): 304/304 0x80000000795cea80
[ 5] Shared Pool 24 ( 24): 560000/560000 0x800000007a8f6780
[ 6] Shared Pool 32 ( 32): 530000/530000 0x800000007b7eaa80
[ 7] Shared Pool 40 ( 40): 70000/70000 0x800000007ca1cf00
[ 8] Shared Pool 192 ( 192): 1269999/1270000 0x800000007cd0cf80
[ 9] Shared Pool 256 ( 256): 140000/140000 0x800000008ba70880
[10] ZIP Results ( 184): 1024/1024 0x80000000a1827300
[11] CTD AV Block ( 1024): 32/32 0x80000000be43d380
[12] Regex Results (11544): 8000/8000 0x80000000be466100
[13] SSH Handshake State ( 6512): 64/64 0x80000000c580c680
[14] SSH State ( 3248): 512/512 0x80000000c5872480
[15] TCP host connections ( 176): 15/16 0x80000000c5a08e80

是显示计数器的全局过滤器三角洲

返回，从命令第二次发出后，在当前和以前的迭代之间的时间范围内触发的全球计数器的快照，并可能暴露异常数量的丢弃包。

>> 显示计数器全局筛选器三角洲是

全球计数器：
自上次采样以来的过时时间 ：2.981 秒

名称值率严重性类别方面描述

--------------------------------------------------------------------------------pkt_recv 89 29 信息包 pktproc 数据包
收到pkt_recv_zero 87 29 信息包 pktproc 包收到从 QoS 0
pkt_sent 3 1 信息包 pktproc数据包
session_allocated 1 0信息会话资源session_freed
分配session_freed 1 0信息会话资源会话释放
session_installed 1 0信息会话资源会话安装
flow_arp_pkt_rcv 83 27信息流arp ARP 数据包
收到flow_arp_pkt_rcv flow_host_pkt_rcv 2 0信息流mgmt从控制平面收到的数据包
flow_host_pkt_xmt 2 0信息流mgmt数据包传输到控制平面
flow_host_service_allow 2 0信息流mgmt设备管理会话允许
appid_ident_by_icmp 1 0信息应用程序 icmp 类型识别的 pktproc 应用程序dfa_sw
2 0 信息 dfa pktproc 使用软件的 dfa 匹配总数
aho_sw 1 0 信息 aho pktproc 软件的总使用量为 AHO
ctd_pkt_slowpath 2 0 信息 ctd pktproc 数据包由慢路径
处理pkt_flow_np 87 29 信息数据包资源数据包进入模块流阶段 np
pkt_flow_host 2 0 信息包资源数据包进入模块流阶段主机
--------------------------------------------------------------------------------
总计数器显示： 16
--------------------------------------------------------------------------------

一些常见的计数器解释说：

显示系统统计会议

以实时仪表板方式显示所有数据飞机的聚合数据包率和吞吐量值，自动刷新

系统统计：（"q"退出，"h"寻求帮助）

设备已打开： 0 天 2 小时 34 分 57 秒
分组速率 ： 32/s
吞吐量： 92 Kbps
总活动会话 ： 14
活跃 TCP 会话 ： 8
活动 UDP 会话 ： 4
活动 ICMP 会话 ： 2

通过按"a"来切换以查看"前 20 个应用程序"，然后通过按"s"来查看"前 20 个应用程序"

前 20 名应用程序统计：（ "q" 退出， "h" 寻求帮助）

虚拟系统：vsys1
应用程序会话字节

-------------------------------- ---------- ------------ ------------ssl 349 47051 53368023
火狐更新4 32503 31679603
谷歌基地57 19879 17687367
ms-update 30 2513 2413399
tor 1 715 710161
网页浏览 60 1140 588357
ping2920 5840 572320
窗口推送通知 57 819 266 737
apt-get 6 662 260149
dns 728 1484 185056
dhcp 124 248 86800
ms-spynet 3 71 45382
ocsp 9 215 33311
谷歌 更新 2 28 8624
ntp 45 90 8100
ipv6 2 64 5248
啜饮 5 5 2283
ldap 8 9 2241
数据不足 5 13 780
icmp 6 6 520

同样重要的是要注意，流量类型和配置的复杂性也可以增加 CPU 利用率。 因此，查看交通模式，了解导致高利用率的潜在应用非常重要 CPU 。

管理平面

通过在 mp 监视器中搜索"---顶部"来检查管理平面资源的使用情况.log或者通过运行显示系统资源命令来检查 CLI 。 以下是此命令的示例输出：

>秀系统资源

顶部 - 03：40：57 上升 20 分钟， 0 用户， 负载平均： 0.00， 0.01， 0.03

任务： 116 共， 1 运行， 115 睡眠， 0 停止， 0 僵尸

Cpu： 1.6% us， 1.3% sy， 0.0% ni， 96.2% id， 0.5% wa， 0.0% 喜， 0.4% si， 0.0% st

Mem： 共 3635080k， 2327864k 使用， 1307216k 免费， 37772k 缓冲区

交换： 2007992k 总计， 0k 使用， 2007992k 免费， 1871932k 缓存

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+ COMMAND

1837 根 15 -5 18036 3508 2032 S 8 0.1 0：35.23 sysd

1 根 20 0 1768 560 488 S 0 0.0 0：00.75 init

2 根 20 0 0 0 S 0 0.0 0：00.00 k 阅读

3 根 RT 0 0 0 S 0 0.0 0：00.00 迁移/0

以下是管理平面上资源使用可能导致问题的迹象。

• %wa CPU 在线是高的，这表明管理平面正在等待在io（在交换和磁盘绑定）。
• 交换线上的免费内存很高。
• CPU 对于开发人员，mgmtsvr和应用程序的过程是高的。

流量模式分析

如果流量模式是性能问题的可疑原因，请向客户请求外部数据包捕获网络流量。 不建议自行执行捕获 firewall ，因为它可能不会显示所有流量，尤其是在交通已卸载的情况下。