目錄html
1、linux內核參數註釋linux
2、兩種修改內核參數方法nginx
3、內核優化參數生產配置web
參數解釋由網絡上收集整理,經常使用優化參數對比了網上多個實際應用進行表格化整理,使查看更直觀。算法
學習linux也有很多時間了,每次優化linux內核參數時,都是在網上拷貝而使用,甚至別人沒有列出來的參數就無論了,難道我就不須要了嗎?apache
參考文章:緩存
linux內核TCP相關參數解釋服務器
http://os.chinaunix.net/a2008/0918/985/000000985483.shtmlcookie
linux內核參數優化網絡
http://blog.chinaunix.net/uid-29081804-id-3830203.html
linux內核調整和內核參數詳解
http://blog.csdn.net/cnbird2008/article/details/4419354
如下表格中紅色字體爲經常使用優化參數
根據參數文件所處目錄不一樣而進行分表整理
下列文件所在目錄:/proc/sys/net/ipv4/
名稱 |
默認值 |
建議值 |
描述 |
tcp_syn_retries |
5 |
1 |
對於一個新建鏈接,內核要發送多少個 SYN 鏈接請求才決定放棄。不該該大於255,默認值是5,對應於180秒左右時間。。(對於大負載而物理通訊良好的網絡而言,這個值偏高,可修改成2.這個值僅僅是針對對外的鏈接,對進來的鏈接,是由tcp_retries1決定的) |
tcp_synack_retries |
5 |
1 |
對於遠端的鏈接請求SYN,內核會發送SYN + ACK數據報,以確認收到上一個 SYN鏈接請求包。這是所謂的三次握手( threeway handshake)機制的第二個步驟。這裏決定內核在放棄鏈接以前所送出的 SYN+ACK 數目。不該該大於255,默認值是5,對應於180秒左右時間。 |
tcp_keepalive_time |
7200 |
600 |
TCP發送keepalive探測消息的間隔時間(秒),用於確認TCP鏈接是否有效。 防止兩邊創建鏈接但不發送數據的攻擊。 |
tcp_keepalive_probes |
9 |
3 |
TCP發送keepalive探測消息的間隔時間(秒),用於確認TCP鏈接是否有效。 |
tcp_keepalive_intvl |
75 |
15 |
探測消息未得到響應時,重發該消息的間隔時間(秒)。默認值爲75秒。 (對於普通應用來講,這個值有一些偏大,能夠根據須要改小.特別是web類服務器須要改小該值,15是個比較合適的值) |
tcp_retries1 |
3 |
3 |
放棄迴應一個TCP鏈接請求前﹐須要進行多少次重試。RFC 規定最低的數值是3 |
tcp_retries2 |
15 |
5 |
在丟棄激活(已創建通信情況)的TCP鏈接以前﹐須要進行多少次重試。默認值爲15,根據RTO的值來決定,至關於13-30分鐘(RFC1122規定,必須大於100秒).(這個值根據目前的網絡設置,能夠適當地改小,個人網絡內修改成了5) |
tcp_orphan_retries |
7 |
3 |
在近端丟棄TCP鏈接以前﹐要進行多少次重試。默認值是7個﹐至關於 50秒 - 16分鐘﹐視 RTO 而定。若是您的系統是負載很大的web服務器﹐那麼也許須要下降該值﹐這類 sockets 可能會耗費大量的資源。另外參的考tcp_max_orphans。(事實上作NAT的時候,下降該值也是好處顯著的,我本人的網絡環境中下降該值爲3) |
tcp_fin_timeout |
60 |
2 |
對於本端斷開的socket鏈接,TCP保持在FIN-WAIT-2狀態的時間。對方可能會斷開鏈接或一直不結束鏈接或不可預料的進程死亡。默認值爲 60 秒。 |
tcp_max_tw_buckets |
180000 |
36000 |
系統在同時所處理的最大 timewait sockets 數目。若是超過此數的話﹐time-wait socket 會被當即砍除而且顯示警告信息。之因此要設定這個限制﹐純粹爲了抵禦那些簡單的 DoS 攻擊﹐不過﹐若是網絡條件須要比默認值更多﹐則能夠提升它(或許還要增長內存)。(事實上作NAT的時候最好能夠適當地增長該值) |
tcp_tw_recycle |
0 |
1 |
打開快速 TIME-WAIT sockets 回收。除非獲得技術專家的建議或要求﹐請不要隨意修改這個值。(作NAT的時候,建議打開它) |
tcp_tw_reuse |
0 |
1 |
表示是否容許從新應用處於TIME-WAIT狀態的socket用於新的TCP鏈接(這個對快速重啓動某些服務,而啓動後提示端口已經被使用的情形很是有幫助) |
tcp_max_orphans |
8192 |
32768 |
系統所能處理不屬於任何進程的TCP sockets最大數量。假如超過這個數量﹐那麼不屬於任何進程的鏈接會被當即reset,並同時顯示警告信息。之因此要設定這個限制﹐純粹爲了抵禦那些簡單的 DoS 攻擊﹐千萬不要依賴這個或是人爲的下降這個限制。若是內存大更應該增長這個值。(這個值Redhat AS版本中設置爲32768,可是不少防火牆修改的時候,建議該值修改成2000) |
tcp_abort_on_overflow |
0 |
0 |
當守護進程太忙而不能接受新的鏈接,就象對方發送reset消息,默認值是false。這意味着當溢出的緣由是由於一個偶然的猝發,那麼鏈接將恢復狀態。只有在你確信守護進程真的不能完成鏈接請求時纔打開該選項,該選項會影響客戶的使用。(對待已經滿載的sendmail,apache這類服務的時候,這個能夠很快讓客戶端終止鏈接,能夠給予服務程序處理已有鏈接的緩衝機會,因此不少防火牆上推薦打開它) |
tcp_syncookies |
0 |
1 |
只有在內核編譯時選擇了CONFIG_SYNCOOKIES時纔會發生做用。當出現syn等候隊列出現溢出時象對方發送syncookies。目的是爲了防止syn flood攻擊。 |
tcp_stdurg |
0 |
0 |
使用 TCP urg pointer 字段中的主機請求解釋功能。大部份的主機都使用老舊的 BSD解釋,所以若是您在 Linux 打開它﹐或會致使不能和它們正確溝通。 |
tcp_max_syn_backlog |
1024 |
16384 |
對於那些依然還未得到客戶端確認的鏈接請求﹐須要保存在隊列中最大數目。對於超過 128Mb 內存的系統﹐默認值是 1024 ﹐低於 128Mb 的則爲 128。若是服務器常常出現過載﹐能夠嘗試增長這個數字。警告﹗假如您將此值設爲大於 1024﹐最好修改include/net/tcp.h裏面的TCP_SYNQ_HSIZE﹐以保持TCP_SYNQ_HSIZE*16(SYN Flood攻擊利用TCP協議散佈握手的缺陷,僞造虛假源IP地址發送大量TCP-SYN半打開鏈接到目標系統,最終致使目標系統Socket隊列資源耗盡而沒法接受新的鏈接。爲了應付這種攻擊,現代Unix系統中廣泛採用多鏈接隊列處理的方式來緩衝(而不是解決)這種攻擊,是用一個基本隊列處理正常的徹底鏈接應用(Connect()和Accept() ),是用另外一個隊列單獨存放半打開鏈接。這種雙隊列處理方式和其餘一些系統內核措施(例如Syn-Cookies/Caches)聯合應用時,可以比較有效的緩解小規模的SYN Flood攻擊(事實證實) |
tcp_window_scaling |
1 |
1 |
該文件表示設置tcp/ip會話的滑動窗口大小是否可變。參數值爲布爾值,爲1時表示可變,爲0時表示不可變。tcp/ip一般使用的窗口最大可達到 65535 字節,對於高速網絡,該值可能過小,這時候若是啓用了該功能,可使tcp/ip滑動窗口大小增大數個數量級,從而提升數據傳輸的能力(RFC 1323)。(對普通地百M網絡而言,關閉會下降開銷,因此若是不是高速網絡,能夠考慮設置爲0) |
tcp_timestamps |
1 |
1 |
Timestamps 用在其它一些東西中﹐能夠防範那些僞造的 sequence 號碼。一條1G的寬帶線路或許會重遇到帶 out-of-line數值的舊sequence 號碼(假如它是因爲上次產生的)。Timestamp 會讓它知道這是個 '舊封包'。(該文件表示是否啓用以一種比超時重發更精確的方法(RFC 1323)來啓用對 RTT 的計算;爲了實現更好的性能應該啓用這個選項。) |
tcp_sack |
1 |
1 |
使用 Selective ACK﹐它能夠用來查找特定的遺失的數據報--- 所以有助於快速恢復狀態。該文件表示是否啓用有選擇的應答(Selective Acknowledgment),這能夠經過有選擇地應答亂序接收到的報文來提升性能(這樣可讓發送者只發送丟失的報文段)。(對於廣域網通訊來講這個選項應該啓用,可是這會增長對 CPU 的佔用。) |
tcp_fack |
1 |
1 |
打開FACK擁塞避免和快速重傳功能。(注意,當tcp_sack設置爲0的時候,這個值即便設置爲1也無效)[這個是TCP鏈接靠譜的核心功能] |
tcp_dsack |
1 |
1 |
容許TCP發送"兩個徹底相同"的SACK。 |
tcp_ecn |
0 |
0 |
TCP的直接擁塞通告功能。 |
tcp_reordering |
3 |
6 |
TCP流中重排序的數據報最大數量。 (通常有看到推薦把這個數值略微調整大一些,好比5) |
tcp_retrans_collapse |
1 |
0 |
對於某些有bug的打印機提供針對其bug的兼容性。(通常不須要這個支持,能夠關閉它) |
tcp_wmem:mindefaultmax |
4096 16384 131072 |
8192 131072 16777216 |
發送緩存設置 min:爲TCP socket預留用於發送緩衝的內存最小值。每一個tcp socket均可以在建議之後均可以使用它。默認值爲4096(4K)。 default:爲TCP socket預留用於發送緩衝的內存數量,默認狀況下該值會影響其它協議使用的net.core.wmem_default 值,通常要低於net.core.wmem_default的值。默認值爲16384(16K)。 max: 用 於TCP socket發送緩衝的內存最大值。該值不會影響net.core.wmem_max,"靜態"選擇參數SO_SNDBUF則不受該值影響。默認值爲 131072(128K)。(對於服務器而言,增長這個參數的值對於發送數據頗有幫助,在個人網絡環境中,修改成了51200 131072 204800) |
tcp_rmem:mindefaultmax |
4096 87380 174760 |
32768 131072 16777216 |
接收緩存設置 同tcp_wmem |
tcp_mem:mindefaultmax |
根據內存計算 |
786432 1048576 1572864 |
low: 當TCP使用了低於該值的內存頁面數時,TCP不會考慮釋放內存。即低於此值沒有內存壓力。(理想狀況下,這個值應與指定給 tcp_wmem 的第 2 個值相匹配 - 這第 2 個值代表,最大頁面大小乘以最大併發請求數除以頁大小 (131072 * 300 / 4096)。 ) pressure: 當TCP使用了超過該值的內存頁面數量時,TCP試圖穩定其內存使用,進入pressure模式,當內存消耗低於low值時則退出pressure狀態。 (理想狀況下這個值應該是 TCP 可使用的總緩衝區大小的最大值 (204800 * 300 / 4096)。 ) high: 容許全部tcp sockets用於排隊緩衝數據報的頁面量。(若是超過這個值,TCP 鏈接將被拒絕,這就是爲何不要令其過於保守 (512000 * 300 / 4096) 的緣由了。 在這種狀況下,提供的價值很大,它能處理不少鏈接,是所預期的 2.5 倍;或者使現有鏈接可以傳輸 2.5 倍的數據。 個人網絡裏爲192000 300000 732000) 通常狀況下這些值是在系統啓動時根據系統內存數量計算獲得的。 |
tcp_app_win |
31 |
31 |
保留max(window/2^tcp_app_win, mss)數量的窗口因爲應用緩衝。當爲0時表示不須要緩衝。 |
tcp_adv_win_scale |
2 |
2 |
計算緩衝開銷bytes/2^tcp_adv_win_scale(若是tcp_adv_win_scale > 0)或者bytes-bytes/2^(-tcp_adv_win_scale)(若是tcp_adv_win_scale BOOLEAN>0) |
tcp_low_latency |
0 |
0 |
容許 TCP/IP 棧適應在高吞吐量狀況下低延時的狀況;這個選項通常情形是的禁用。(但在構建Beowulf 集羣的時候,打開它頗有幫助) |
tcp_westwood |
0 |
0 |
啓用發送者端的擁塞控制算法,它能夠維護對吞吐量的評估,並試圖對帶寬的總體利用狀況進行優化;對於 WAN 通訊來講應該啓用這個選項。 |
tcp_bic |
0 |
0 |
爲快速長距離網絡啓用 Binary Increase Congestion;這樣能夠更好地利用以 GB 速度進行操做的連接;對於 WAN 通訊應該啓用這個選項。 |
ip_forward |
0 |
- |
NAT必須開啓IP轉發支持,把該值寫1 |
ip_local_port_range:minmax |
32768 61000 |
1024 65000 |
表示用於向外鏈接的端口範圍,默認比較小,這個範圍一樣會間接用於NAT表規模。 |
65535 |
65535 |
系統支持的最大ipv4鏈接數,默認65536(事實上這也是理論最大值),同時這個值和你的內存大小有關,若是內存128M,這個值最大8192,1G以上內存這個值都是默認65536 |
所處目錄/proc/sys/net/ipv4/netfilter/
文件須要打開防火牆纔會存在
名稱 |
默認值 |
建議值 |
描述 |
ip_conntrack_max |
65536 |
65536 |
系統支持的最大ipv4鏈接數,默認65536(事實上這也是理論最大值),同時這個值和你的內存大小有關,若是內存128M,這個值最大8192,1G以上內存這個值都是默認65536,這個值受/proc/sys/net/ipv4/ip_conntrack_max限制
|
432000 |
180 |
已創建的tcp鏈接的超時時間,默認432000,也就是5天。影響:這個值過大將致使一些可能已經不用的鏈接常駐於內存中,佔用大量連接資源,從而可能致使NAT ip_conntrack: table full的問題。建議:對於NAT負載相對本機的 NAT表大小很緊張的時候,可能須要考慮縮小這個值,以儘早清除鏈接,保證有可用的鏈接資源;若是不緊張,沒必要修改 |
|
120 |
120 |
time_wait狀態超時時間,超過該時間就清除該鏈接 |
|
ip_conntrack_tcp_timeout_close_wait |
60 |
60 |
close_wait狀態超時時間,超過該時間就清除該鏈接 |
ip_conntrack_tcp_timeout_fin_wait |
120 |
120 |
fin_wait狀態超時時間,超過該時間就清除該鏈接 |
文件所處目錄/proc/sys/net/core/
名稱 |
默認值 |
建議值 |
描述 |
|
1024 |
16384 |
每一個網絡接口接收數據包的速率比內核處理這些包的速率快時,容許送到隊列的數據包的最大數目,對重負載服務器而言,該值須要調高一點。 |
somaxconn
|
128 |
16384 |
用來限制監聽(LISTEN)隊列最大數據包的數量,超過這個數量就會致使連接超時或者觸發重傳機制。 web應用中listen函數的backlog默認會給咱們內核參數的net.core.somaxconn限制到128,而nginx定義的NGX_LISTEN_BACKLOG默認爲511,因此有必要調整這個值。對繁忙的服務器,增長該值有助於網絡性能 |
|
129024 |
129024 |
默認的發送窗口大小(以字節爲單位) |
rmem_default
|
129024 |
129024 |
默認的接收窗口大小(以字節爲單位) |
|
129024 |
873200 |
最大的TCP數據接收緩衝 |
wmem_max |
129024 |
873200 |
最大的TCP數據發送緩衝 |
1、使用echo value方式直接追加到文件裏如echo "1" >/proc/sys/net/ipv4/tcp_syn_retries,但這種方法設備重啓後又會恢復爲默認值
2、把參數添加到/etc/sysctl.conf中,而後執行sysctl -p使參數生效,永久生效
這兒所列參數是老男孩老師生產中經常使用的參數:
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl =15
net.ipv4.tcp_retries2 = 5
net.ipv4.tcp_fin_timeout = 2
net.ipv4.tcp_max_tw_buckets = 36000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_orphans = 32768
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_wmem = 8192 131072 16777216
net.ipv4.tcp_rmem = 32768 131072 16777216
net.ipv4.tcp_mem = 786432 1048576 1572864
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.ip_conntrack_max = 65536
net.ipv4.netfilter.ip_conntrack_max=65536
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=180
net.core.somaxconn = 16384
net.core.netdev_max_backlog = 16384
對比網上其餘人的生產環境優化參數,須要優化的參數基本差很少,只是值有相應的變化。具體優化值要參考應用場景,這兒所列只是經常使用優化參數,是否適合,可在上面查看該參數描述,理解後,再根據本身生產環境而設。
其它相關linux內核參數調整文章:
Linux內核參數優化
http://flandycheng.blog.51cto.com/855176/476769
優化linux的內核參數來提升服務器併發處理能力
nginx作web服務器linux內核參數優化