?一，在系統執行命令時報錯error: too many open files

在linux中一切皆文件，例如監聽的端口，設備，文件，進程等，都需要占用一個文件描述符（fd）。故在linux系統中最大打開文件描述符數open files，就很容易在大并發請求的系統上成為瓶頸。

調整的方法：

# echo "ulimit -n 1000000" >> /etc/profile

二，SYN Flood***

SYN Flood是當前最流行的DoS（拒絕服務***）與DDoS（分布式拒絕服務***）的方式之一，這是一種利用TCP協議缺陷，發送大量偽造的TCP連接請求，常用假冒的IP或IP號段發來海量的請求連接的第一個握手包（SYN包），被***服務器回應第二個握手包（SYN+ACK包），因為對方是假冒IP，對方永遠收不到包且不會回應第三個握手包。導致被***服務器保持大量SYN_RECV狀態的“半連接”，并且會重試默認5次回應第二個握手包，塞滿TCP等待連接隊列，資源耗盡（CPU滿負荷或內存不足），讓正常的業務請求連接不進來。

我們看到業務曲線大跌時，檢查機器和DNS，發現只是對外的web機響應慢、CPU負載高、ssh登陸慢甚至有些機器登陸不上，檢查系統syslog，會有類此如下的信息：

# tail -f /var/log/messages

Apr 18 11:21:56 web5 kernel: possible SYN flooding on port 80. Sending cookies.

檢查連接數增多，并且SYN_RECV 連接特別多：

# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'?

TIME_WAIT 16855

CLOSE_WAIT 21

SYN_SENT 99

FIN_WAIT1 229

FIN_WAIT2 113

ESTABLISHED 8358

SYN_RECV 48965

CLOSING 3

LAST_ACK 313

我們可以通過調優kernel來緩解***：

1）net.ipv4.tcp_synack_retries?= 0

這個比較重要，表示回應第二個握手包（SYN+ACK包）給客戶端IP后，如果收不到第三次握手包（ACK包）后，進行0次重試，加快回收“半連接”。

2）net.ipv4.tcp_max_syn_backlog=16384

進入SYN包的最大請求隊列長度，默認1024。對重負載服務器,增加該值顯然有好處。

3）net.ipv4.tcp_syncookies = 1

打開syn cookie功能，***當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN，默認為0，表示關閉。

如果，調節kernel仍不能減輕syn flood***的話，直接用nginx或iptables封有嫌疑的ip。

三，系統socket TIME_WAIT過多

當socket連接由client端主動關閉后，socket連接最后會處于TIME_WAIT狀態一段時間。一般情況下，這段時間為

2MSL（MSL:tcp報文段最大生存時間，他是任何報文段被丟棄前在網絡內的最大時間，這樣做也是為了讓那些傳輸慢的報文段能被成功接收）。RFC 793[ Postel 1981c]指出MSL為2分鐘，但是現實中常用值為30s或1min或2min。

當系統中有大量socket?TIME_WAIT狀態時，導致占用過多系統端口（而一個端口就是fd）。例如我們有個服務監聽的端口為8012，重啟的時候經常會提示端口被占用。

通過查看/proc/sys/net/ipv4/ip_local_port_range可以知道設置的Linux內核自動分配端口的端口范圍：

# cat /proc/sys/net/ipv4/ip_local_port_range

? ?1025 65535

減少方法：

1）net.ipv4.tcp_tw_reuse = 1

表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關閉；

2）net.ipv4.tcp_tw_recycle = 1

表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉；

3）net.ipv4.tcp_fin_timeout = 30

#表示如果套接字由本端主動要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間。

四，使用ip_conntrack模塊導致系統丟包

kernel 用 ip_conntrack 模塊來記錄 iptables 網絡包的狀態，并把每條記錄保存到 table 里（這個 table 在內存里，可以通過/proc/net/ip_conntrack 查看當前已經記錄的總數），如果網絡狀況繁忙，比如高連接，高并發連接等會導致逐步占用這個 table 可用空間，一般這個 table 很大不容易占滿并且可以自己清理，table 的記錄會一直呆在 table 里占用空間直到源 IP 發一個 RST 包，但是如果出現被***、錯誤的網絡配置、有問題的路由/路由器、有問題的網卡等情況的時候，就會導致源 IP 發的這個 RST 包收不到，這樣就積累在 table 里，越積累越多直到占滿。無論，哪種情況導致table變滿，滿了以后就會丟包，出現外部無法連接服務器的情況。內核會報如下錯誤信息：kernel: ip_conntrack: table full, dropping packet。

在/proc/net/ip_conntrack中，每一個跟蹤連接表會占用304字節的內核存儲空間，跟蹤連接越多，越占用系統內存：

# cat /var/log/messages|grep conn ??

Nov 28 13:18:20 yd_82_231 kernel: ip_conntrack version 2.4 (8192 buckets, 65536 max) - 304 bytes per conntrack

調整方法：

1）net.ipv4.netfilter.ip_conntrack_max = 655360

增大跟蹤的最大條數

2）net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 10800

減少跟蹤連接的最大有效時間

五，server連接數高一般調整的tcp相關參數

1）/proc/sys/net/ipv4/tcp_mem

# cat /proc/sys/net/ipv4/tcp_mem

786432 ?2097152 ?3145728

確定 TCP 棧應該如何反映內存使用；每個值的單位都是內存頁（通常是 4KB）。第一個值是內存使用的下限。第二個值是內存壓力模式開始對緩沖區使用應用壓力的上限。第三個值是內存上限。在這個層次上可以將報文丟棄，從而減少對內存的使用。對于較大的 BDP 可以增大這些值（但是要記住，其單位是內存頁，而不是字節）。

2）/proc/sys/net/ipv4/tcp_wmem

# cat /proc/sys/net/ipv4/tcp_wmem

4096 ?65536 ?8388608

為自動調優定義每個 socket 使用的內存。第一個值是為 socket 的發送緩沖區分配的最少字節數。第二個值是默認值（該值會被 wmem_default 覆蓋），緩沖區在系統負載不重的情況下可以增長到這個值。第三個值是發送緩沖區空間的最大字節數（該值會被 wmem_max 覆蓋）。

3）/proc/sys/net/ipv4/tcp_rmem

# cat /proc/sys/net/ipv4/tcp_rmem

4096 87380 8388608

與 tcp_wmem 類似，不過它表示的是為自動調優所使用的接收緩沖區的值。

轉載于:https://blog.51cto.com/leejia/1422219

總結

以上是生活随笔為你收集整理的常见问题kernel调优的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。