M9000流量不大CPU利用率低的情况下出现丢包现象

某客户购买我司两台M9006，割接后出现oracle数据库每天早上10：00左右和下午15：00左右断开一次连接的情况，断开后因为软件机制又重新连接。了解到客户的数据库业务十分依赖长连接，初步判断为中间出现丢包现象，导致连接断裂。

查看当时的流量和CPU利用率均不高，配置没有任何问题，现象比较奇怪

M9000设备没有出现告警，客户的服务器出现连接断开的告警，并自行重新建立连接后恢复

查看诊断信息发现：

 353     4          0K      100      D     6:53:12:470    [kdrvdp4]      
    354     5          0K      100      D     6:40:23:340    [kdrvdp5]      
    355     6          0K      100      D     7:4:3:680     [kdrvdp6]      
    356     7          0K      100      D     7:14:4:200     [kdrvdp7]      
    357     8          0K      100      D     6:48:56:850    [kdrvdp8]      
    358     9          0K      100      D     6:53:31:540    [kdrvdp9]      
    359     10         0K      100      D     6:49:31:930    [kdrvdp10]     
    360     11         0K      100      D     7:36:2:560     [kdrvdp11]     
    361     12         0K      100      D     6:50:12:850    [kdrvdp12]     
    362     13         0K      100      D     7:35:0:400     [kdrvdp13]     
    363     14         0K      100      D     7:22:32:420    [kdrvdp14]     
    364     15         0K      100      D     7:36:36:160    [kdrvdp15]     
    365     16         0K      100      D     7:4:32:720     [kdrvdp16]     
    366     17         0K      100      D     13:37:34:980   [kdrvdp17]     
    367     18         0K      100      D     7:4:17:860     [kdrvdp18]     
    368     19         0K      100      D     7:55:34:940    [kdrvdp19]     
    369     20         0K      100      D     7:15:51:800    [kdrvdp20]     
    370     21         0K      100      D     6:51:49:700    [kdrvdp21]     
    371     22         0K      100      D     7:21:57:510    [kdrvdp22]     
    372     23         0K      100      D     6:58:42:500    [kdrvdp23]     
    373     24         0K      100      D     7:58:38:660    [kdrvdp24]     
    374     25         0K      100      D     6:55:10:290    [kdrvdp25]     
    375     26         0K      100      D     6:48:45:960    [kdrvdp26]     
    376     27         0K      100      D     6:49:21:620    [kdrvdp27]     
    377     28         0K      100      D     7:2:34:960     [kdrvdp28]     
    378     29         0K      100      D     6:58:9:190     [kdrvdp29]     
    379     30         0K      100      D     6:50:29:600    [kdrvdp30]     
    380     31         0K      100      D     7:19:48:60     [kdrvdp31]  

vCPU17的CPU占用时间是其他vCPU的两倍左右，初步判断发生了单个转发核跑满的情况，收集高峰期时的诊断发现vCPU17的CPU利用率已经到了3.7%

 366    366  3.7  0.0   R  100      -  09:09:06      [kdrvdp17]  

数值看起来不大，但是32个vCPU平分100%的CPU，平均下来每个vCPU能得到3.125%的CPU利用率，高峰期时vCPU17已经严重超荷运行，抢占了其他的资源。经过实验室模拟测试，在vCPU超过3.3%的情况下，丢包开始显现。

原因分析：M9000等V7防火墙默认的流分类为逐流模式，报文会按照5元组HASH到各个vCPU上处理，这样的HASH算法不能保证流量绝对平均，如果客户业务集中在几个流上，或者报文经过HASH后正好集中于一个转发核。转发核在繁忙的情况下，会随机丢弃报文。如果客户业务对丢包时序特别敏感，就会影响到业务

修改M9000流分类策略为逐包模式

进入系统视图
 system-view
  配置流分类策略
 forwarding policy { per-flow | per-packet }
 缺省情况下，采用基于流处理的流分类策略
 

请注意，这样报文可能会引来乱序，现场业务需要做好评估

在网管上查看CPU利用率低，并不能反馈设备的真实情况。只能反映设备整体的数值，在遇到故障时，还需要从诊断中分析，3.7%也是很小的数值，但是明白其中的计算方法就可以知道问题的根因