精通polling參數(shù)調(diào)優(yōu)的進(jìn)來(lái)幫幫忙吧

mirnshi

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


請(qǐng)教一下，這個(gè)分拆體現(xiàn)在哪兒？

擴(kuò)大mbuf尺寸，不考慮是否真能提高性能，至少可以盡量避免系統(tǒng)使用mbuf鏈或者cluster。另外，樓主兩個(gè)網(wǎng)卡mtu一致，而且是二層轉(zhuǎn)發(fā)，似乎也涉及不到ip fragmentation的問(wèn)題 ...

這個(gè)分拆，是不恰當(dāng)?shù)�，我的本意是分揀。�?xiě)完后，沒(méi)有仔細(xì)審看，表示歉意。

在協(xié)議棧實(shí)現(xiàn)中，會(huì)根據(jù)包的大小，申請(qǐng)不同的mbuf。而且在我的印象中，從網(wǎng)卡上來(lái)的包使用不到cluster，或者說(shuō)承擔(dān)轉(zhuǎn)發(fā)時(shí)，是不使用cluster的，只有從會(huì)話層下來(lái)的時(shí)候，由于數(shù)據(jù)包很大，需要拆成適宜大小并組成cluster。所以我以往的經(jīng)驗(yàn)，做網(wǎng)關(guān)類，不必調(diào)整cluster的數(shù)量，mbuf的數(shù)量倒是很重要，如果有大隊(duì)列，還要調(diào)整內(nèi)核可使用的內(nèi)存空間大小。

所以你即便將mbuf調(diào)得很大，協(xié)議棧還是要判斷一下，再去申請(qǐng)。系統(tǒng)缺省已經(jīng)有2k的了，足夠應(yīng)付鏈路上的包了，那你說(shuō)提高最小的mbuf有必要嗎？只會(huì)浪費(fèi)內(nèi)存。

雨絲風(fēng)片

原帖由 mirnshi 于 2006-5-26 10:30 發(fā)表
在協(xié)議棧實(shí)現(xiàn)中，會(huì)根據(jù)包的大小，申請(qǐng)不同的mbuf。而且在我的印象中，從網(wǎng)卡上來(lái)的包使用不到cluster，或者說(shuō)承擔(dān)轉(zhuǎn)發(fā)時(shí)，是不使用cluster的，只有從會(huì)話層下來(lái)的時(shí)候，由于數(shù)據(jù)包很大，需要拆成適宜大小并組成cluster。所以我以往的經(jīng)驗(yàn)，做網(wǎng)關(guān)類，不必調(diào)整cluster的數(shù)量，mbuf的數(shù)量倒是很重要，如果有大隊(duì)列，還要調(diào)整內(nèi)核可使用的內(nèi)存空間大小。

所以你即便將mbuf調(diào)得很大，協(xié)議棧還是要判斷一下，再去申請(qǐng)。系統(tǒng)缺省已經(jīng)有2k的了，足夠應(yīng)付鏈路上的包了，那你說(shuō)提高最小的mbuf有必要嗎？只會(huì)浪費(fèi)內(nèi)存。 ...

“從網(wǎng)卡上來(lái)的包使用不到cluster”，那m_devget()函數(shù)中的此段代碼何解？

1. 
   
2. 
   
3.                         if (totlen + off >= MINCLSIZE) {
   
4.                                 m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR);
   
5.                                 len = MCLBYTES;
   
6.                         } else {
   
7.                                 m = m_gethdr(M_DONTWAIT, MT_DATA);
   
8.                                 len = MHLEN;
   

復(fù)制代碼

“所以你即便將mbuf調(diào)得很大，協(xié)議棧還是要判斷一下，再去申請(qǐng)�！�，修改mbuf的大小，就是要影響協(xié)議棧的上述“判斷”過(guò)程。

上面是和你討論“拆分”的事情，現(xiàn)在回到樓主的測(cè)試，修改mbuf的大小只是嘗試上述不同的分配策略是否會(huì)對(duì)此造成影響，這主要是流程性的影響。如你所說(shuō)，可供mbuf使用的內(nèi)存數(shù)量確實(shí)也是一個(gè)關(guān)鍵，我們可以在測(cè)試過(guò)程中關(guān)注內(nèi)存的使用情況，看看這方面是否有瓶頸。

xfsoul

內(nèi)存占用到不大。應(yīng)該是性能拷貝的性能消耗太大。

xie_minix

netisr_pollmore函數(shù)中的       
kern_load = (kern_load * hz) / 10000;這句有問(wèn)題.
應(yīng)該錯(cuò)了.
他的錯(cuò)誤的算法將導(dǎo)致hz在默認(rèn)100時(shí)性能...
kern.polling.dbg.pollkern: 1            這是網(wǎng)絡(luò)軟中斷所占比率為1%
kern.polling.dbg.kernpoll_burst: 150   以至于poll_burst不斷增加到頂.
kern.polling.dbg.on_cpu1: 0
kern.polling.dbg.net_load: 0
kern.polling.dbg.poll_invoke: 344070598
kern.polling.dbg.poll_suspect: 744461
kern.polling.dbg.pollmore_coun: 719577
kern.polling.dbg.poll_coun: 744461
下個(gè)帖有說(shuō)明,是我的想法有問(wèn)題.

[ 本帖最后由 xie_minix 于 2006-5-26 13:47 編輯 ]

xfsoul

xie_minix兄、版主兄還有其他幾位兄弟，大家一起努力啊。
如果能把FreeBSD polling的一些缺陷修正，也算是對(duì)FreeBSD的不小貢獻(xiàn)了。

xie_minix

不對(duì),還是我錯(cuò)了,向大家解釋一下:
if (kern_load > (100 - user_frac)) {
這句的原本意思是:
求軟件中斷在整個(gè)1秒時(shí)間所占百分比是否大于減去其他所占用時(shí)間.
大于就說(shuō)明時(shí)間夠了.poll_burst--;
小于則poll_burst++只要加后不大于最大值.
poll_burst的值很重要,要不然就不能體現(xiàn)出整個(gè)算法的合理性.
我們?cè)趤?lái)看看kern_load = (kern_load * hz) / 10000;這句
是為了求得網(wǎng)絡(luò)軟中斷所占1秒中的比率.10000這個(gè)常量有點(diǎn)
很難懂.kern_load之前得到的是軟件中斷所使用的毫秒.
那么kern_load*hz代表每秒鐘軟中斷大概是占了多少毫秒,
這樣推算的話,10000應(yīng)該是1000000/100,即先除以1百萬(wàn)毫秒(1秒)
得到百分比,再乘以100取出百分?jǐn)?shù).
哎這個(gè)10000也不寫(xiě)個(gè)說(shuō)明.

[ 本帖最后由 xie_minix 于 2006-5-26 13:48 編輯 ]

雨絲風(fēng)片

原帖由 xie_minix 于 2006-5-26 13:46 發(fā)表
不對(duì),還是我錯(cuò)了,向大家解釋一下:
if (kern_load > (100 - user_frac)) {
這句的原本意思是:
求軟件中斷在整個(gè)1秒時(shí)間所占百分比是否大于減去其他所占用時(shí)間.
大于就說(shuō)明時(shí)間夠了.poll_burst--;
小于則p ...

原來(lái)如此！看來(lái)此公編程風(fēng)格有待改進(jìn)。
對(duì)于polling的算法還不熟，結(jié)合你的文章，繼續(xù)閱讀代碼。

mirnshi

原帖由 雨絲風(fēng)片 于 2006-5-26 11:41 發(fā)表

...

回答問(wèn)題前，需要仔細(xì)看代碼了，許久不弄，就是生疏了。
我看了看以前調(diào)優(yōu)的一些記錄，的確和cluster相關(guān)的，可以通過(guò)調(diào)高nmbcluster參數(shù)，提高系統(tǒng)處理網(wǎng)絡(luò)效率
這個(gè)參數(shù)需要在啟動(dòng)時(shí)，設(shè)置，一旦內(nèi)核啟動(dòng)了，就不能更改了。在/boot/loader.rc中設(shè)置
警告：這個(gè)值不能過(guò)大，否則系統(tǒng)會(huì)因沒(méi)有足夠的內(nèi)存分配而啟動(dòng)不起來(lái)

[ 本帖最后由 mirnshi 于 2006-5-26 14:10 編輯 ]

mirnshi

FreeBSD在網(wǎng)絡(luò)處理上，我一直認(rèn)為是非常強(qiáng)的，我曾在志強(qiáng)2.4，內(nèi)存1G，4.11，接收900MB，CPU還能空余5-9%，但是發(fā)包就不行了，只能達(dá)到3、400MB。這是為了測(cè)試極限值，所有的包都是收到就丟棄。所以能達(dá)到極限。

xfsoul

我在PD 820和AMD Opteron平臺(tái)，linux網(wǎng)橋透明轉(zhuǎn)發(fā)。當(dāng)包>512時(shí)候，雙向千兆線速轉(zhuǎn)發(fā)，輕松愉快！