Linux系統優化之網絡IO調優

 

 

首先說明，對於linux系統而言，tcp/ip協議棧是工做在內核空間中實現並且在內核中是按照流水線方式實現的

當咱們去接收一個報文時，由各棧去解封裝，而這是由流水線去處理的

而流水線是非copy類型的，所謂非copy相似就是直接送往下一個流水線而不是從TCP內存中複製到IP棧的內存，而是直接將此段空間讓給IP使用，因此交給下一個關口的時候挪動的不是數據而是協議棧，因此數據一直在同一段內存中存放，接收數據的時候要先在內存中應用IP協議棧、解ip封裝而後交給TCP協議棧進行工做以此類推

 

一般通常而言不須要複製任何數據，性能很是不錯的，須要注意的是對於整個主機來說，不管是接收仍是發送，只要跟非本機進行交互都須要經過網卡設備向外發送或向內接收

 

那當一個來自web的報文到達網卡的時候，那接下來訪問哪一個服務咱們不得而知，可是咱們要對信號接收並進行處理的話，那麼首先須要將報文接收下來，並存放在內存空間中

而內存又分爲內核空間內核和用戶空間內存 ，因此當一段信號到達網卡的時候必須當即通知cpu進行處理，這個過程叫作中斷

所以一旦有中斷產生須要處理中斷有權限處理中斷的只有內核，所以在硬件級別只有內核纔有權限訪問

 

因此這個時候，一般狀況下，某一進程正在運行，網卡忽然接收到某一信號，因而網卡中斷CPU，進程切換出去，接下來執行內核中的代碼，將此代碼接下來並在內存中開闢一段空間將數據存放下來，若是數據量很大的話也就意味着在內核的內存中可能開闢多塊內存來存放這段數據，也就意味着CPU會被中斷N次，由此的話性能會很低

 

爲了不這種狀況，DMA機制產生了

 本文來自http://yijiu.blog.51cto.com  轉載需經博主本人許可，盜帖可恥！

DMA機制

cpu只須要開闢一段內存空間，因而接下來的全部控制都交給DMA芯片，由DMA控制整個總線，當複製數據到內存的過程結束了，因而DMA會通知cpu（內核）任務結束

 

中斷下的數據放進來了，可是可能未必會特別緊急，有可能cpu上正在執行其餘進程，好比內核正在執行刷寫內容到磁盤，也就意味着刷寫過程當中是不容許隨意切斷的

因此接進來的網絡報文有可能暫存幾毫秒，等待內核執行完其餘操做了然後立刻切換至當前任務中來，以完成操做給予響應

 

但無論怎麼說，只要將用戶的來源請求暫存到本地內存中就能夠處理了，若是在處理以前又來了不少請求，那麼會將其繼續暫存依次處理

當隊列被寫滿了，後續再來的請求則會丟棄，也就是咱們常說的拒絕服務

 

一樣道理，當咱們本機接收下來，經過本機拆ip 拆tcp 拆應用首部 等一系列操做，過後會發現這是某一對應的用戶空間的進程應用 好比web服務器，很顯然這個web服務器要關聯到這個套接字上，最終用戶就會根據這個套接字接口將數據從套接字發送至這個進程 

 

這個進程接收到請求後發現用戶所訪問的是某個靜態頁面，則會構建響應報文

可是須要注意幾個問題：

構建響應報文是否要發起本地磁盤IO

是否要裝載本地文件

是否裝載完成以後封裝成響應報文，然後發送給用戶，可是若是還有其餘往外發送的報文的話，則將其放到發送隊列中

 

發送隊列

簡單來說是內存空間，那麼網卡驅動程序會從這段內存空間裏首部依次將報文發送出去

而咱們內存也是優先的，而是否內存空間越大就意味着能緩存的請求越多

 

那麼網絡調優無非就是調整緩衝大小以及鏈接數，而網絡功能不只僅有tcp協議棧，還包括udp icmp等等

 

緩衝類別

若是不是tcp協議棧的話，那它仍然須要其餘緩衝區，所以咱們系統上緩衝對於linux分爲兩大類：

