tcpcopy线上部署以及github提交的一个issue

给自己留存一个美好的回忆
github提交的issue

● 发现tcpcopy在开启单个进程多倍流量转发时会出现cpu单核心使用率过高导致rst包的现象，后来通过抓包排查等多钟方法以外发现是单进程tcpcopy的cpu无法响应造成的，后来启动6个tcpcopy进程同时一倍流量没有啥问题。

● Online Server(OS)：上面要部署 TCPCopy，从数据链路层(pcap 接口)抓请求数据包，发包是从IP层发出去；
● Test Server(TS)：最新的架构调整把 intercept 的工作从 TS 中 offload 出来。TS 设置路由信息，把 被测应用 的需要被捕获的响应数据包信息路由到 AS；
● Assistant Server(AS)：这是一台独立的辅助服务器，原则上一定要用同网段的一台闲置服务器来充当辅助服务器。AS 在数据链路层截获到响应包，从中抽取出有用的信息，再返回给相应的 OS 上的 tcpcopy 进程。

请配合下图1理解：

10.116.95.87 target server10.116.95.81 intercept/usr/local/intercept/sbin/intercept -i eth1 -F 'tcp and src port 9999'  -l /data/intercept.log -d10.116.95.82线上/usr/local/tcpcopy/sbin/tcpcopy -x 80-10.116.95.87:9999 -s 10.116.95.81  -m 20480 -c 192.168.2.x -n 1  -l  /data/tcpcopy.log -d

线上服务器10.116.95.82## 部署cd /usr/local/src && rsync -avzP bigdata.vxlan.net::wVioz35SWO9zywesmagfOrP9XjigoF8j/tcpcopy/* .cd /usr/local/src/tcpcopy && ./configure --prefix=/usr/local/tcpcopy/   && make -j 10 && make installtarget server10.116.95.81yum install -y libpcap-develmkdir /usr/local/src/interceptcd /usr/local/src/intercept && rsync -avzP bigdata.vxlan.net::wVioz35SWO9zywesmagfOrP9XjigoF8j/tcpcopy/intercept/* .cd /usr/local/src/intercept && ./configure --prefix=/usr/local/intercept/ && make -j 10 && make install使用第一步10.116.95.87route add -net 192.168.2.0/24 gw 10.116.95.81#route del -net 192.168.2.0/24 gw 10.116.95.8210.116.95.81/usr/local/intercept/sbin/intercept -i eth1 -F 'tcp and src port 9999'  -l /data/intercept.log -d第二步10.116.95.82/usr/local/tcpcopy/sbin/tcpcopy -x 80-10.116.95.87:9999 -s 10.116.95.81  -m 20480 -c 192.168.2.x -n 1  -l  /data/tcpcopy.log -d/usr/local/tcpcopy/sbin/tcpcopy -x 80-10.116.95.87:9999 -s 10.116.95.81  -m 20480 -c 192.168.2.x -n 1  -l  /data/tcpcopy.log -d

内核调一调

内核参数调整一下kernel.sysrq = 1kernel.core_uses_pid = 1kernel.msgmnb = 65536kernel.msgmax = 65536kernel.shmmax = 68719476736kernel.shmall = 4294967296net.ipv4.ip_forward = 0net.ipv4.conf.default.accept_source_route = 0net.ipv4.tcp_syncookies = 1#############################net.ipv4.conf.default.rp_filter = 0net.ipv4.conf.all.rp_filter = 0net.ipv4.conf.all.arp_announce = 2##net.nf_conntrack_max= 2031616##net.netfilter.nf_conntrack_checksum = 0##net.netfilter.nf_conntrack_tcp_timeout_established= 38############ bigdata define ###########net.core.somaxconn = 20480net.ipv4.ip_local_reserved_ports = 8000-9000,28000-29000net.ipv6.conf.all.disable_ipv6 = 1net.core.netdev_max_backlog = 20480net.ipv4.tcp_max_tw_buckets = 800000net.ipv4.tcp_max_syn_backlog = 20480net.ipv4.tcp_keepalive_time=30net.ipv4.tcp_keepalive_intvl=1net.ipv4.tcp_keepalive_probes=3##net.netfilter.nf_conntrack_max = 4096000

如果采用的是IP Queue模块来截获响应包，则intercept程序密切跟ip queue内核模块相关，所以当压力很大的时候请求丢失率很高，需要优化sysctl系统参数才能达到好的效果（通过cat /proc/net/ip_queue，查看ip queue运行情况，如果Queue dropped的数值不断增大，则需要修改ip_queue_maxlen参数，比如echo 4096 > /proc/sys/net/ipv4/ip_queue_maxlen；如果Netlink dropped的数值不断增大，修改net.core.rmem_max和net.core.wmem_max参数,比如sysctl -w net.core.rmem_max=16777216和sysctl -w net.core.wmem_max=16777216）从给的少量log来看，存在着ip_queue内核模块丢响应包的可能性。先从ip queue入手，调大后，看是否还有此问题pf_ring安装yum -y install subversion flex bison ethtool