精通polling参数调优的进来帮帮忙吧

antijp

I've checked the two sizes, sizeof(pkthdr) == sizeof(m_hdr) == 24, and sizeof(m_ext) also equals to 24.
MINCLSIZE is 209. This design removes a indirect pointer and would make performance better.

colddawn

个人感觉这个测试结果大包性能提升不太像mbuf大小问题。

mirnshi

帖子好长呀，看了半天。

如果是桥模式，从网卡中断开始，一直到这个包不在2层，都是在一个中断里，所以桥转发的效率很关键，专做桥设备就需要增加队列之类的，提高包响应速度了，否则仅仅要响应中断，系统就受不了了。
polling模式在某些情况下是可以提高效率的，polling模式主要原理就是网卡将数据包放到队列中，cpu通过轮训的方式获取数据包，属于主动方式，而中断相当于被动接收。如果cpu在轮训间隔内可以有效地处理队列中的包，就可以提高效率，否则就会降低效率。
查看系统效率，尤其是网卡的，不仅仅要看vmstat，netstat可是必须要看的，可以看到包流量，错误数等等。在有足够cpu处理的情况下，如果流量上不去，那就要看看网卡了，看看错误数是不是很高。这些数据都是互相影响的，但也不能作为唯一判定值。所以一定要通过判断vmstat，netstat的监测数据，在去调整相应参数。

将mbuf的尺寸增大，并不会带来特别显著的提高，系统会根据包的大小，自动分拆的，大家可以看看协议栈的实现。

caibird3rd

注意别把注意力全放在操作系统上，测试机本身（所用总线规格等）、网络连接、smartbit的设置 等等
都应该检查一遍

xie_minix

其实楼主的要求很简单,他想把FB下千兆卡的效率提高到能和LINUX差不多就行了.
我们是来给他想办法,同时也提高我们自己.去寻找具体原因.你可以怀疑某个地
方出问题,即使是比较幼稚的想法.但必须去实现.用代码或调试各种参数去测试.
另外说句: 楼上的caibird3rd明显没进入状态.哈哈
已经有很多人都在反映该问题.我知道的许多非常专业的放火墙开发人员(DDOS方向)
也遇到此问题.到目前还没有解决.以至于他们转向了LINUX.
对于现在的FB,锁的粗细粒度使用的还是有问题.比如大家看看POLLING的5.3.使用
GAINT太多,还有些代码重复,不多评论了.继续检查

www_ftp

在Free BSD 6.0以后,polling的确不起什么作用,就是调的参数再好,最多只能达到不开polling的程度.在linux下也测试过打不打开polling性能也没有什么变化.听过4.11打开与不打开polling差别很大.

xfsoul

我现在已经不指望通过调节FreeBSD参数来提高性能了。
我暂停这个测试，下周继续在另外一个平台上测试性能。
我已经配置好了FreeBSD 4.11和FreeBSD6.1双系统。对于该平台，linux的性能已经测试过了，由于该平台性能比较强，linux表现还过得去。
硬件平台：
CPU：双路Opteron 2.4G
内存：1G DDR400 双通道开启，ECC关闭
网卡：Intel双光纤口网卡、Intel双口网卡。这四个网卡都是连接在北桥上，PCI-X 64bit， 133MHz。

大约下周二开始测试。大家有空不妨帮我想想办法呵，我先谢过了。

caibird3rd

原帖由 xie_minix 于 2006-5-25 16:07 发表
其实楼主的要求很简单,他想把FB下千兆卡的效率提高到能和LINUX差不多就行了.
我们是来给他想办法,同时也提高我们自己.去寻找具体原因.你可以怀疑某个地
方出问题,即使是比较幼稚的想法.但必须去实现.用代码或调试各种参数去测试.
另外说句: 楼上的caibird3rd明显没进入状态.哈哈
已经有很多人都在反映该问题.我知道的许多非常专业的放火墙开发人员(DDOS方向)
也遇到此问题.到目前还没有解决.以至于他们转向了LINUX.
对于现在的FB,锁的粗细粒度使用的还是有问题.比如大家看看POLLING的5.3.使用
GAINT太多,还有些代码重复,不多评论了.继续检查 ...

哈哈，对FB我倒是不熟，只是略有耳闻FB的性能如何稳定和有效率，真的比Linux差很多吗？
说老实话，对于比较成熟的一个发行版来说，其运行时的各种缺省参数一般都是仔细调优了的，充分
权衡了各个子系统的影响、考虑到了各类常见应用环境。

怀疑仅仅通过调整参数，能够获得多大的性能提升。
我的经验，这种情况，要么是系统代码内在结构决定，要么就是硬件平台甚至测试环境的影响。
不是我瞧不起各位老大的能力，前者的分析很难啊。
在这里给各位加油，希望有一天FB里面也有大量国人的补丁，呵呵

mirnshi

原帖由 caibird3rd 于 2006-5-25 17:29 发表


哈哈，对FB我倒是不熟，只是略有耳闻FB的性能如何稳定和有效率，真的比Linux差很多吗？
说老实话，对于比较成熟的一个发行版来说，其运行时的各种缺省参数一般都是仔细调优了的，充分
权衡了各个子系统的影 ...

无论OS，还是DB，它的发行版都是为了适合绝大多数情况的，要想在某种应用和场合发挥最大的性能，各项参数是必须调整的。所以不要这么讲，否则各类系统的管理员就要失业了。

xie_minix

mirnshi:
我猜想,开发POLLING的团队有问题.他们对MUTEX的了解不够,最起码在5.3版本时.
这是最要命的事情.
其次,写代码时没经过思考(请原谅我这么说,他们也不容易),比如你看:
5.3版本
poll_idle(void)中
mtx_lock(&Giant); <---------
ether_poll(poll_each_burst);
mtx_unlock(&Giant);
在看ether_poll()
ether_poll(int count)
{
int i;
mtx_lock(&Giant);    <---------
他是不是怕没锁住啊,哈哈