Ineedle驱动方式dpdk测试性能
这次主要是测试在dpdk方案下,ineedle的处理包的性能。
发包工具:使用立永当时写的一个发包工具:linux_pcap
做法:
大概是从网上抓取了一些数据包,将源ip替换为随即ip,sip替换为要监控的ip地址。然后用pcap工具进行发包
设备:
这次发包工具运行在测试机上,也就是这次跑ineedle的DELLR430设备,用em2端口发包,用p1p4接口来接收包。
注意:
要打开网卡的混杂模式。
说明:
这个设备性能比较好,发包正常的包最大速度能够达到:75M/s。单包发送(排除IO干扰)情况下速度:96M/S,转化为bps大概有800MBPS。 如果在普通设备上的速度是比较小的,具体数值忘记了。
其它因素:
发包工具发的报文是从网络上抓的一些包作为样本,然后对源ip和和目的ip进行替换,源ip随机替换,目的ip替换为服务器配置要监控的域名和ip,进行发包;
包中可能会有错误,貌似会有点影响正常测试的准确性。
有时间可以再优化一下发包的工具,看看能不能提高一下测试速度,主要是想排除一下IO等待的干扰。
暂时分为2个步骤:
1、单独测试dpdk的抓包能力
最大速度 96M/S 的时候打到DPDK网口上时候,由于dpdk只与ineedle做了简单的包传递,ineedle并没有实际处理包,因此ineedle对其影响不大,可以准确测试dpdk底层的性能。
由于发包工具最大发包的速度也就是这个速度,因此现在只能测试到这个速度了。在这个速度下dpdk比较稳定,在ineedle和dpdk的相互通信情况下完全没有丢包现象;其实也差不多快达到千兆网口的极限了。
2、ineedle和dpdk正常交互时用正常数据包测试
这次是让ineedle正常处理数据包,走完全的流程;其实说是完全的流程也不太准确,因为发包工具发的包好多可能是错误的、不正常的或者说不能完全走ineedle全程的数据包,好多从中间部分就被处理掉了。当然这些包可能会影响到我们测试的速度,但是也没办法,现在只有这一个工具。大概测试过程:
每组数据测试5min,发包速度是从低到高:
13M/S————————不丢 20M/S————————不丢 30M/S————————不丢 38M/S————————不丢 48M/S————————不丢 53M/S————————不丢 58M/S————————不丢 63M/S————————不丢 66M/S————————不丢 72M/S————————不丢 80M-82M/S——————丢包
测试结果,暂时为这个样子。
————————————————————— 我是分割线 ———————————————————————————————
下边要总结出ineedle和dpdk系统中处理包、丢包情况;主要也分为2部分进行统计:
一、驱动层dpdk
包总数:从dpdk网卡进去的包的总数量。
下边的情况我们会将这些报文进行丢弃:
【1】DPDK程序启动后,在ineedle程序启动开始处理数据包之前的这些包将会被丢掉,调试信息中会给予显示。
【2】初次根据mac过滤的报文,包括:广播报文、组播报文、本地报文等将会被丢掉。
【3】根据协议类型将一些arp报文、vlan报文、非支持链路类型报文等将会被丢掉。
【4】根据配置服务器ip来进行过滤,那些不在web中配置的要监控的sip列表之中的报文也将会直接过滤掉。
【5】如果进入网卡数据报文速度太快,ineedle来不及处理过来,在DPDK程序中将会队列溢出情况,溢出部分报文将 会被丢掉。
二、Ineedle系统
包总数:经过DPDK程序过滤丢球相应报文后copy进入iNeedle系统的报文总数。
下边的情况我们也会将这些报文进行丢弃:
【1】ineedle系统可以设置报文的最大速率,如果超过这个速率,这些报文就将会被丢弃。当然这个一般情况下没有做设置,暂时不考虑这种情况。
【2】packet_main中初次判断,若接收的报文长度比抓取的还长,这是种错误的情况。这些报文会被丢弃,这种情况平时应该会很少吧。
【3】对IP层分片的报文,因为后面的分片不带TCP、UDP信息,暂时不处理。
【4】ineedle系统中再次对目的ip进行过滤,非目的sip的报文将会被丢弃。
【5】根据传输过来的报文方向进行判断,非SESS_DIRECT_S2C、SESS_DIRECT_C2S、SESS_DIRECT_INIT的报文视为错误的报文,将会被丢掉。
【6】对于获取到5元组后,进行简单计算如果报文长度-ip头-tcp头/udp头长度,结果小于0的报文将会被丢弃。
【7】对于长度不为0的报文,但是携带了SYN、RST、FIN标记的,是不正常的报文视为错误报文,将会被丢弃。
【8】对于创建sess_tbl表失败的或者是syn重复,类似syn flood攻击的报文视为错误报文,将会被丢弃。
【9】对于非TCP或非HTTP报文当然状态置为packet_fsm_type_over,视为不处理报文,将会被丢弃。
【10】对于HTTP报文长度小于0的报文视为错误报文,将会被丢弃。
【11】对于TCP分片报文经过组合一次后,仍然是分片报文或者分片太大超过程序设置缓存,视为错误,将会被丢弃。
【12】对于C2S方向的HTTP报文,判断出不是GET、POST等方法,设置状态机为over,视为不处理报文,将会被丢弃。
【13】对于HTTP层面报文进行分析,非REQUEST或RESPONSE报文的,状态设置为packet_fsm_type_over,视为不处理报文,将会被丢弃。
【14】对上述情况进行统计,并可以通过调试信息打印出来这些报文处理情况。
三、日志功能
测试功能可以正常使用。但是存在问题,web端配置ip等信息时,只能添加一个ip区间段,再次添加就没有反应,只能从数据库手动添加;日志下载功能似乎也是有bug的,选择条件后点击下载后一直在web端显示正在生成文件,就是生成不了,可能是web的一些bug。
四、磁盘存储说明
总共3块磁盘:300GB、600GB、600GB
300GB:系统盘 + /var/dz_resource + ineedle基本环境
600GB:数据库mysql
600GB:日志
五、简单总结
【测试问题】
1、发包工具:
发包工具不是自己亲自写的,不太熟悉;发包工具发的包很多有错误的包,影响了测试的准确性;测试速度提不上来,必须到性能比较好的设备上才能勉强可以达到测试的条件;其实也可能存在发包的效率问题,抽时间修改一下。
2、调试信息:
dpdk当时仅仅是完成底层数据包的抓取,然后向上ineedle提供包的拷贝功能。并没有实现一些调试信息的接口,导致后续测试时调试信息不完整;后续又临时采用了文件记录的方法,暂时先用着吧。ineedle调试信息这块,虽然可以通过./shell程序来查看ineedle实时包统计情况,但感觉总计的信息不完整;ineedle调试信息统计包的函数中记得有个bug,后来临时修改了一下,原因是当时添加dpdk时忘记修改关于调试show_packet_cmd函数的一些关于底层信息,每次只要在shell中执行show packet_num就会导致程序崩溃。暂时解决办法是将其相关底层驱动相关信息统计代码给注释掉了,只统计报文情况。
3、日志功能:
日志功能模块,对这一块代码读得太少了,测试的时候有点手忙脚乱的。日志功能需要在日志web界面进行相关配置,配置完成之后,才能实现日志的记录功能,最后在配置日志功能后重启一下ineedle;记得ineedle当时设置的是对每个主机的日志记录最大上限是1GB;日志存储目录:/var/dz_resouce/ineedle/release/data/ilog/logs,似乎会定时将此日志文件拷贝的wapp程序共享目录/var/dz_resource/shared;
4、日志程序:
之前可能好久都没有使用过日志功能,这次看代码和测试中发现read和write通信的逻辑有点问题;write端独立不管read是否读取,一直晕着头往共享内存队列中写数据,read端也是不加控制的一直循环从队列中读取数据;一直默认情况是write端的速度比较快,read端可能要写IO速度会稍慢,但即使这样也会存在很多中问题比如数据覆盖等;这次稍微修改了下read端的代码,在write端数据实在是速度非常快的情况下,丢包也是在所难免的,若是read端比较快的情况下要控制read端读取包的进度,不能盲目一直往下读取,因为可能会读取到错误的或者重复的数据包(上次循环write的包),这样就是不对的,导致错误比较严重。程序中添加了几个字段来控制read端的读取行为。现阶段只能这样处理,因为write端暂时不能够等待read,在write端持续高速写入的情况下是无法实现等待的。结果在后续测试中能够保持write和read上的同步。
【代码修改】
1、调试代码修改
这些是在测试过程中进行调试时添加的一些printf语句,打印一些变量执行的情况,这个在测试完毕都已经进行删除
2、dpdk端
添加了包统计的调试信息,在dpdk代码中添加的,没有使用多线程,添加了time等的系统调用来计时,即使是1s中进行一次io写操作,但是系统调用是每次都进行的,可能会导致dpdk的效率问题。但是在调试过程中又是必须的,就暂且保留在代码中,可以在后续稳定的实际生产环境中要将调试信息给关闭掉。
3、ineedle端
同样是针对ineedle报文统计的调试信息做了一些简单修改。具体在show_packet_num函数中作了简单修改。