天天看點

Ubuntu tcp緩存設定--tcp buffer參數優化

本文基于CENTOS 、DEBIAN/UBUNTU 編寫 。

我有兩台位于不同資料中心的伺服器,都用來處理很多并行的大檔案傳輸。但是處理大檔案,網絡性能非常差。并且涉及到一個大檔案,會導緻性能降級。我怎樣通過調整Linux下面的 TCP 來解決這個問題?

預設,Linux的stack是沒有為廣域網之間的大檔案高速傳輸而配置的,這樣做是為了節約記憶體資源。為了使連接配接的系統服務之間能有更加高速的網絡處理更多的網絡包,你可以很容易的通過增加網絡 buffer size 來調整 Linux 網絡 stack 。

預設的 Linux buffer size 的最大值是非常小的,tcp 的記憶體是基于系統的記憶體自動計算的,你能通過鍵入以下指令找到實際的值:

 $ cat /proc/sys/net/ipv4/tcp_mem

預設的和最大的接收資料包記憶體大小:

$ cat /proc/sys/net/core/rmem_default

$ cat /proc/sys/net/core/rmem_max

預設的和最大的發送資料包記憶體的大小:

$ cat /proc/sys/net/core/wmem_default

$ cat /proc/sys/net/core/wmem_max

最大的記憶體 buffers 的選項:

$ cat /proc/sys/net/core/optmem_max

調整值

為所有的協定隊列設定作業系統層面的最大的發送 buffer size (wmem) 和 接收 buffer size (rmem)為 12 MB。換句話說,設定記憶體數量,配置設定給每一個為了傳送檔案而打開或者是建立的 tcp socket 。

警告 警告!在大多數的 Linux 中 rmem_max和wmem_max 被配置設定的值為 128 k,在一個低延遲的網絡環境中,或者是 apps 比如 DNS、Web Server,這或許是足夠的。盡管如此,如果延遲太大,預設的值可能就太小了,是以請記錄以下在你的伺服器上用來提高記憶體使用方法的設定。

# echo 'net.core.wmem_max=12582912' >> /etc/sysctl.conf

# echo 'net.core.rmem_max=12582912' >> /etc/sysctl.conf

你還需要設定 minimum size, initial size, and maximum size in bytes:

# echo 'net.ipv4.tcp_rmem= 10240 87380 12582912' >> /etc/sysctl.conf

# echo 'net.ipv4.tcp_wmem= 10240 87380 12582912' >> /etc/sysctl.conf

打開 window scaling ,這是一個用來擴充傳輸視窗的選項:

# echo 'net.ipv4.tcp_window_scaling = 1' >> /etc/sysctl.conf

確定定義在 RFC1323 中的 timestamps打開:

# echo 'net.ipv4.tcp_timestamps = 1' >> /etc/sysctl.conf

確定 select acknowledgments:

# echo 'net.ipv4.tcp_sack = 1' >> /etc/sysctl.conf

這個 “select acknowledgments” 不知道該如何翻譯,翻譯為“選擇确認?”

當連接配接關閉的時候,TCP 預設緩存了很多連接配接名額在 route cache 中,以至于在不久的将來,連接配接建立的時候,可以用這些值來設定初始化條件。通常,這提升了整體的性能,但是,有時候會引起性能下降, 如果設定的話,TCP 在關閉的時候不緩存這些名額。

# echo 'net.ipv4.tcp_no_metrics_save = 1' >> /etc/sysctl.conf

當 interface 接收到的資料包數量比核心處理速度的快的時候, 設定 input 隊列最大的 packets 數量值。

# echo 'net.core.netdev_max_backlog = 5000' >> /etc/sysctl.conf

現在重載這些改變,使其生效:

# sysctl -p

使用 tcpdump 指令檢視 通過 eth0 資料包流量的變化:

# tcpdump -ni eth0

推薦閱讀:

請參考核心文檔/networking/ip-sysctl.txt擷取更加多的資訊

請檢視sysctl的man手冊

原文連結:http://blog.csdn.net/dongfengkuayue/article/details/50599967

繼續閱讀