Re: [問題] rtorrent中的send buffer設定有何作用?

看板P2PSoftWare作者 (阿平)時間17年前 (2008/09/06 15:16), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串2/2 (看更多)
※ 引述《mander (阿平)》之銘言: 這裡的send/receive buffer效果,與系統中的buffer/cache比較有什麼差異呢? 原本的預設值是0/0K,在設定了buffer size後(send/receive 各設成200MB/20MB後) 放了5分鐘 10分鐘 30分鐘 檢查了記憶體使用量,好像並沒有什麼變化... 程式的記憶體使用量也沒有增加(維持44MB) $ free -m total used free shared buffers cached Mem: 504 498 5 0 4 449 -/+ buffers/cache: 44 459 Swap: 282 0 282 若站在減少磁碟讀寫的角度,有必要設定此項嗎? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.104.108.84

09/05 01:59,
增加當然有用 至於你用free去看可能不太準確 因為
09/05 01:59

09/05 02:00,
記憶體的使用要看kernel設定 有的設定會把free的吃到
09/05 02:00

09/05 02:00,
剩下一點點 吃掉的那些都拿來做磁碟快取或是其他IO使
09/05 02:00

09/05 02:01,
用 不如用ps去看單獨的process吃掉多少比較準一點
09/05 02:01
謝謝 系統kernel版本是Linux debian 2.6.25-2-686 ps的內容像是下面這樣嗎 這是大約前一篇文時的狀態 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND home 17863 4.3 9.6 91100 49728 pts/1 S+ Sep04 58:08 rtorrent ram使用約48mb,ul/dl rate在19/100k左右 ........... 過了一天後如下,使用量降低猜測是流量變小了 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND home 17863 3.4 3.4 35868 17732 pts/1 S+ Sep04 104:13 rtorrent 約17mb,ul/dl rate在19/1.7k 並補上相對應的free -m狀態 $ free -m total used free shared buffers cached Mem: 504 498 5 0 3 454 -/+ buffers/cache: 40 463 Swap: 282 0 282 從以上觀察看起來,buffer size的大小好像不影響程式的記憶體使用量 又或者是buffer size的設定是沒有生效或作用的!? 根據 http://tinyurl.com/3x6nyj 有提到的一段指令 跟著照打 "cat /proc/sys/net/ipv4/tcp_wmem" 得到了 三個數字 $cat /proc/sys/net/ipv4/tcp_wmem 4096 16384 2076672 (三個數字的意義 http://steve.chinavfx.net/?p=42) 話說rotrrent中 buffer size的設定好像跟這是沒關係的(?),設了對tcp_wmem並沒有 任何影響,不知為何要在文章中提到這個指令.. 推 gen2linux :http://tinyurl.com/3x6nyj 09/05 02:10

09/05 02:12,
socket buffer設到200MB會不會太誇張..
09/05 02:12

09/05 02:14,
一般經由setsockopt增大buf對效能都是有效的
09/05 02:14

09/05 02:17,
只是單位通常是kbytes吧
09/05 02:17
其實我對send buffer在系統中扮演的腳色不太清楚 200M是在找資料的過程中,剛好看到了有別人放上來的設定檔有這樣設的 http://ja.pastebin.ca/1177305 內容是臨時性的,應該不久會被洗掉 內容的正確性未知,想說先設定看看效果如何 結果是如同上面所寫的,覺得也許可以跟各為討論討論 目前暫時看不出有明顯的效果 orz...

09/05 10:39,
send/receive buffer同磁碟讀寫關係不大, 它們是用
09/05 10:39

09/05 10:49,
來解決雙方傳輸速率不同以及傳送失敗需要重新發送。
09/05 10:49

09/06 03:35,
不只是這樣,那段buffer是提供kernel vs user space
09/06 03:35

09/06 03:36,
的緩衝,越大越可能減少互相拷貝的次數,以提升效能
09/06 03:36

09/06 03:37,
但對於"磁碟讀寫"這回事來說,跟應用程式本身的實作
09/06 03:37

09/06 03:37,
方法較相關沒錯
09/06 03:37
就磁碟讀寫這部分,根據我用"肉眼"的觀察,硬碟燈的頻率沒有明顯差異 至少在30秒的觀察中並沒有很明顯的變化 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 203.67.184.14
文章代碼(AID): #18mYv8Lp (P2PSoftWare)
文章代碼(AID): #18mYv8Lp (P2PSoftWare)