·核心緩衝

    爲全部協議提供的空間，若是沒有定義則使用這類空間，事實上，咱們能夠將tcp獨立出來，由於tcp比較獨特並且tcp有限狀態機制在多個狀態之間能夠進行轉換的，也就是tcp緩衝也被稱爲sock緩衝

·TCP緩衝（sock緩衝）

  若是將scok緩衝獨立出來的話，那麼核心緩衝只爲udp等其餘非tcp協議棧進行緩衝，那麼在某一文件中極可能是分開進行定義的 

 

當一個用戶請求到來，經過網卡將其鏈接進來，也就意味着在此之間須要進行三次握手

，鏈接進來以後這時候咱們的鏈接狀態爲established,在這個狀態中咱們進程正在構建響應報文，當這個報文構建完成以後則向這個鏈接進行響應了，發送過程當中屬於established，假如咱們使用的是非持久鏈接，當報文發送完以後，就表示須要斷開了，尤爲是在使用非持久鏈接必須是服務器端進行斷開，否則客戶端一直處於掛機狀態則會很麻煩。

 

在內核中，視爲系統一切皆文件，也就是說任何一個鏈接進來了實際上是經過文件句柄來保存，也就意味着內核必需要爲這個內核使用一個文件句柄，內核所打開的文件必須可以追蹤到這個文件

 

對於用戶來說在內核中可以持有的文件句柄數是有限的65536個

問題是咱們所生產的文件愈來愈多，並且這個文件並且實際上是tcp鏈接文件，而這個文件還要用於描述tcp的狀態的，正常狀況下正在發送傳輸數據的狀態就是established，傳完了雙方要四次斷開

 

斷開的某種可能性：好比傳輸完成假設等待客戶端進行斷開，客戶端須要發送了FIN請求，可是客戶端一直沒有發送，由服務器進行發送，服務器發送FIN至客戶端，客戶端接收到了信息，狀態從established轉爲FIN_WITE1等待對方的第一次對咱們關閉鏈接的請求，處於write1的時候 這個進程所包含的信息量也是很是大的。若是對方始終不回覆的話，咱們須要定義一個超時時間。

 

若是對方對咱們回覆響應，那麼除了等待對方的fin_wirte1以外還須要等待對方的響應確認報文達到以後立馬等待用戶進入fin報文，接下來等待第二次的fin_wirte的時候，這時咱們的狀態會處於fin_write2狀態

 

接收到對方第一個報文以後，馬上轉爲第二種等待狀態--fin_write2,當進入此狀態的時候，此時跟須要向對方確認的數據將會被清理出去

清理出去會，fin_write2大概會在1.5k信息量左右

 

若是對方遲遲不迴應其信息的話，那麼對於一個很是繁忙的服務器來說是不容許等待太長時間的，因而咱們有兩種方案：

1 超時，由於遲遲等不來也不能始終維持鏈接，從而再也不維護一個非有效的套接字句柄

2 快速回收，tcp time weite2鏈接重用，一旦接收到了對方第一次確認以後，裏面根據用戶相關的用戶協議都會被清出去，其裏面的敏感信息都會消失，由此咱們能夠將新的鏈接請求的數據填入到此文件句柄中從而歸類爲一個新的請求進行處理     

 

若是咱們沒有進行重用，而超時時間定義的很是長，結果會發生鏈接耗盡，同而會有大量的time_wite2的鏈接狀態，而新的鏈接再也進不來了

 

對網卡而言，必定是當一個報文到來的時候要中斷CPU，由內核接受請求在內存中應用保存的，因此內存須要一段空間，空間有多大須要自行去定義的，若是內存足夠大的話能夠定義大一點，因此內存空間越大就越意味着越可以及早的將請求接入到本地服務器中，只不過響應速度比較慢而已，至少拒絕服務***不會發生。

 

萬一隊列滿了，咱們還有補救措施

在系統上還有一個叫作cookie機制，其機制能夠將另外的內存空間補充進來

 

事實上在linux還有其餘的功能須要調整：

好比tcp創建會話是獨立的，二者之間創建鏈接後，發送報文的時候爲了更好的性能，將其批量發送，批量發送一次性發送多少取決於tcp的滑動窗口

 

 

批量發送

首先，發送方有發送方的緩衝，接收方有接收緩衝，中間還要有網線管道

