linux常見內核參數的修改

---

1、修改方法（三種）
先說一下sysctl用法：
sysctl -a 打印全部支持修改的內核參數；
sysctl -p 使得寫入/etc/sysctl.conf的內核參數生效；
sysctl +須要修改的參數 設置內核參數；
1,（臨時修改）直接用echo的方式修改/proc/sys/文件系統，例如：
echo 5> /proc/sys/net/ipv4/tcp_retries2
2,（臨時修改）用sysctl命令，例如：
sysctl net.ipv4.tcp_retries2=5
3,（持久化修改）修改/etc/sysctl.conf文件，例如：
echo "net.ipv4.tcp_retries2=5">> /etc/sysctl.conf

2、經常使用內核參數

net.ipv4.tcpfintimeout
#修改timewait狀的存在時間，默認的2MSL
注意：timewait存在且生存時間爲2MSL是有緣由的，見我上一篇博客爲何會有timewait狀態的存在，因此修改它有必定的風險，仍是根據具體的狀況來分析。

net.ipv4.tcpretries1
#放棄迴應一個TCP鏈接請求前﹐須要進行多少次重試。RFC 規定最低的數值是3﹐這也是默認值

net.ipv4.tcpretries2
#TCP失敗重傳次數,默認值15,意味着重傳15次才完全放棄.可減小到5,以儘早釋放內核資源.

net.netfilter.nf_conntrack
#該模塊在kernel 2.6.15（2006-01-03發佈） 被引入，支持ipv4和ipv6，取代只支持ipv4的ip_connktrack，用於跟蹤鏈接的狀態，供其餘模塊使用。最多見的使用場景是 iptables 的 nat 和 state 模塊：nat 根據轉發規則修改IP包的源/目標地址，靠nf_conntrack的記錄才能讓返回的包能路由到發請求的機器。
state 直接用 nf_conntrack 記錄的鏈接狀態（NEW/ESTABLISHED/RELATED/INVALID）來匹配防火牆過濾規則。
在服務器訪問量大時，若是內核netfilter模塊conntrack相關參數配置不合理，就會致使新鏈接被drop掉。推薦bucket至少 262144，max至少 1048576，不夠再繼續加。
net.netfilter.nf_conntrack_count 的數字持續超過 nf_conntrack_max 的 20% 就該考慮調高上限了；

net.ipv4.tcpsyncookies = 1
#表示開啓SYN Cookies。當出現SYN等待隊列溢出時，啓用cookies來處理，可防範少許SYN×××，默認爲0，表示關閉；

net.ipv4.tcptwreuse = 1
#表示開啓重用。容許將TIME-WAIT sockets從新用於新的TCP鏈接，默認爲0，表示關閉；

net.ipv4.tcptwrecycle = 1
#表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉。

net.ipv4.tcpfintimeout = 30
#表示若是套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間。

net.ipv4.tcpkeepalivetime = 1200
#表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改成20分鐘。

net.ipv4.iplocalportrange = 1024 65000
#表示用於向外鏈接的端口範圍。缺省狀況下很小：32768到61000，改成1024到65000。

net.ipv4.tcpmaxtwbuckets = 5000
#表示系統同時保持TIMEWAIT套接字的最大數量，若是超過這個數字，
TIMEWAIT套接字將馬上被清除並打印警告信息。默認爲180000，改成5000。
對於Apache、Nginx等服務器，上幾行的參數能夠很好地減小TIMEWAIT套接字數量，可是對於Squid，效果卻不大。此項參數能夠控制TIMEWAIT套接字的最大數量，避免Squid服務器被大量的TIMEWAIT套接字拖死。*

如何儘可能處理TIMEWAIT過多
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
#簡單來講，就是打開系統的TIMEWAIT重用和快速回收，至於怎麼重用和快速回收，這個問題我沒有深究，實際場景中這麼作確實有效果。用netstat或者ss觀察就能得出結論。

net.ipv4.tcp_syncookies = 1打開這個syncookies的目的其實是：「在服務器資源（並不是單指端口資源，拒絕服務有不少種資源不足的狀況）不足的狀況下，儘可能不要拒絕TCP的syn（鏈接）請求，儘可能把syn請求緩存起來，留着過會兒有能力的時候處理這些TCP的鏈接請求」。若是併發量真的很是很是高，打開這個其實用處不大。