coolsnowwolf
WAN的转发是否有performance issue?
我都x86软路由，千兆电信带宽，刚启动的时候 用Iperf3跟外网的千兆主机，跑945Mbps没问题发现运行一段时间之后，就会降速到500M甚至最低50M了，用speedtest测试也是一样，原来以为是什么ssr/mwan3之类的干扰或相关，后来service stop关了这些东西之后发现根本没用，必须重启，重启之后立马恢复1000M的速度，观察过端口里面自协商1000Mbps是从来没有问题的。在sysctl里吧能调优的ipv4相关参数也都调大了（因为之前内核会报nf conntrack太小和tcp orphan 太多之类的错误）不管用。这个问题因为没有什么头绪，也不知道怎么搜索....只是看官方好像提过R21版本是有performance issue.但的确是困扰我好久了,因为不知道触发条件，只是观察测速得到的现象。哪位有经验能否提点下方向
发现issue出现的时候，测速只能到300-500M, 是因为CPU 100%了 两个软中断softirq几乎把CPU跑满，查中断最高的是网卡RX的，找到一个类似的issue #6126 ，但他那个问题说是Fullcone-NAT的问题，我这里即便关了F-NAT，问题依然依旧啊，好像跑到一个什么状态里了，就只要网卡大流量就会sirq超高，cpu100%,速度急剧下去了，但看上去两个CPU的网卡中断负载又是均匀的，不存在网上说的那些CPU affanity的问题。但之前没出问题的时候一如既往的好，能跑到950M，CPU高一点，80%左右，也不会到100%导致处理不过来，这个问题好像比较容易发生在手工切换ssr节点的场景下。有谁知道如何恢复么，除了重启。请大佬@coolsnowwolf也帮忙看看啊，多谢
图1： sirq 90%， ksoftirqd0/ksoftirqd1 几乎各50%导致满载
图2： 网卡RX sirq 异常的多
图3：网卡sirq 在CPU0/CPU1之间是相对均衡的。
是不是有大量小包场景中断这么？使用高的时候看看连接数
下面这些参数看看 这些是我的，大量小包场景，仅供参考，根据自己使用场景调节： echo 4000000 > /proc/sys/net/netfilter/nf_conntrack_max echo 1000000 > /proc/sys/net/netfilter/nf_conntrack_buckets echo 5 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout echo 512000 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 echo 2048000 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 echo 4096000 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
是不是有大量小包场景中断这么？使用高的时候看看连接数
下面这些参数看看 这些是我的，大量小包场景，仅供参考，根据自己使用场景调节： echo 4000000 > /proc/sys/net/netfilter/nf_conntrack_max echo 1000000 > /proc/sys/net/netfilter/nf_conntrack_buckets echo 5 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout echo 512000 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 echo 2048000 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 echo 4096000 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
我试试，另外，我发现测速正常到960M左右时候，虽然sirq 也较高-50%+， 但ksoftirqd0/1 两个负载都很低，才3%-4%，但异常降速的时候，这两个就变成上面图里的40%+了，不知为何。
是不是有大量小包场景中断这么？使用高的时候看看连接数 下面这些参数看看 这些是我的，大量小包场景，仅供参考，根据自己使用场景调节： echo 4000000 > /proc/sys/net/netfilter/nf_conntrack_max echo 1000000 > /proc/sys/net/netfilter/nf_conntrack_buckets echo 5 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout echo 512000 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 echo 2048000 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 echo 4096000 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
我试试，另外，我发现测速正常到960M左右时候，虽然sirq 也较高-50%+， 但ksoftirqd0/1 两个负载都很低，才3%-4%，但异常降速的时候，这两个就变成上面图里的40%+了，不知为何。
没用
是不是有大量小包场景中断这么？使用高的时候看看连接数 下面这些参数看看 这些是我的，大量小包场景，仅供参考，根据自己使用场景调节： echo 4000000 > /proc/sys/net/netfilter/nf_conntrack_max echo 1000000 > /proc/sys/net/netfilter/nf_conntrack_buckets echo 5 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout echo 512000 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 echo 2048000 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 echo 4096000 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
我试试，另外，我发现测速正常到960M左右时候，虽然sirq 也较高-50%+， 但ksoftirqd0/1 两个负载都很低，才3%-4%，但异常降速的时候，这两个就变成上面图里的40%+了，不知为何。
没用
用sar -I irq# 1 观察了一下，正常无issue能测到940M+的时候，所有eth网口的软中断请求数量和出现issue（2core CPU 100%, ksoftirqd0/1都40%+，转发性能大大下降）时的数值在量级上并无明显差异，但是就是出问题的时侯表现为ksoftirqd0/1奇高，没问题就正常开销（<10%), 不知道是什么鬼，经验一般都是在改变SSR配置的时候会出来。比如切换节点。
这个问题在我新买的N5105的软路由上也重现了，表现为软中断异常升高吃满CPU, 网络转发速度急剧下降，目前没找到具体的触发条件，好像每次在做ssr的节点切换之后会出来，不知道是否有因果关系。建议大佬们研究一下。
同样问题我这里也有，大概每12小时左右就会发作一次，LZ的防火墙有自定义规则吗？配置是通过升级保存的吗？ 我目前重新恢复了一次出厂，手动重新设置了一次。 把防火墙自定义两条限制上传的iptable注释掉 然后把Fullcone NAT禁用 全局的DNS解析只留了一个 目前已经试用了近两天看起来是正常的。