至於取決於發送多大，而兩個相鄰比較近的主機之間能夠儘量調整窗口大小

對於tcp而言滑動窗口對發送/接收來說是一個很是重要的衡量手段（網絡性能調整機制）只不過一般在網絡調優中，這個功能咱們觸及到的很是少而已

 

以下圖所示：

咱們的報文真正在互聯網上傳送的時候，或者在tcp ip中傳送的時候

一切都是有sock_buff接收的

sock_buffer須要在某一個接收方的協議棧中自下而上的進行流水線處理

 

 

回顧：tcp的有限狀態

server默認狀態爲listen 

當client開始發送請求的時候狀態爲syn_sent ,因而將狀態從close轉爲sync

對方接收到syn報文之後就從listen狀態轉爲syn_recv，併發送sync_ack 並確認對方的請求 ，一直等待對方接收

對方接收下來，發送syn+ack 從其轉爲established ，而服務器收到ack 從而也轉爲established

 

四次斷開就略過不談了，具體請看 http://yijiu.blog.51cto.com/433846/1356254

 

查看當前網絡打開的套接字情況

使用netstat查看

[root@node2~]# netstat -tunlp

ActiveInternet connections (only servers)

ProtoRecv-Q Send-Q Local Address               Foreign Address             State       PID/Program name  

tcp        0     0 0.0.0.0:80                 0.0.0.0:*                   LISTEN      4733/nginx         

tcp        0     0 0.0.0.0:22                 0.0.0.0:*                   LISTEN     1092/sshd          

tcp        0     0 127.0.0.1:6010             0.0.0.0:*                   LISTEN      9707/sshd          

tcp        0     0 :::22                      :::*                        LISTEN      1092/sshd          

tcp        0     0 ::1:6010                   :::*                        LISTEN      9707/sshd          

tcp        0     0 :::3306                    :::*                        LISTEN      11572/mysqld 

 

查看當前處於活動狀態的套接字

[root@node3 ~]# sar -n SOCK

#SOCK是關鍵字，不用改

[root@localhost~]# sar -n SOCK 1 3

Linux2.6.32-358.2.1.el6.x86_64 (localhost)     09/29/2014_x86_64_    (4CPU)

 

03:21:01PM    totsck    tcpsck   udpsck    rawsck   ip-frag   tcp-tw

03:21:02PM       455       166         4         1         0        78

03:21:03PM       459       166         4         1         0        77

03:21:04PM       460       168         4         1         0        70

Average:          458       167         4         1         0        75

參數解釋：

#totsck    系統持有的socket個數

#tcpsck   當前正在處於使用中的tcp socket文件個數

#udpsck   當前正在處於使用中的udp socket文件個數

#rawsck   raw套接字個數，raw能夠理解爲數據流，沒法歸類tcp/udp

#ip-frage  當前正在使用的ip分片個數

#tcp-tw   處於tw狀態的tcp套接字個數

 

sar還能夠顯示根據IP相關的信息

[root@localhost~]# sar -n IP 1 3

Linux2.6.32-358.2.1.el6.x86_64 (localhost)     09/29/2014_x86_64_    (4CPU)

 

03:22:41PM    irec/s  fwddgm/s   idel/s     orq/s   asmrq/s  asmok/s  fragok/s fragcrt/s

03:22:42PM    126.00      0.00   124.00    123.00      0.00     0.00      0.00      0.00

03:22:43PM     69.70      0.00    69.70     63.64      0.00     0.00      0.00      0.00

03:22:44PM     98.02      0.00    98.02    176.24      0.00     0.00      0.00      0.00

Average:        98.00      0.00    97.33    121.33      0.00     0.00      0.00      0.00

 本文來自http://yijiu.blog.51cto.com  轉載需經博主本人許可，盜帖可恥！

lsof 查看打開的文件

lsof -l   #顯示關聯當前用戶上全部的文件

 

咱們當前是root用戶，root用戶可能大多數進程都是以其進程運行，因此這些進程打開的文件都關聯到一個用戶上去了

若是咱們想查看某個pid打開的文件的話，以下所示：

[root@localhost~]# lsof -i :80

COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME

