[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問題,重要的問題說三遍，國內大量的鏈接這樣
--//做可能會導致一些網路故障非常難查，除非應用都是非常純的內網環境里面，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/11244.html
標籤：Oracle
下一篇：plsql儲存程序