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

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

個人感覺這個測試結(jié)果大包性能提升不太像mbuf大小問題。

mirnshi

帖子好長呀，看了半天。

如果是橋模式，從網(wǎng)卡中斷開始，一直到這個包不在2層，都是在一個中斷里，所以橋轉(zhuǎn)發(fā)的效率很關(guān)鍵，專做橋設(shè)備就需要增加隊列之類的，提高包響應(yīng)速度了，否則僅僅要響應(yīng)中斷，系統(tǒng)就受不了了。
polling模式在某些情況下是可以提高效率的，polling模式主要原理就是網(wǎng)卡將數(shù)據(jù)包放到隊列中，cpu通過輪訓(xùn)的方式獲取數(shù)據(jù)包，屬于主動方式，而中斷相當(dāng)于被動接收。如果cpu在輪訓(xùn)間隔內(nèi)可以有效地處理隊列中的包，就可以提高效率，否則就會降低效率。
查看系統(tǒng)效率，尤其是網(wǎng)卡的，不僅僅要看vmstat，netstat可是必須要看的，可以看到包流量，錯誤數(shù)等等。在有足夠cpu處理的情況下，如果流量上不去，那就要看看網(wǎng)卡了，看看錯誤數(shù)是不是很高。這些數(shù)據(jù)都是互相影響的，但也不能作為唯一判定值。所以一定要通過判斷vmstat，netstat的監(jiān)測數(shù)據(jù)，在去調(diào)整相應(yīng)參數(shù)。

將mbuf的尺寸增大，并不會帶來特別顯著的提高，系統(tǒng)會根據(jù)包的大小，自動分拆的，大家可以看看協(xié)議棧的實現(xiàn)。

caibird3rd

注意別把注意力全放在操作系統(tǒng)上，測試機(jī)本身（所用總線規(guī)格等）、網(wǎng)絡(luò)連接、smartbit的設(shè)置 等等
都應(yīng)該檢查一遍

xie_minix

其實樓主的要求很簡單,他想把FB下千兆卡的效率提高到能和LINUX差不多就行了.
我們是來給他想辦法,同時也提高我們自己.去尋找具體原因.你可以懷疑某個地
方出問題,即使是比較幼稚的想法.但必須去實現(xiàn).用代碼或調(diào)試各種參數(shù)去測試.
另外說句: 樓上的caibird3rd明顯沒進(jìn)入狀態(tài).哈哈
已經(jīng)有很多人都在反映該問題.我知道的許多非常專業(yè)的放火墻開發(fā)人員(DDOS方向)
也遇到此問題.到目前還沒有解決.以至于他們轉(zhuǎn)向了LINUX.
對于現(xiàn)在的FB,鎖的粗細(xì)粒度使用的還是有問題.比如大家看看POLLING的5.3.使用
GAINT太多,還有些代碼重復(fù),不多評論了.繼續(xù)檢查

www_ftp

在Free BSD 6.0以后,polling的確不起什么作用,就是調(diào)的參數(shù)再好,最多只能達(dá)到不開polling的程度.在linux下也測試過打不打開polling性能也沒有什么變化.聽過4.11打開與不打開polling差別很大.

xfsoul

我現(xiàn)在已經(jīng)不指望通過調(diào)節(jié)FreeBSD參數(shù)來提高性能了。
我暫停這個測試，下周繼續(xù)在另外一個平臺上測試性能。
我已經(jīng)配置好了FreeBSD 4.11和FreeBSD6.1雙系統(tǒng)。對于該平臺，linux的性能已經(jīng)測試過了，由于該平臺性能比較強(qiáng)，linux表現(xiàn)還過得去。
硬件平臺：
CPU：雙路Opteron 2.4G
內(nèi)存：1G DDR400 雙通道開啟，ECC關(guān)閉
網(wǎng)卡：Intel雙光纖口網(wǎng)卡、Intel雙口網(wǎng)卡。這四個網(wǎng)卡都是連接在北橋上，PCI-X 64bit， 133MHz。

大約下周二開始測試。大家有空不妨幫我想想辦法呵，我先謝過了。

caibird3rd

原帖由 xie_minix 于 2006-5-25 16:07 發(fā)表
其實樓主的要求很簡單,他想把FB下千兆卡的效率提高到能和LINUX差不多就行了.
我們是來給他想辦法,同時也提高我們自己.去尋找具體原因.你可以懷疑某個地
方出問題,即使是比較幼稚的想法.但必須去實現(xiàn).用代碼或調(diào)試各種參數(shù)去測試.
另外說句: 樓上的caibird3rd明顯沒進(jìn)入狀態(tài).哈哈
已經(jīng)有很多人都在反映該問題.我知道的許多非常專業(yè)的放火墻開發(fā)人員(DDOS方向)
也遇到此問題.到目前還沒有解決.以至于他們轉(zhuǎn)向了LINUX.
對于現(xiàn)在的FB,鎖的粗細(xì)粒度使用的還是有問題.比如大家看看POLLING的5.3.使用
GAINT太多,還有些代碼重復(fù),不多評論了.繼續(xù)檢查 ...

哈哈，對FB我倒是不熟，只是略有耳聞FB的性能如何穩(wěn)定和有效率，真的比Linux差很多嗎？
說老實話，對于比較成熟的一個發(fā)行版來說，其運行時的各種缺省參數(shù)一般都是仔細(xì)調(diào)優(yōu)了的，充分
權(quán)衡了各個子系統(tǒng)的影響、考慮到了各類常見應(yīng)用環(huán)境。

懷疑僅僅通過調(diào)整參數(shù)，能夠獲得多大的性能提升。
我的經(jīng)驗，這種情況，要么是系統(tǒng)代碼內(nèi)在結(jié)構(gòu)決定，要么就是硬件平臺甚至測試環(huán)境的影響。
不是我瞧不起各位老大的能力，前者的分析很難啊。
在這里給各位加油，希望有一天FB里面也有大量國人的補(bǔ)丁，呵呵

mirnshi

原帖由 caibird3rd 于 2006-5-25 17:29 發(fā)表


哈哈，對FB我倒是不熟，只是略有耳聞FB的性能如何穩(wěn)定和有效率，真的比Linux差很多嗎？
說老實話，對于比較成熟的一個發(fā)行版來說，其運行時的各種缺省參數(shù)一般都是仔細(xì)調(diào)優(yōu)了的，充分
權(quán)衡了各個子系統(tǒng)的影 ...

無論OS，還是DB，它的發(fā)行版都是為了適合絕大多數(shù)情況的，要想在某種應(yīng)用和場合發(fā)揮最大的性能，各項參數(shù)是必須調(diào)整的。所以不要這么講，否則各類系統(tǒng)的管理員就要失業(yè)了。

xie_minix

mirnshi:
我猜想,開發(fā)POLLING的團(tuán)隊有問題.他們對MUTEX的了解不夠,最起碼在5.3版本時.
這是最要命的事情.
其次,寫代碼時沒經(jīng)過思考(請原諒我這么說,他們也不容易),比如你看:
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);    <---------
他是不是怕沒鎖住啊,哈哈