squid   30197 squid  13u  IPv6 136216148      0t0 TCP 172.23.215.252:http->172.23.200.148:prat (ESTABLISHED)

squid   30197 squid  14u  IPv6 136164788      0t0 TCP *:http (LISTEN)

squid   30197 squid  15u  IPv6 136164801      0t0 TCP 172.23.215.72:http->172.23.200.154:53616 (ESTABLISHED)

squid   30197 squid  16u  IPv6 136208979      0t0 TCP 172.23.215.251:http->172.23.200.34:ufastro-instr (ESTABLISHED)

squid   30197 squid  18u  IPv4 136216350      0t0 TCP 172.23.215.72:58292->108.126.126.124.broad.bjtelecom.net:http(ESTABLISHED)

squid   30197 squid  19u  IPv6 136214917      0t0 TCP 172.23.215.251:http->172.23.214.43:saphostctrl (ESTABLISHED)

squid   30197 squid  20u  IPv6 136204102      0t0 TCP 172.23.215.252:http->172.23.200.31:epl-slp (ESTABLISHED)

squid   30197 squid  21u  IPv4 136217076      0t0 TCP 172.23.215.72:56237->203.208.37.25:http (ESTABLISHED)

squid   30197 squid  23u  IPv6 136212725      0t0 TCP 172.23.215.72:http->172.23.215.60:menandmice-dns (ESTABLISHED)

squid   30197 squid   26u IPv6 136208054      0t0  TCP172.23.215.251:http->172.23.200.109:ndl-tcp-ois-gw (ESTABLISHED)

squid   30197 squid  36u  IPv6 136207570      0t0 TCP 172.23.215.251:http->172.23.200.109:inova-ip-disco (ESTABLISHED)

squid   30197 squid  37u  IPv6 136216808      0t0 TCP 172.23.215.251:http->172.23.201.71:fc-faultnotify (ESTABLISHED)

squid   30197 squid  38u  IPv6 136216906      0t0 TCP 172.23.215.251:http->172.23.200.42:tappi-boxnet (ESTABLISHED)

squid   30197 squid  39u  IPv6 136203186      0t0 TCP 172.23.215.251:http->172.23.201.44:adrep (ESTABLISHED)

以上是80端口打開的全部文件，很顯然，若是全部的繁忙的web服務器使用此命令查看，可能會顯示的很是多，除了LISTEN狀態的，其餘的都表示當前狀態處於打開狀態的TCP web服務的會話數

 

lsof -i的格式：

lsof -i[46][protocol][@hostname|hostaddr][:service|port]
     46：IPv4或IPv6
     protocol：TCP or UDP
     hostname：Internet host name
     hostaddr：IPv4地址
     service：/etc/service中的服務名稱(能夠不僅一個)
     port：端口號 (能夠不僅一個)

 

例：

查看22端口如今運行的狀況

[root@localhost~]# lsof -i :22

COMMAND   PID USER  FD   TYPE    DEVICE SIZE/OFF NODE NAME

sshd     1291 root    3u IPv4      9070      0t0 TCP *:ssh (LISTEN)

sshd     1291 root    4u IPv6      9072      0t0 TCP *:ssh (LISTEN)

sshd     5516 root    3r IPv4 133312373      0t0  TCP 172.23.215.72:ssh->172.23.214.52:10827(ESTABLISHED)

sshd    30520 root    3r IPv4 136203961      0t0  TCP 172.23.215.72:ssh->172.23.215.1:61817(ESTABLISHED)

查看22端口打開狀況，咱們當前的 172.23.215.1:60536鏈接到node3.test.com 主機上來，狀態是established

 

 

查看某個用戶所打開的文件

[root@localhost~]#  lsof -u squid | more

COMMAND   PID USER   FD   TYPE             DEVICE  SIZE/OFF     NODE NAME

squid   30197 squid  cwd   DIR              252,3      4096  2752513 /root

squid   30197 squid rtd    DIR              252,3      4096         2 /

squid   30197 squid txt    REG              252,3  32944005  2102844 /usr/local/squid-3.3.12/sbin/squid

squid   30197 squid  mem   REG              252,3     22536  2883586 /lib64/libdl-2.12.so

squid   30197 squid mem    REG              252,3     43392  2883591 /lib64/libcrypt-2.12.so

squid   30197 squid mem    REG              252,3    386040  2883590 /lib64/libfreebl3.so

squid   30197 squid mem    REG              252,3    124624  2883606 /lib64/libselinux.so.1

squid   30197 squid mem    REG              252,3    944712  2883654 /lib64/libkrb5.so.3.3

##########略過##############

 

能夠看到，運行squid服務的用戶名爲squid，因此咱們可能尚未被用戶監控就已經打開不少文件了，更況且一旦打開不少網絡套接字文件讓網絡用戶創建鏈接可能須要打開的鏈接會更多

因此未來若是創建高併發服務器的時候首先要調整運行服務的運行用戶的文件描述符

 

netstat -tu  當前處於活動狀態的鏈接

[root@localhost~]# netstat  -tun | wc -l

515

能夠看到有515個鏈接，爲了看起來方便，咱們以鏈接數統計各個狀態

[root@localhost~]# netstat  -tun | awk '/^tcp/{stat[$NF]++}END{for(S in stat) print S,stat[S]}'

TIME_WAIT87

FIN_WAIT11

SYN_SENT1

FIN_WAIT210

ESTABLISHED549

CLOSING1

另外ss -tuan 會比netstat更快，根據習慣來選擇

 

不少時候只是觀測某一服務的值，好比咱們只想看80端口相關的值

，只須要抓取80端口相關狀態便可，所以根據本身須要靈活變化命令以實現需求

 

 

使用dstat查看哪一個進程佔用IO量最大

[root@node3~]# dstat -top-io

查看哪一個進程佔用cpu最多

[root@localhost~]# dstat -d -r --top-io

-dsk/total---io/total- ----most-expensive----

 read writ| read  writ|     i/o process     

9121B  148k|0.95 4.59 |init         96k  143k

   0    0 |   0     0 |stunnel     427k 424k

   0 8192B|   0  2.00 |(squid-1)    93k 135k

   0  168k|   0  8.00 |(squid-1)  1185k 1241k

   0  968k|   0  24.0 |(squid-1)   398k 489k

8192B  392k|2.00 92.0 |(squid-1)   175k  253k

   0    0 |   0     0 |(squid-1)   668k 875k

  56k   0 |12.0     0 |(squid-1)   429k 567k

   0  240k|   0  12.0 |(squid-1)   116k 244k

 

 本文來自http://yijiu.blog.51cto.com  轉載需經博主本人許可，盜帖可恥！

網絡參數優化

net.ipv4.tcp_max_tw_buckets
time_wait的數量，默認爲8192；

若是默認8192若是咱們有其值以上的鏈接數則會被請出去，通常來說尤爲是time wite2狀態清理或重用都是沒有問題的。

 

net.ipv4.ip_local_port_range = 1024 65000
容許系統打開的端口範圍，前而爲下限，後面的數字爲上限；默認爲「32768 到 61000」；

對於繁忙的服務器或高併發web服務器很明顯是不夠用的，假如使用nginx等作反向代理，這個範圍儘量調大，這裏咱們調整爲 1024 到 65000，只要是沒有人用的則直接拿來去用

注意：此可用範圍決定了最後time_wait狀態的鏈接的數量；也就意味着處於time_wite狀態鏈接都於各類情況沒有斷開而不少都處於time wite狀態，那麼這個量會很高，但不管多高也不能高出net.ipv4.ip_local_port_range = 1024 65000 的差值的

若是time_wite狀態的鏈接數達到了這個區間的全部最大值，結果意味着新的鏈接已經鏈接不進來，全部的time_wite都被佔據，全部的新連接均可能被拒絕鏈接了

不管是time wite仍是其餘狀態，全部的鏈接數字都不能超過這個差值的，因此tw的狀態越少，那麼咱們正常鏈接的就越多

 本文來自http://yijiu.blog.51cto.com  轉載需經博主本人許可，盜帖可恥！

下面的兩項可有效下降tw狀態鏈接的數量，以下所示：

 

下降tw狀態鏈接的數量：

net.ipv4.tcp_tw_recycle = {0|1}  

