免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: xfsoul

[FreeBSD] 精通polling参数调优的进来帮帮忙吧 [复制链接]

论坛徽章:
0
发表于 2006-05-25 09:59 |显示全部楼层
另外注意到你测试的数据FB的CPU占用率方面比较奇怪,尤其是小包的第一个50%,是不是开启了HTT?关闭掉试试看。
还有这个参数kern.polling.user_frac: Desired user fraction of cpu time
把user占用的cpu时间片尽量压缩,这样内核CPU利用率会比较高,毕竟linux下都高过90%了,FB这么少说明是有问题的。

论坛徽章:
0
发表于 2006-05-25 10:00 |显示全部楼层
原帖由 colddawn 于 2006-5-25 09:54 发表
kern.polling.burst_max: 300
kern.polling.burst: 300
这两个值一样,似乎burst不够用了,继续调大些试试看??



HZ=4000
burst=300
理论可以发120万pps呢。

ps:我调成500性能也无变化

论坛徽章:
0
发表于 2006-05-25 10:02 |显示全部楼层
原帖由 colddawn 于 2006-5-25 09:59 发表
另外注意到你测试的数据FB的CPU占用率方面比较奇怪,尤其是小包的第一个50%,是不是开启了HTT?关闭掉试试看。
还有这个参数kern.polling.user_frac: Desired user fraction of cpu time
把user占用的cpu时间片 ...

那个参数调整到更小也没有意义,我从5开始每10一个档都调节过了。

CPU利用率很低 我也很奇怪,为什么这么多资源FB不去使用。
但是如果不开polling,CPU占用就上去了,也是90%多。

论坛徽章:
0
发表于 2006-05-25 10:03 |显示全部楼层
kern.polling.burst: Current polling burst size
fw2# sysctl -d kern.polling.burst_max
kern.polling.burst_max: Max Polling burst size

应该是要调整max,lz是说错了还是调错了?

论坛徽章:
0
发表于 2006-05-25 10:05 |显示全部楼层
原帖由 colddawn 于 2006-5-25 10:03 发表
kern.polling.burst: Current polling burst size
fw2# sysctl -d kern.polling.burst_max
kern.polling.burst_max: Max Polling burst size

应该是要调整max,lz是说错了还是调错了?

我就是调整的max
sysctl kern.polling.burst_max=150
sysctl kern.polling.burst_max=200
sysctl kern.polling.burst_max=300
sysctl kern.polling.burst_max=400
sysctl kern.polling.burst_max=500
sysctl kern.polling.burst_max=1000
都试过了。

我测试的数据是我微调内核参数得到的最好数据。

论坛徽章:
0
发表于 2006-05-25 10:24 |显示全部楼层
我还是希望能看到大概每秒执行软中断的次数(POLLING),这样可以确定调度器及系统的基本情况.
我在我家里的机器上(SMP PII 450  256M  if_vr * 1)
3. 一些测试值:
   kern.polling.dbg.poll_coun: 5404323  软中断实现的总次数,默认设置每秒大概在30000左右次调用
kern.polling.dbg.pollmore_coun: 4952549
kern.polling.dbg.poll_suspect: 0
kern.polling.dbg.poll_invoke: 24 从硬件时钟中断到netisr_poll的毫秒
kern.polling.dbg.net_load: 30 从NETISR_POLL到NETISR_POLLMORE的毫秒
kern.polling.burst: 150
kern.polling.burst_max: 150
kern.polling.each_burst: 20
kern.polling.idle_poll: 0
kern.polling.user_frac: 50
kern.polling.reg_frac: 20
kern.polling.short_ticks: 258
kern.polling.lost_polls: 4
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 1
kern.polling.enable: 1
kern.polling.phase: 0
kern.polling.suspect: 2
kern.polling.stalled: 0
kern.polling.idlepoll_sleeping: 1

[ 本帖最后由 xie_minix 于 2006-5-25 10:26 编辑 ]

论坛徽章:
0
发表于 2006-05-25 10:24 |显示全部楼层
原帖由 雨丝风片 于 2006-5-25 09:47 发表


从楼主的数据长度即可判断出测试的时候肯定会使用cluster了:

当然,由于mbuf头结构的修改,目前的门限数值比208还要小。现在就是想先看看它不用cluster的时候的测试性能如何。

Less than 208? I've traced the code. sizeof(m_hdr) == 24, sizeof(pkthdr) == 24, without m_ext, the maximum size of the data can be stored is 208. These number is when you are running on i386.
I'm running amd64, so the calculation may be incorrect, and under amd64 sizeof(m_hdr)==sizeof(pkthdr)==40, it's so depressing...:em12:

论坛徽章:
0
发表于 2006-05-25 10:31 |显示全部楼层
我把msize改为4096性能也无提升,看来不是MSIZE的问题:
下面是发包的时候抓下来的系统参数:

现在CPU占用率倒是上去了,发512字节的包的时候,到达了平均27%。我又测试了64字节的性能,也没有提升!在64字节下,双向各以18万pps速率发包的时候,CPU占用率也大幅提高,到达81%!可恨的是性能并无丝毫提升!
# sysctl -a | grep mbuf
     mbuf_tag     0     0K       -        2  32
mbuf_jumbo_1:  16384,        0,      0,      0,        0
mbuf_jumbo_9:   9216,        0,      0,      0,        0
mbuf_jumbo_p:   4096,        0,      0,      0,        0
mbuf_cluster:   2048,    16960,   2048,      6,     2048
mbuf:           4096,        0,   2050,    126,      746
mbuf_packet:    4096,        0,   1983,    193,  3819588

# sysctl -a | grep kern.polling
kern.polling.idlepoll_sleeping: 1
kern.polling.stalled: 66
kern.polling.suspect: 6078
kern.polling.phase: 0
kern.polling.enable: 1
kern.polling.handlers: 4
kern.polling.residual_burst: 0
kern.polling.pending_polls: 0
kern.polling.lost_polls: 8083
kern.polling.short_ticks: 1400
kern.polling.reg_frac: 200
kern.polling.user_frac: 20
kern.polling.idle_poll: 0
kern.polling.each_burst: 300
kern.polling.burst_max: 500
kern.polling.burst: 500

强烈怀疑是内存操作速度太慢所致。
可是怎么验证呢。

[ 本帖最后由 xfsoul 于 2006-5-25 10:35 编辑 ]

论坛徽章:
0
发表于 2006-05-25 11:06 |显示全部楼层
原帖由 antijp 于 2006-5-25 10:24 发表

Less than 208? I've traced the code. sizeof(m_hdr) == 24, sizeof(pkthdr) == 24, without m_ext, the maximum size of the data can be stored is 208. These number is when you are running on i386.
I' ...



呵呵,是我没注意。Stevens写书的时候用的MSIZE是128,那个时候决定MINCLSIZE的方法就是两个mbuf的数据区大小,一个带packet头,一个不带。因此,Stevens所举的4.4BSD中的MINCLSIZE就是128-20+128-20-8 = 208,也就是说只要用两个mbuf无法存储的数据,就需要使用cluster。(使用这个算法,如果MSIZE是256,则MINCLSIZE为464)

后来,mbuf的头结构确实是扩展了,但MINCLSIZE的计算方法也改了。假设MSIZE为256,则MINCLSIZE为256-24-24+1 = 209,凡大于等于这个数值的数据就需要使用cluster。相对于4.4BSD中MSIZE同样等于256的情况(MINCLSIZE =464),这个门限降低了一半。

论坛徽章:
0
发表于 2006-05-25 12:16 |显示全部楼层
Now I'm building 6.1 on another i386 machine, I'll check the size later.
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP