[20200305]netstat state=ESTABLISHED and timer=probe 2.txt

[20200305]netstat state=ESTABLISHED and timer=probe 2.txt

1.問題提出:
--//生產系統執行netstat發現大量的state=ESTABLISHED和timer=probe的網路連結。
#  netstat -tnop 2>/dev/null  | grep probe |wc -l
351

#  netstat -tnop 2>/dev/null  | grep probe |head -2
tcp        0  32120 aaa.bbb.ccc.ddd:1521        qqq. ESTABLISHED 16957/oraclezzzz1   probe (18.23/0/0)
tcp        0  32120 aaa.bbb.ccc.ddd:1521        qqq. ESTABLISHED 12413/oraclezzzz1   probe (19.25/0/0)

--//而processes=5000,幾乎消耗351/5000*100=7.02%。而且如果從客戶端查詢網路連線已經消失了，也就是這些連線是死連線，毫無用
--//處。實際上春節前我就注意到這個問題，但是我沒探究，因為高峰時連線數已經達到48XX。如果疫情一過，程式的網路連線數肯定不
--//足。

--//順便說一下使用netatat和ss遇到的問題，如果在oracle，grid使用者執行netstat -tnop 。在PID/Program name列是看不到程式號相
--//關資訊的，注意一定要使用root使用者執行，在PID/Program name列才有顯示,
--//切記，我這裡犯了一點點小錯誤。
--//另外ss 只要加入-p引數執行異常緩慢，不知道為什麼。而且ss顯示太寬，我以前講過使用column -t 過濾，實際上不對齊。
--//應該使用expand效果更好。而且視乎存在某個快取的問題，一段一段的輸出資訊在使用expand過濾時。
--//而且還有小部分是state=FIN_WAIT1(佔11個）, timer=probe的情況。
--//如果你連續檢查：
# watch -d -t -n 1 "netstat -tnop 2>/dev/null  | grep  qqq.
# seq 100 | xargs -IQ bash -c  "netstat -tnop 2>/dev/null  | grep  qqq.| ts.awk ; sleep 1"
[2020-03-05 16:23:58] tcp        0  32120 aaa.bbb.ccc.ddd:1521        qqq. ESTABLISHED 16957/oraclezzzz1   probe (3.29/0/0)
[2020-03-05 16:24:00] tcp        0  32120 aaa.bbb.ccc.ddd:1521        qqq. ESTABLISHED 16957/oraclezzzz1   probe (1.07/0/0)
[2020-03-05 16:24:02] tcp        0  32120 aaa.bbb.ccc.ddd:1521        qqq. ESTABLISHED 16957/oraclezzzz1   probe (119.22/0/0)
[2020-03-05 16:24:04] tcp        0  32120 aaa.bbb.ccc.ddd:1521        qqq. ESTABLISHED 16957/oraclezzzz1   probe (117.17/0/0)
[2020-03-05 16:24:06] tcp        0  32120 aaa.bbb.ccc.ddd:1521        qqq. ESTABLISHED 16957/oraclezzzz1   probe (115.08/0/0)
[2020-03-05 16:24:09] tcp        0  32120 aaa.bbb.ccc.ddd:1521        qqq. ESTABLISHED 16957/oraclezzzz1   probe (112.88/0/0)
--//probe後面的第1引數120->0->120->0不斷反覆。state=FIN_WAIT1也是一樣。第2，第3引數都是0，從來沒有變化。
--//注: The interpretation of field is, first field = timer countdown value, second field = no. of retransmissions,
--//third field= number of keepalive probes sent.

#  ps -eLf | grep 1695[7]
oracle    16957      1  16957  0    1 Jan14 ?        00:00:01 oraclezzzz1 (LOCAL=NO)
--//STIME=Jan19，我抽查發現有一些顯示2019. 如何顯示完整的日期格式不知道.

