測試系統在linux上的效能發現丟包率極為嚴重，發210000條資料，丟包達110000之巨，丟包率超過50%。同等情形下windows上測試，僅丟幾條資料。形勢嚴峻，必須解決。考慮可能是因為協議棧buffer太低所致，於是先看看預設情況：
sysctl -a |grep net.core
發現net.core.rmem_max = 131071
net.core.rmem_default = 112640
修改吧，變大一點，變成10m，然後reboot（應該重啟某個服務即可）
然後查網絡卡收包情況：
netstat -su
結果如下：
udp:
97690 packets received
112310 packets to unknown port received.
0 packet receive errors
20 packets sent
發現資料在網絡卡就丟了，判斷可能是防火牆引起的，於是執行命令：
iptables -l
結果如下：
chain input (policy accept)
target prot opt source destination
chain forward (policy accept)
target prot opt source destination
chain output (policy accept)
target prot opt source destination
證明iptables啟動，於是停止防火牆：
service iptables stop
這個命令即時生效，開啟防火牆的命令：
service iptables start
如果要徹底關閉防火牆，則需要重啟後生效
開啟： chkconfig iptables on
關閉： chkconfig iptables off
在開啟了防火牆時，做如下設定，開啟相關埠，
修改/etc/sysconfig/iptables 檔案，新增以下內容：
-a rh-firewall-1-input -m state --state new -m tcp -p tcp --dport 80 -j accept
-a rh-firewall-1-input -m state --state new -m tcp -p tcp --dport 22 -j accept
重新測試，沒丟一條資料。
linux 核心引數調整說明
所有的tcp/ip調優引數都位於/proc/sys/net/目錄。例如, 下面是最重要的一些調優引數, 後面是它們的含義:
1. /proc/sys/net/core/rmem_max — 最大的tcp資料接收緩衝。
2. /proc/sys/net/core/wmem_max — 最大的tcp資料傳送緩衝。
3. /proc/sys/net/ipv4/tcp_timestamps — 時間戳在(請參考rfc 1323)tcp的包頭增加12個位元組。
4. /proc/sys/net/ipv4/tcp_sack — 有選擇的應答。
5. /proc/sys/net/ipv4/tcp_window_scaling — 支援更大的tcp視窗. 如果tcp視窗最大超過65535(64kb), 必須設定該數值為1。
6. rmem_default — 預設的接收視窗大小。
7. rmem_max — 接收視窗的最大大小。
8. wmem_default — 預設的傳送視窗大小。
9. wmem_max — 傳送視窗的最大大小。
/proc目錄下的所有內容都是臨時性的, 所以重啟動系統後任何修改都會丟失。
建議在系統啟動時自動修改tcp/ip引數:
把下面**增加到/etc/rc.local檔案, 然後儲存檔案, 系統重新引導的時候會自動修改下面的tcp/ip引數:
echo 256960 > /proc/sys/net/core/rmem_default
echo 256960 > /proc/sys/net/core/rmem_max
echo 256960 > /proc/sys/net/core/wmem_default
echo 256960 > /proc/sys/net/core/wmem_max
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_sack
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
tcp/ip引數都是自解釋的, tcp視窗大小設定為256960, 禁止tcp的時間戳(取消在每個資料報的頭中增加12位元組), 支援更大的tcp視窗和tcp有選擇的應答。
上面數值的設定是根據互連網連線和最大頻寬/延遲率來決定。
注: 上面例項中的數值可以實際應用, 但它只包含了一部分引數。
另外乙個方法: 使用 /etc/sysctl.conf 在系統啟動時把引數配置成您所設定的值:
net.core.rmem_default = 256960
net.core.rmem_max = 256960
net.core.wmem_default = 256960
net.core.wmem_max = 256960
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack =1
net.ipv4.tcp_window_scaling = 1
設定linux核心引數
配置 linux 核心引數(2種方法),修改後不用重啟動更新: /sbin/sysctl -p
第一種:開啟/etc/sysctl.conf 複製如下內容
kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144
第二種:開啟終端
cat >> /etc/sysctl.conf<
kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144
eof這裡，對每個引數值做個簡要的解釋和說明。
（1）shmmax：該引數定義了共享記憶體段的最大尺寸（以位元組為單位）。預設為32m，對於oracle來說，該預設值太低了，通常將其設定為2g。
（2）shmmni：這個核心引數用於設定系統範圍內共享記憶體段的最大數量。該引數的預設值是 4096 。通常不需要更改。
（3）shmall：該引數表示系統一次可以使用的共享記憶體總量（以頁為單位）。預設值就是2097152，通常不需要修改。
（4）sem：該引數表示設定的訊號量。
（5）file-max：該引數表示檔案控制代碼的最大數量。檔案控制代碼設定表示在linux系統中可以開啟的檔案數量。
修改好核心以後，執行下面的命令使新的配置生效。
[root @linux1 /root]# /sbin/sysctl -p
以 root 使用者身份執行以下命令來驗證您的設定：
/sbin/sysctl -a | grep shm
/sbin/sysctl -a | grep sem
/sbin/sysctl -a | grep file-max
/sbin/sysctl -a | grep ip_local_port_range
例如：# /sbin/sysctl -a | grep shm
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shm-use-bigpages = 0
# /sbin/sysctl -a | grep sem
kernel.sem = 250 32000 100 128
# /sbin/sysctl -a | grep file-max
fs.file-max = 65536
# /sbin/sysctl -a | grep ip_local_port_range
net.ipv4.ip_local_port_range = 1024 65000
/sbin/sysctl -p
ps：通常用預設引數就可以了吧.
Linux UDP嚴重丟包問題的解決
測試系統在linux上的效能發現丟包率極為嚴重，發210000條資料，丟包達110000之巨，丟包率超過50 同等情形下windows上測試，僅丟幾條資料。形勢嚴峻，必須解決。考慮可能是因為協議棧buffer太低所致，於是先看看預設情況 sysctl a grep net.core 發現net.co...
網路資料丟包嚴重 線路環路是其禍首
仔細對這類現象進行總結後，我們發現最容易造成資料丟包現象的因素就是網路環路，畢 竟在規模稍微大一點的區域網環境中，網路管理員很容易把交換機之間的埠連線錯誤，從而引起網路環路現象，並且這種現象由於有比較強的隱蔽性，我們在排除 這類故障的時候要是不留神的話很容易多走彎路！為了幫助各位高效解決資料丟包嚴重...
UDP丟包及無序的問題
最近在做乙個專案,在這之前,做了個驗證程式.發現客戶端連續發來1000個1024位元組的包,伺服器端出現了丟包現象.糾其原因,是服務端在還未完全處理掉資料,客戶端已經資料傳送完畢且關閉了.有沒有成熟的解決方案來解決這個問題.我用過sleep 1 暫時解決這個問題,但是這不是根本解決辦法,如果資料量大...