#快速回收並重用
是否啓用timewait快速回收；很顯然在一個很是繁忙的服務器是必需要快速回收的，可是要啓用這個功能的話，在LVS的NAT環境下可能會出現嚴重的問題：

開啓此功能在NAT環境下可能會出現嚴重的問題：由於TCP有一種行爲，它能夠緩存每一個鏈接最新的時間戳，後續請求中若是時間戳小於緩存中的時間戳，即被視爲無效並丟棄相應的請求報文；不少時候服務端和服務器端的時間可能會不一致，因此當一個用戶請求鏈接進來了爲其分發至一臺服務器上，而且啓動了快速重用，意味着前面的用戶斷開了而後又來了個用戶重用了這個鏈接，重用以後往外發送的時候會遇到一個問題：

·爲了實現鏈接重用，而這個鏈接重用的報文跟前面仍是同一個連接，因而被當前系統識別爲當前用戶的鏈接是同一個，由於咱們容許了重用而重用發現後面的鏈接的時間戳的系統時間與咱們當前系統時間不一致，那致使時間戳不一致，由於請求的時間戳可能小於緩存的時間戳。好比咱們緩存3：30:50 的時間戳 ，而過來的請求時間3:30:58

慢了幾秒，它就認爲這個時間已經被請求過了，因此這種請求就會被丟棄，所以在這種狀況下可能大量的用戶請求出現異常行爲，都是處於time out等 各類狀況，這在nat模型下的ipvs框架是極爲常見的，若是請求tcp_tw_recycle的話Linux是否啓用這種行爲取決於tcp_timestamp和tcp_tw_recycle，而前一個參數默認是啓用的，因此啓用後面的參數就會激活此功能；所以，若是是基於LVS的NAT環境，安全起見，應該禁用tcp_tw_recycle。

 

另外一種解決方案：把tcp_timestamps設置爲0，tcp_tw_recycle設置爲1並不會如想象中奏效，由於一旦關閉了tcp_timestamps，那麼即使打開了tcp_tw_recycle，後面的參數也沒有效果。此時下降net.ipv4.tcp_max_tw_buckets的值就能夠顯著下降tw鏈接的數量了。可是仍然不能避免問題

#回收不表明重用，重用還須要取決於tw_reuse

 

 

net.ipv4.tcp_timestamps= 0
tcp報文時間戳，關閉時能夠避免序列號的卷繞，如上所述；

net.ipv4.tcp_syncookies = {0|1}
是否開啓SYN Cookies，即當SYN等待隊列溢出時，是否啓用cookies功能；
用戶的請求到達後，會被列入到請求隊列中，而隊列滿了以後再有信的請求進來則被拒絕服務，爲了不此種狀況，咱們會在另外一內存段中開闢一段內存--被稱爲後背隊列

sync cookies 通常都是啓用的，只要內存足夠大將timestamps調大便可

 

 

net.ipv4.tcp_max_syn_backlog = 262144
保存的那些還沒有收到客戶端確認信息的鏈接請求的最大值；默認爲128，可增大此值；

#在等待最後發送ack的時候容許多少個等待，前提是有足夠內存

#加大有助於爲更多鏈接提供相應的

 

 本文來自http://yijiu.blog.51cto.com  轉載需經博主本人許可，盜帖可恥！

net.ipv4.tcp_synack_retries = #
爲了打開對端的鏈接，內核須要發送一個SYN並附帶一個迴應前面一個SYN的ACK，這也即所謂的三次握手中的第二次；這個設置決定了內核放棄鏈接以前發送SYN+ACK 包的數量；繁忙的服務器上建議設置爲0或者1；0表示只要最多回應一次，若是不迴應則斷開鏈接

 本文來自http://yijiu.blog.51cto.com  轉載需經博主本人許可，盜帖可恥！

 

net.ipv4.tcp_syn_retries = #
在內核放棄創建鏈接以前發送SYN包的數量；

#tcp握手的第一次，重啓幾回

繁忙的服務器上建議設置爲0或者1；

 

 

net.ipv4.tcp_max_orphans = 262144
系統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上；若是超過這個數字，孤兒鏈接將即刻被複位並打印出警告信息；
這個限制僅僅是爲了防止簡單的DoS ***，不能過度依靠它或者人爲地減少這個值，若是須要修改，在確保有足夠內存可用的前提下，應該增大此值；

