精通polling參數(shù)調(diào)優(yōu)的進來幫幫忙吧

colddawn

另外注意到你測試的數(shù)據(jù)FB的CPU占用率方面比較奇怪，尤其是小包的第一個50%，是不是開啟了HTT？關(guān)閉掉試試看。
還有這個參數(shù)kern.polling.user_frac: Desired user fraction of cpu time
把user占用的cpu時間片盡量壓縮，這樣內(nèi)核CPU利用率會比較高，畢竟linux下都高過90%了，F(xiàn)B這么少說明是有問題的。

xfsoul

原帖由 colddawn 于 2006-5-25 09:54 發(fā)表
kern.polling.burst_max: 300
kern.polling.burst: 300
這兩個值一樣，似乎burst不夠用了，繼續(xù)調(diào)大些試試看？？

HZ=4000
burst=300
理論可以發(fā)120萬pps呢。

ps:我調(diào)成500性能也無變化

xfsoul

原帖由 colddawn 于 2006-5-25 09:59 發(fā)表
另外注意到你測試的數(shù)據(jù)FB的CPU占用率方面比較奇怪，尤其是小包的第一個50%，是不是開啟了HTT？關(guān)閉掉試試看。
還有這個參數(shù)kern.polling.user_frac: Desired user fraction of cpu time
把user占用的cpu時間片 ...

那個參數(shù)調(diào)整到更小也沒有意義，我從5開始每10一個檔都調(diào)節(jié)過了。

CPU利用率很低 我也很奇怪，為什么這么多資源FB不去使用。
但是如果不開polling，CPU占用就上去了，也是90%多。

colddawn

kern.polling.burst: Current polling burst size
fw2# sysctl -d kern.polling.burst_max
kern.polling.burst_max: Max Polling burst size

應(yīng)該是要調(diào)整max，lz是說錯了還是調(diào)錯了？

xfsoul

原帖由 colddawn 于 2006-5-25 10:03 發(fā)表
kern.polling.burst: Current polling burst size
fw2# sysctl -d kern.polling.burst_max
kern.polling.burst_max: Max Polling burst size

應(yīng)該是要調(diào)整max，lz是說錯了還是調(diào)錯了？

我就是調(diào)整的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
都試過了。

我測試的數(shù)據(jù)是我微調(diào)內(nèi)核參數(shù)得到的最好數(shù)據(jù)。

xie_minix

我還是希望能看到大概每秒執(zhí)行軟中斷的次數(shù)(POLLING),這樣可以確定調(diào)度器及系統(tǒng)的基本情況.
我在我家里的機器上(SMP PII 450  256M  if_vr * 1)
3. 一些測試值:
   kern.polling.dbg.poll_coun: 5404323  軟中斷實現(xiàn)的總次數(shù),默認(rèn)設(shè)置每秒大概在30000左右次調(diào)用
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 編輯 ]

antijp

原帖由 雨絲風(fēng)片 于 2006-5-25 09:47 發(fā)表


從樓主的數(shù)據(jù)長度即可判斷出測試的時候肯定會使用cluster了：

當(dāng)然，由于mbuf頭結(jié)構(gòu)的修改，目前的門限數(shù)值比208還要小。現(xiàn)在就是想先看看它不用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:

xfsoul

我把msize改為4096性能也無提升，看來不是MSIZE的問題：
下面是發(fā)包的時候抓下來的系統(tǒng)參數(shù)：

現(xiàn)在CPU占用率倒是上去了，發(fā)512字節(jié)的包的時候，到達了平均27%。我又測試了64字節(jié)的性能，也沒有提升！在64字節(jié)下，雙向各以18萬pps速率發(fā)包的時候，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

強烈懷疑是內(nèi)存操作速度太慢所致。
可是怎么驗證呢。

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

雨絲風(fēng)片

原帖由 antijp 于 2006-5-25 10:24 發(fā)表

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的數(shù)據(jù)區(qū)大小，一個帶packet頭，一個不帶。因此，Stevens所舉的4.4BSD中的MINCLSIZE就是128-20+128-20-8 = 208，也就是說只要用兩個mbuf無法存儲的數(shù)據(jù)，就需要使用cluster。（使用這個算法，如果MSIZE是256，則MINCLSIZE為464）

后來，mbuf的頭結(jié)構(gòu)確實是擴展了，但MINCLSIZE的計算方法也改了。假設(shè)MSIZE為256，則MINCLSIZE為256-24-24+1 = 209，凡大于等于這個數(shù)值的數(shù)據(jù)就需要使用cluster。相對于4.4BSD中MSIZE同樣等于256的情況（MINCLSIZE =464），這個門限降低了一半。

antijp

Now I'm building 6.1 on another i386 machine, I'll check the size later.