2.問題分析:
--//透過資料庫查詢看看,我們系統透過觸發器在v$session.client_info記錄IP地址。
#  netstat -tnop 2>/dev/null  | grep probe |grep oraclezzzz1|awk '{print $5}' | sed -e "s/:/',/" -e "s/^/('/" -e "s/$/),/"
('qqq.),
...

SELECT *
  FROM v$session
 WHERE (client_info, port) IN ( ('qqq. 51586)
                                 ....
                              , ('qqq. 55470))

--//結果不再貼出，logon_time跨度 2019/11/27 17:15:38 －2020/2/7 10:31:31。

SELECT PREV_EXEC_START,logon_time,(PREV_EXEC_START-logon_time)*86400 sec,prev_sql_id
  FROM v$session
 WHERE (client_info, port) IN ( ('qqq. 51586)
                                   ...
                              , ('qqq. 55470))
               order by 3 desc
               
--//(PREV_EXEC_START-logon_time)*86400大部分都是0或者是-1,而且prev_sql_id=b5j7y2r5zr37t.

> @ tpt/sqlid b5j7y2r5zr37t %
Show SQL text, child cursors and execution stats for SQLID b5j7y2r5zr37t child nvl('%','%')
HASH_VALUE PLAN_HASH_VALUE  CH# SQL_TEXT
---------- --------------- ---- ------------------------------------------------------------------------------------------------------------------------------------------------------
3422260473               0    0 declare      PRIVS_ERROR exception;         --raise error,if rule exception,will trigger privs_error      pragma exception_init(PRIVS_ERROR,-1031);
                                begin    execute immediate 'begin tlogon.logon; end;'; exception    when PRIVS_ERROR then        raise;    when others then        rollback; end
                                capaalogon;

 CH# PARENT_HANDLE    OBJECT_HANDLE     PLAN_HASH     PARSES   H_PARSES EXECUTIONS    FETCHES ROWS_PROCESSED ROWS_PER_FETCH    CPU_SEC CPU_SEC_EXEC    ELA_SEC ELA_SEC_EXEC       LIOS  LIOS_EXEC       PIOS      SORTS USERS_EXECUTING
---- ---------------- ---------------- ---------- ---------- ---------- ---------- ---------- -------------- -------------- ---------- ------------ ---------- ------------ ---------- ---------- ---------- ---------- ---------------
   0 000000131D196028 00000001FC3F2828          0   63547049          8   63588712          0       63587482                789794.321   .012420354 823529.875   .012950882  344748703 5.42153933       5343          0               0
--//防水牆導致的問題嗎？從PREV_EXEC_START-logon_time的差值看登入馬上就掛了。不會是該核心版本在網路處理上有bug，即使防水
--//牆導致連線斷開，連線也不應該保持這麼久不會斷開。

3.先解決state=FIN_WAIT1的情況：
--//參考連線： https://blog.csdn.net/microgp/article/details/86588973
FIN_WAIT1：

1、sysctl -a |grep net.ipv4.tcp_max_orphans(記下 net.ipv4.tcp_max_orphans的值第三步需要賦給orig_orphans)  
2、sysctl -w net.ipv4.tcp_max_orphans=0   然後等待FIN_WAIT1的消失，可以用 netstat -np|grep 9080  反覆檢視，直到沒有任何條目
3、sysctl -w net.ipv4.tcp_max_orphans=$orig_orphans

--//在測試前我在測試環境做了測試，修改它並不影響業務。建議大家還是小心謹慎，自己再測試看看。
#  sysctl -a |grep net.ipv4.tcp_max_orphans
net.ipv4.tcp_max_orphans = 262144
# sysctl -w net.ipv4.tcp_max_orphans=0
--//我的測試最多等3*120秒這些連線state=FIN_WAIT1會全部消失。
# sysctl -w net.ipv4.tcp_max_orphans =262144

4.解決state=ESTABLISHED and timer=probe：
--//先找一個不太重要的程式看看。
#  netstat -tnop 2>/dev/null  | grep 112514
tcp        0  25245 aaa.bbb.ccc.ddd:1521        rrr.ttt.yyy.215:1301         ESTABLISHED 112514/oraclezzzz1  probe (36.31/0/0)

#  kill -9 112514
#  ps -ef | grep 11251[4]
#  netstat -tnop 2>/dev/null  | grep rrr.ttt.yyy.215:1301
tcp        0  25246 aaa.bbb.ccc.ddd:1521        rrr.ttt.yyy.215:1301         FIN_WAIT1   -                   probe (57.31/0/0)
--//昏，state=FIN_WAIT1,對應程式已經不見了。但是連結還是保持，state=FIN_WAIT1。現在想想前面看到state=FIN_WAIT1的連線,不會當
--//時kill程式留下的把。
--//重複處理state=FIN_WAIT1步驟，該連線也會消失。

--//批次處理就簡單了。
1.先看一下是否都是oracle相關程式,不能是一些特殊程式,避免資料庫down掉.
# netstat -tnop 2>/dev/null  | grep probe | awk '{print $7}' | cut -f1 -d"/"  | paste -sd, | xargs ps v -p | column -t

2.建立kill指令碼
#  netstat -tnop 2>/dev/null  | grep probe | awk '{print $7}' | cut -f1 -d"/"|xargs -IQ echo kill -9 Q

3.執行：
# netstat -tnop 2>/dev/null  | grep probe | awk '{print $7}' | cut -f1 -d"/"|xargs -IQ echo kill -9 Q | bash
or
# netstat -tnop 2>/dev/null  | grep probe | awk '{print $7}' | cut -f1 -d"/"|xargs -IQ kill -9 Q

--//不放心把上面的指令碼copy下來，單獨自行。另外必須提的是如果net.ipv4.tcp_max_orphans=0，kill -9程式後馬上查詢
--// netstat -tnop 2>/dev/null  | grep probe馬上消失。
--//不會出現前面state=FIN_WAIT1的情況。必須記住執行 sysctl -w net.ipv4.tcp_max_orphans=262144修改該引數回來。

4.檢查netsta 是否還有timer=probe的資訊.
#  netstat -tnop 2>/dev/null  | grep probe

5.總結:
--//1.不知道是否是在業務高峰密集登入導致的網路異常.因為登入是繞不開那個語句的執行的,還是該核心版本在網路上的bug.
--//2.netstat -ntop 注意選擇root使用者執行,不然看不到PID/Program name相關資訊.
--//補充一點在我的測試環境oracle使用者執行沒有問題，有點奇怪。
--//3.我感覺不能使用SQLNET.EXPIRE_TIME檢測網路連線,也許使用tcp keepalive特性要好一些.明天修改它,在1臺機器使用
--//tcp keepalive特性,另外1臺保持不變,再觀察看看.
--//我們rac環境跑2個資料庫，一臺使用tcp keepalive特性，另外一臺使用SQLNET.EXPIRE_TIME.再觀察看看。
net.ipv4.tcp_keepalive_time = 590
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 4

--//4.另外我懷疑我們前臺接入認證的軟體引起的問題。windows開機出現登入介面快，實際上是一個假象，我們登入後接入認證的程式
--//設計不好，會彈出一個介面，如果使用者選擇X而不是最小化，機器無法接入網路，不知道這個是否會引起這個問題。

--//5.對這個團隊再次失望，沒人重視這些細節問題。這樣被動的維護系統，真不知道以後會出什麼事情。今天上班檢查發現再次出現2
--//個連結。