#這個數值越大越好，越大對於抗***能力越強

 

net.ipv4.tcp_fin_timeout = 5
若是套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間；缺省值是60秒。
然而，對端可能會出錯或意外宕機並永遠不關閉鏈接。即便你的機器是一個輕載的WEB 服務器，也有由於大量的死套接字而內存溢出的風險，FIN-WAIT-2 的危險性比FIN-WAIT-1要小，由於每一個鏈接最多隻能消耗1.5K內存，可是它們的生存期長些；

#假如說沒有打開套接字的重用，那就意味着若是發送fin報文並等待對方相應，對方相應了又等待對方的fin 這時對方不發fin了，這種處於fin的鏈接數最多能夠設置爲多長時間，若是超時，則斷開，60秒太長，能夠將其設置爲5

 

net.ipv4.tcp_keepalive_time = 30
當keepalive起用的時候，TCP發送keepalive消息的頻度，默認是是2小時；

#長鏈接，若是沒有fin的斷開的話則一直處於長鏈接狀態

#默認是7200秒，當時間已到會嘗試着從新創建鏈接，若是能從新創建成功則繼續，若是不成功則重試，若是重試幾回都失敗了則斷開鏈接，固然鏈接數有點長，可是不建議更改，由於跟tcp協議相關，而更改了之後可能不符合規定，可能會出現異常，固然能夠嘗試

 本文來自http://yijiu.blog.51cto.com  轉載需經博主本人許可，盜帖可恥！

關於內存參數調優

咱們說過對於網絡協議棧來說，有接收緩衝 發送緩衝等，參數就是爲了調整網絡功能的內存大小的

 

net.core.rmem_max=8388608
定義內核用於全部類型的鏈接的最大接收緩衝大小；

#核心緩衝接收緩衝的最大值。最大值表示若是須要的話從默認值增加到最大值，萬一內存不夠用了，就再也不分配。

net.core.rmem_default=65536
定義內核用於全部類型的鏈接的默認接收緩衝大小；
#核心緩衝接收緩衝的默認值，至少要保證的值，就是最大打開的文件描述符，不用解釋了吧

net.core.wmem_max=8388608
定義內核用於全部類型的鏈接的最大發送緩衝大小；

net.core.wmem_default=65536
定義內核用於全部類型的鏈接的默認發送緩衝大小；

 

以上兩點，需自行設定

 

調整tcp緩衝

 

net.ipv4.tcp_mem='8388608 83886088388608' 

定義TCP協議棧使用的內存空間；分別爲最小值，默認值和最大值；#既接收有發送

net.ipv4.tcp_rmem='4096 87380 8388608'
定義TCP協議棧用於接收緩衝的內存空間；

第一個值爲最小值，即使當前主機內存空間吃緊，也得保證tcp協議棧至少有此大小的空間可用；

第二個值爲默認值，它會覆蓋net.core.rmem_default中爲全部協議定義的接收緩衝的大小；

第三值爲最大值，即能用於tcp接收緩衝的最大內存空間；

net.ipv4.tcp_wmem='4096 65536 8388608'

定義TCP協議棧用於發送緩衝的內存空間；

 

做爲服務器來說，響應的報文數要大，咱們在發送以前用戶的請求數可能比響應數要大因此並不意味着發送方大於接收數，由於接收進來的或響應用戶的請求量可能會很是大，反而接收進來的內存會更大一點，雖然接收進來的請求沒有數據，這就是爲何咱們在如下參數tcp_rmem 設置爲默認8萬多 而tcp_wmem 爲6萬多的緣由

本文來自http://yijiu.blog.51cto.com  轉載需經博主本人許可，盜帖可恥！

 

付：如下爲國內著名電商某服務器的內核優化參數：

#Controls the default maxmimum size of a mesage queue
kernel.msgmnb = 65536

# Controls the maximum size of a message, in bytes
kernel.msgmax = 65536

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
net.core.somaxconn = 32768
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 0
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.ip_local_port_range = 1024  65535
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 100
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 20000

 

本文來自http://yijiu.blog.51cto.com  轉載需經博主本人許可，盜帖可恥！