12.7故障问题

起笔前还是需要督促自己养成bolg记录的习惯，1年过去了，大部分经历过的研发过程问题、管理问题都没有积累总结。

1.

12.5号设备发现信令处理不过来，最后分析结果是1个线程处理socket的收包过程，并根据一定的负载算法（偶联号）分配到5个缓冲队列，5个线程各读一个缓冲队列进行处理，处理结果分两类，一类是普通信令，一类是寻呼paging信令，这两类结果各自对应一个发送队列，每个队列都有一个线程进行读取和使用相同的socket进行报文发送。

                          |---buffer1---thread1                                   ----thread1---buffer1---|

                          |---buffer2---thread2    --------------------    ----thread1---buffer1---|

  CN -----R---->|---buffer3---thread3     |       process     |    ----thread1---buffer1---|<--R----eNB

            ^            |---buffer4---thread4    --------------------    ----thread1---buffer1---|         ^

            |             |---buffer5---thread5        /         \                ----thread1---buffer1---|         |

            |                                                   /             \                                                             |

            |                                             Buffer1      Buffer2                                                   |

            |                                              /                   \                                                           |

            |                                          Thread1          Thread2                                               |

            |----------W------------------/                          \----------------W------------------------|

模型如上图所示，由于模块测试时候使用的是1个线程读R一个线程写W，性能吞吐达到30几万次队列读写每秒，但是有5个线程写，一个线程读的时候由于竞争的关系，性能下降了10倍左右。还好有单元测试帮忙可以方便的验证模型的性能吞吐。最后修改的是发送时候paging的队列也是5个，保证每个线程都只读、写一个队列，最后测试的效果很好，1千eNB的paging消息处理没有拥塞过载。

2.

se负荷分担是，由于数据有分片包，处理流程需要走主通道，进行rab汇聚转换后，在gtpu里面设置的负荷分担因子是核心侧的teid；但是普通报文进入快速通道后默认的负荷分担因子是报文的srcip，当快速通道查找fib表失败时，汇聚已经经过了转换，重新进入主通道的ip层，此时目的src、dstip都有改变，走的是路由forward这条链，直接使用了src ip的负荷分担因子，最终导致走了路径不一致。问题的发现也是根据现网抓包写单元测试测出来的。同时也发现了进入主通道汇聚处理gtpu后是不可能添加fib成功的，因为gtpu的发送函数里面设置了SecSA的指针为NULL，也说明快速通道处理gtpu汇聚不完善，没有达到快速的目的。

if(msg->SecSa) //经过gtpu发送后重新构造了一个msg，msg->SecSa被清空了
{
SecSA* sa = (SecSA*)msg->SecSa;
if(sa->dir == SA_DIR_OUT)
{//for out put, record the L2 info
sa->phyport = msg->Port;
sa->vlan = msg->VlanID;
sa->peermac = eth.DstMac;
}
else if(msg->Port >= FABRIC_PORT && msg->Port < MAX_PORT_NUM)
{//for inbound, record the L2 info, Dolphin 2014/09/15
   IP_FIB_Add(info, msg, ð);
}
}

所有的这些都是基于单元测试分析性能和跟踪调试发现的问题：

1. 单元测试需要和实际应用的接口一致，比如加解密的函数功能要一致，不能简单的写一个自己的变换认为就OK了，这在这次问题排查中使用现网抓包的输入是有很大帮助的

2. 单元测试加入最新的用例后包装后续的改动不会出现类似的问题，同时要求新开发代码必须要考虑到整体流程处理的测试上，不能偷懒不写单元测试。