[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
--//中文翻譯：
http://www.cnxct.com/coping-with-the-tcp-time_wait-state-on-busy-linux-servers-in-chinese-and-dont-enable-tcp_tw_recycle/

--//裡面提到不要設置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:
--//按照https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938205(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問題,重要的問題說三遍，國內大量的鏈接這樣
--//做可能會導致一些網路故障非常難查，除非應用都是非常純的內網環境裡面。