论坛徽章:: 0

1楼 [报告]

发表于 2006-05-25 15:13 |显示全部楼层

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

caibird3rd

丰衣足食

论坛徽章:: 0

2楼 [报告]

发表于 2006-05-25 17:29 |显示全部楼层

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

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

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

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

caibird3rd

丰衣足食

论坛徽章:: 0

3楼 [报告]

发表于 2006-05-25 19:05 |显示全部楼层

原帖由 xie_minix 于 2006-5-25 18:11 发表
mirnshi:
我猜想,开发POLLING的团队有问题.他们对MUTEX的了解不够,最起码在5.3版本时.
这是最要命的事情.
其次,写代码时没经过思考(请原谅我这么说,他们也不容易),比如你看:
5.3版本
poll_idle(void)中
mtx ...

不晓得是不是跟linux的大内核锁一样，可以重复进入的？
ether_poll（）说不定在别的地方还有调用到，所以要加锁
大内核锁在linux里已经很少用到了。看来linux更注重性能的说法有一定道理

另外，不晓得FB有没有针对Opteron的优化？楼主用的Opteron应该很牛啦

[ 本帖最后由 caibird3rd 于 2006-5-25 19:08 编辑 ]