[20200312]不要設定net.ipv4.tcp_tw_recycle=1.txt

[20200312]不要設定net.ipv4.tcp_tw_recycle=1.txt

--//昨天認真看了2篇blog：
https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
--//中文翻譯：


--//裡面提到不要設定net.ipv4.tcp_tw_recycle=1。TIME_WAIT狀態問題不是太嚴重，可以完全不理會它。
--//我仔細閱讀，說真的許多一些細節還不是很理解。我開始接觸主要是不理解生產系統rac環境為什麼這麼多state=TIME_WAIT.
--//現在看來自己純粹是畫蛇添足，浪費時間,不過自己感覺還是學到許多東西.

--//現在我大概知道原因,做一些總結：

1.實際上對於正常資料庫應用，正常退出應用程式，實際上state=TIME_WAIT發生在客戶端，這也是我開始的困惑。服務端不應該這個多
  state=TIME_WAIT。我的問題實際上由此展開^_^.

https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux

TCP state diagram

Only the end closing the connection first will reach the TIME-WAIT state. The other end will follow a path which usually
permits to quickly get rid of the connection.
--//只有先關閉連線的結束才會達到TIME-WAIT狀態.. 另一端將沿著通常允許快速擺脫連線。

2.我們使用dblink短連線很多，這時服務端實際上變成客戶端，導致state=TIME_WAIT多。

3.exadata 出廠設定 net.ipv4.tcp_timestamps = 0，即使我設定net.ipv4.tcp_tw_recycle=1也無效，毫無作用，這也是我在測試中遇
  到的第二個困惑。我想oracle這樣做可能有它的道理, 不會使用特殊的方式規避其它dba設定net.ipv4.tcp_tw_recycle=1的問題。

--//exadate 的 /etc/sysctl.conf設定,不知道前面# 12650500 ,oracle內部表示什麼?
# 12650500
net.ipv4.tcp_timestamps = 0

--//再次提醒建議不要設定net.ipv4.tcp_tw_recycle=1 解決大量state=TIME_WAIT問題。

4.還有1個原因導致服務端state=TIME_WAIT增多,就是客戶端連線RAC資料庫使用scan ip,會跳轉到vip ip，這樣一旦大量使用者以這種方式
  登入，就是在服務端產生大量的state=TIME_WAIT連線。

5.還有前臺客戶端基本都是XP機器。我的測試MS關於tcp_timestamps預設設定是關閉的，至少在windows 7，windows 2003伺服器版下,XP
  我不知道。
 
這樣即使服務端設定  net.ipv4.tcp_timestamps = 1 和 net.ipv4.tcp_tw_recycle=1 依舊在服務端生產大量的state=TIME_WAIT.
不過linux機器預設設定都是net.ipv4.tcp_timestamps = 1。

--//再次提醒建議不要設定net.ipv4.tcp_tw_recycle=1 解決大量state=TIME_WAIT問題。  
--//注：我在這裡測試時又犯了一個錯誤，以為跨網段的機器不能快速回收TIME_WAIT，實際上是我的測試機器windows7的
--//tcp_timestamps預設設定是關閉的.

6.有一個可行的方法減少大量state=TIME_WAIT連線,就是在一些中介軟體伺服器可以不要使用scan ip連線資料庫，採用老的vip ip就可以
  減少這樣的情況。改動涉及中介軟體伺服器，影響不大,這是比較可行成本最低的改進方法,僅僅對rac環境有效.

--//話又反活來講,如果不是rac環境,可能就看不到大量的state=TIME_WAIT狀態.

7.如果網路連結透過公網或者NAT轉換，肯定不能設定net.ipv4.tcp_tw_recycle=1. 由於我們一些應用透過公網，當我設定
  net.ipv4.tcp_tw_recycle=1
  net.ipv4.tcp_timestamps=1
--//確實有少量的客戶端(實際上也就2臺)無法連線伺服器的情況，甚至內網的機器也出現一臺，我不知道為什麼。最終還原原來設定
  net.ipv4.tcp_tw_recycle=0
  net.ipv4.tcp_timestamps=0

8.記憶體 CPU 資源消耗很少。參考連結的測試：https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux

9.state=TIME_WAIT對應用影響很小，4元素組成一個連線，oracle 建議核心引數設定net.ipv4.ip_local_port_range = 1024 65000
  支援埠數量達到64000，這樣如果不達到每秒60000/60 = 1000 個/連線，基本影響可以忽略。

  我感覺不能達到這個數量，至少我自己沒見過。我們資料庫高峰也就是200個/每秒連線。

10.TIME_WAIT狀態的消失時間在linux下寫死的,在net/tcp.h標頭檔案裡面的,許多連結提示修改net.ipv4.tcp_fin_timeout是錯誤的:
--//除非修改標頭檔案內容,重新編譯核心!!
#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
                  * state, about 60 seconds */
#define TCP_FIN_TIMEOUT TCP_TIMEWAIT_LEN
                                 /* BSD style FIN_WAIT2 deadlock breaker.
                  * It used to be 3min, new value is 60sec,
                  * to combine FIN-WAIT-2 timeout with
                  * TIME-WAIT timer.
                  */

11.windows下可以修改TIME_WAIT狀態的消失時間:
--//在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters上新增一個DWORD型別的值TcpTimedWaitDelay，值
--//就是秒數，最小30秒,不能低於該值.注要重啟機器才能生效:
--//timewait.reg
REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:0000001e

12.windows下設定tcp_timestamps:
--//按照(v=technet.10)?redirectedfrom=MSDN
Tcp1323Opts
--//注:1323 應該是關聯RFC 1323文件.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type  Range            Default value
------------------------------------------
REG_DWORD  0 | 1 | 2 | 3    3

Value  Meaning
0 (00) Timestamps and window scaling are disabled.
1 (01) Window scaling is enabled.
2 (10) Timestamps are enabled.
3 (11) Timestamps and window scaling are enabled.

--//按照介紹MS預設應該是開啟tcp_timestamps的。不過我發現在windows 7,windows 2003下不是這樣。修改為2或者3.我僅僅測試修改3
--//的情況.
REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"Tcp1323Opts"=hex:03

13.最後簡單講一下測試方法,使用tnsping server_ip count > /dev/null,這樣比較簡單快捷,這時state=TIME_WAIT出現在服務端,使用
   netstat -ntop 或者ss -nto 觀察.

# seq 10000 | xargs -IQ bash -c "ss -tano state time-wait | ts.awk ; sleep 1"
or
# seq 10000 | xargs -IQ bash -c "netstat -nto | grep TIME-WAIT | ts.awk ; sleep 1"

$ cat $(which ts.awk)
# /bin/bash
gawk '{ print strftime("[%Y-%m-%d %H:%M:%S]"), $0 }'

在服務端net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=1,客戶端net.ipv4.tcp_timestamps=1的情況下服務端出現TIME_WAIT很快消失.
在服務端net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=1,客戶端net.ipv4.tcp_timestamps=0的情況下服務端出現TIME_WAIT等60秒消失.
在服務端net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=0,                                       服務端出現TIME_WAIT等60秒消失.
在服務端net.ipv4.tcp_tw_recycle=0,net.ipv4.tcp_timestamps=N(N=1,0)                                 服務端出現TIME_WAIT等60秒消失.

--//大家可以自行測試.測試結果就不貼上來了,有點繁瑣.
--//從這裡也看出如果大量的客戶端是windows，沒有開啟tcp_timestamp,在服務端設定
--//net.ipv4.tcp_tw_recycle=1,net.ipv4.tcp_timestamps=1也一樣毫無用處.

14.演示一個服務端產生大量TIME_WAIT的例子:
--//還是另外寫一篇,不然寫的又太長了.

--//最後再次提醒建議不要設定net.ipv4.tcp_tw_recycle=1來解決大量state=TIME_WAIT問題,重要的問題說三遍，國內大量的連結這樣
--//做可能會導致一些網路故障非常難查，除非應用都是非常純的內網環境裡面。