【Mysql—Linux】系統調優,你所不知道的TIME_WAIT和CLOSE_WAIT
http://mp.weixin.qq.com/s?__biz=MzA3MzYwNjQ3NA==&mid=403232978&idx=1&sn=4ed396ac1999add1c866419bd62b0e75&scene=21#wechat_redirect
你遇到過TIME_WAIT的問題嗎?
Netstat的一些常用選項
netstat -s——本選項能夠按照各個協議分別顯示其統計資料。如果你的應用程式(如Web瀏覽器)執行速度比較慢,或者不能顯示Web頁之類的資料,那麼你就可以用本選項來檢視一下所顯示的資訊。你需要仔細檢視統計資料的各行,找到出錯的關鍵字,進而確定問題所在。
netstat -e——本選項用於顯示關於乙太網的統計資料。它列出的專案包括傳送的資料包的總位元組數、錯誤數、刪除數、資料包的數量和廣播的數量。這些統計資料既有傳送的資料包數量,也有接收的資料包數量。這個選項可以用來統計一些基本的網路流量。
netstat -r——本選項可以顯示關於路由表的資訊,類似於後面所講使用route print命令時看到的 資訊。除了顯示有效路由外,還顯示當前有效的連線。
netstat -a——本選項顯示一個所有的有效連線資訊列表,包括已建立的連線(ESTABLISHED),也包括監聽連線請求(LISTENING)的那些連線,斷開連線(CLOSE_WAIT)或者處於聯機等待狀態的(TIME_WAIT)等
netstat -n——顯示所有已建立的有效連線。
我相信很多都遇到過這個問題。一旦有使用者在喊:網路變慢了。第一件事情就是,netstat -a | grep TIME_WAIT | wc -l 一下,哎呀媽呀,幾千個TIME_WAIT。
然後,做的第一件事情就是:開啟Google或者Bing,輸入關鍵詞:too many time wait。一定能找到解決方案,而排在最前面或者被很多人到處轉載的解決方案一定是:
開啟 sysctl.conf 檔案,修改以下幾個引數:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_timestamps = 1然後執行 /sbin/sysctl -p 讓引數生效。net.ipv4.tcp_syncookies = 1 表示開啟SYN Cookies。當出現SYN等待佇列溢位時,啟用cookies來處理,可防範少量SYN攻擊,預設為0,表示關閉;
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線,預設為0,表示關閉;
net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連線中TIME-WAIT sockets的快速回收,預設為0,表示關閉。
net.ipv4.tcp_fin_timeout 修改系統預設的 TIMEOUT 時間
你也會被告知,開啟tw_recylce和tw_reuse一定需要timestamps的支援,而且這些配置一般不建議開啟,但是對解決TIME_WAIT很多的問題,有很好的用處。
接下來,你就直接修改了這幾個引數,reload一下,發現,咦,沒幾分鐘,TIME_WAIT的數量真的降低了,也沒發現哪個使用者說有問題,然後就沒有然後了。
做到這一步,相信50%或者更高比例的開發就已經止步了。問題好像解決了,但是,要徹底理解並解決這個問題,可能就沒這麼簡單,或者說,還有很長的路要走!
什麼是TIME-WAIT和CLOSE-WAIT?
所謂,要解決問題,就要先理解問題。隨便改兩行程式碼,發現bug“沒有了”,也不是bug真的沒有了,只是隱藏在更深的地方,你沒有發現,或者以你的知識水平,你無法發現而已。
大家知道,由於socket是全雙工的工作模式,一個socket的關閉,是需要四次握手來完成的。
-
主動關閉連線的一方,呼叫close();協議層傳送FIN包
-
被動關閉的一方收到FIN包後,協議層回覆ACK;然後被動關閉的一方,進入CLOSE_WAIT狀態,主動關閉的一方等待對方關閉,則進入FIN_WAIT_2狀態;此時,主動關閉的一方 等待 被動關閉一方的應用程式,呼叫close操作
-
被動關閉的一方在完成所有資料傳送後,呼叫close()操作;此時,協議層傳送FIN包給主動關閉的一方,等待對方的ACK,被動關閉的一方進入LAST_ACK狀態;
-
主動關閉的一方收到FIN包,協議層回覆ACK;此時,主動關閉連線的一方,進入TIME_WAIT狀態;而被動關閉的一方,進入CLOSED狀態
-
等待2MSL時間,主動關閉的一方,結束TIME_WAIT,進入CLOSED狀態
透過上面的一次socket關閉操作,你可以得出以下幾點:
-
主動關閉連線的一方 - 也就是主動呼叫socket的close操作的一方,最終會進入TIME_WAIT狀態
-
被動關閉連線的一方,有一箇中間狀態,即CLOSE_WAIT,因為協議層在等待上層的應用程式,主動呼叫close操作後才主動關閉這條連線
-
TIME_WAIT會預設等待2MSL時間後,才最終進入CLOSED狀態;
-
在一個連線沒有進入CLOSED狀態之前,這個連線是不能被重用的!
所以,這裡憑你的直覺,TIME_WAIT並不可怕(not really,後面講),CLOSE_WAIT才可怕,因為CLOSE_WAIT很多,表示說要麼是你的應用程式寫的有問題,沒有合適的關閉socket;要麼是說,你的伺服器CPU處理不過來(CPU太忙)或者你的應用程式一直睡眠到其它地方(鎖,或者檔案I/O等等),你的應用程式獲得不到合適的排程時間,造成你的程式沒法真正的執行close操作。
這裡又出現兩個問題:
-
上文提到的連線重用,那連線到底是個什麼概念?
-
協議層為什麼要設計一個TIME_WAIT狀態?這個狀態為什麼預設等待2MSL時間才會進入CLOSED
先解釋清楚這兩個問題,我們再來看,開頭提到的幾個網路配置究竟有什麼用,以及TIME_WAIT的後遺症問題。
Socket連線到底是個什麼概念?
大家經常提socket,那麼,到底什麼是一個socket?其實,socket就是一個 五元組,包括:
-
源IP
-
源埠
-
目的IP
-
目的埠
-
型別:TCP or UDP
這個五元組,即標識了一條可用的連線。注意,有很多人把一個socket定義成四元組,也就是 源IP:源埠 + 目的IP:目的埠,這個定義是不正確的。
例如,如果你的本地出口IP是180.172.35.150,那麼你的瀏覽器在連線某一個Web伺服器,例如百度的時候,這條socket連線的四元組可能就是:
[180.172.35.150:45678, tcp, 180.97.33.108:80]
源IP為你的出口IP地址 180.172.35.150,源埠為隨機埠 45678,目的IP為百度的某一個負載均衡伺服器IP 180.97.33.108,埠為HTTP標準的80埠。
如果這個時候,你再開一個瀏覽器,訪問百度,將會產生一條新的連線:
[180.172.35.150:43678, tcp, 180.97.33.108:80]
這條新的連線的源埠為一個新的隨機埠 43678。
如此來看,如果你的本機需要壓測百度,那麼,你最多可以建立多少個連線呢?我在文章《雲思路 | 輕鬆構建千萬級投票系統》裡也稍微提過這個問題,沒有閱讀過本文的,可以傳送“投票系統”閱讀。
第二個問題,TIME_WAIT有什麼用?
如果我們來做個類比的話,TIME_WAIT的出現,對應的是你的程式裡的異常處理,它的出現,就是為了解決網路的丟包和網路不穩定所帶來的其他問題:
第一,防止前一個連線【五元組,我們繼續以 180.172.35.150:45678, tcp, 180.97.33.108:80 為例】上延遲的資料包或者丟失重傳的資料包,被後面複用的連線【前一個連線關閉後,此時你再次訪問百度,新的連線可能還是由180.172.35.150:45678, tcp, 180.97.33.108:80 這個五元組來表示,也就是源埠湊巧還是45678】錯誤的接收(異常:資料丟了,或者傳輸太慢了),參見下圖:
-
SEQ=3的資料包丟失,重傳第一次,沒有得到ACK確認
-
如果沒有TIME_WAIT,或者TIME_WAIT時間非常端,那麼關閉的連線【180.172.35.150:45678, tcp, 180.97.33.108:80 的狀態變為了CLOSED,源埠可被再次利用】,馬上被重用【對180.97.33.108:80新建的連線,複用了之前的隨機埠45678】,並連續傳送SEQ=1,2 的資料包
-
此時,前面的連線上的SEQ=3的資料包再次重傳,同時,seq的序號剛好也是3(這個很重要,不然,SEQ的序號對不上,就會RST掉),此時,前面一個連線上的資料被後面的一個連線錯誤的接收
第二,確保連線方能在時間範圍內,關閉自己的連線。其實,也是因為丟包造成的,參見下圖:
-
主動關閉方關閉了連線,傳送了FIN;
-
被動關閉方回覆ACK同時也執行關閉動作,傳送FIN包;此時,被動關閉的一方進入LAST_ACK狀態
-
主動關閉的一方回去了ACK,主動關閉一方進入TIME_WAIT狀態;
-
但是最後的ACK丟失,被動關閉的一方還繼續停留在LAST_ACK狀態
-
此時,如果沒有TIME_WAIT的存在,或者說,停留在TIME_WAIT上的時間很短,則主動關閉的一方很快就進入了CLOSED狀態,也即是說,如果此時新建一個連線,源隨機埠如果被複用,在connect傳送SYN包後,由於被動方仍認為這條連線【五元組】還在等待ACK,但是卻收到了SYN,則被動方會回覆RST
-
造成主動建立連線的一方,由於收到了RST,則連線無法成功
所以,你看到了,TIME_WAIT的存在是很重要的,如果強制忽略TIME_WAIT,還是有很高的機率,造成資料粗亂,或者短暫性的連線失敗。
那麼,為什麼說,TIME_WAIT狀態會是持續2MSL(2倍的max segment lifetime)呢?這個時間可以透過修改核心引數調整嗎?第一,這個2MSL,是RFC 793裡定義的,參見RFC的截圖示紅的部分:
這個定義,更多的是一種保障(IP資料包裡的TTL,即資料最多存活的跳數,真正反應的才是資料在網路上的存活時間),確保最後丟失了ACK,被動關閉的一方再次重發FIN並等待回覆的ACK,一來一去兩個來回。核心裡,寫死了這個MSL的時間為:30秒(有讀者提醒,RFC裡建議的MSL其實是2分鐘,但是很多實現都是30秒),所以TIME_WAIT的即為1分鐘:
所以,再次回想一下前面的問題,如果一條連線,即使在四次握手關閉了,由於TIME_WAIT的存在,這個連線,在1分鐘之內,也無法再次被複用,那麼,如果你用一臺機器做壓測的客戶端,你一分鐘能傳送多少併發連線請求?如果這臺是一個負載均衡伺服器,一臺負載均衡伺服器,一分鐘可以有多少個連線同時訪問後端的伺服器呢?
TIME_WAIT很多,可怕嗎?
如果你透過 ss -tan state time-wait | wc -l 發現,系統中有很多TIME_WAIT,很多人都會緊張。多少算多呢?幾百幾千?如果是這個量級,其實真的沒必要緊張。第一,這個量級,因為TIME_WAIT所佔用的記憶體很少很少;因為記錄和尋找可用的local port所消耗的CPU也基本可以忽略。
會佔用記憶體嗎?當然!任何你可以看到的資料,核心裡都需要有相關的資料結構來儲存這個資料啊。一條Socket處於TIME_WAIT狀態,它也是一條“存在”的socket,核心裡也需要有保持它的資料:
-
核心裡有儲存所有連線的一個hash table,這個hash table裡面既包含TIME_WAIT狀態的連線,也包含其他狀態的連線。主要用於有新的資料到來的時候,從這個hash table裡快速找到這條連線。不同的核心對這個hash table的大小設定不同,你可以透過dmesg命令去找到你的核心設定的大小:
-
還有一個hash table用來儲存所有的bound ports,主要用於可以快速的找到一個可用的埠或者隨機埠:
由於核心需要儲存這些資料,必然,會佔用一定的記憶體。
會消耗CPU嗎?當然!每次找到一個隨機埠,還是需要遍歷一遍bound ports的吧,這必然需要一些CPU時間。
TIME_WAIT很多,既佔記憶體又消耗CPU,這也是為什麼很多人,看到TIME_WAIT很多,就蠢蠢欲動的想去幹掉他們。其實,如果你再進一步去研究,1萬條TIME_WAIT的連線,也就多消耗1M左右的記憶體,對現代的很多伺服器,已經不算什麼了。至於CPU,能減少它當然更好,但是不至於因為1萬多個hash item就擔憂。
如果,你真的想去調優,還是需要搞清楚別人的調優建議,以及調優引數背後的意義!
TIME_WAIT調優,你必須理解的幾個調優引數
在具體的圖例之前,我們還是先解析一下相關的幾個引數存在的意義。
-
net.ipv4.tcp_timestamps
RFC 1323 在 TCP Reliability一節裡,引入了timestamp的TCP option,兩個4位元組的時間戳欄位,其中第一個4位元組欄位用來儲存傳送該資料包的時間,第二個4位元組欄位用來儲存最近一次接收對方傳送到資料的時間。有了這兩個時間欄位,也就有了後續最佳化的餘地。
tcp_tw_reuse 和 tcp_tw_recycle就依賴這些時間欄位。
-
net.ipv4.tcp_tw_reuse
字面意思,reuse TIME_WAIT狀態的連線。
時刻記住一條socket連線,就是那個五元組,出現TIME_WAIT狀態的連線,一定出現在主動關閉連線的一方。所以,當主動關閉連線的一方,再次向對方發起連線請求的時候(例如,客戶端關閉連線,客戶端再次連線服務端,此時可以複用了;負載均衡伺服器,主動關閉後端的連線,當有新的HTTP請求,負載均衡伺服器再次連線後端伺服器,此時也可以複用),可以複用TIME_WAIT狀態的連線。
透過字面解釋,以及例子說明,你看到了,tcp_tw_reuse應用的場景:某一方,需要不斷的透過“短連線”連線其他伺服器,總是自己先關閉連線(TIME_WAIT在自己這方),關閉後又不斷的重新連線對方。
那麼,當連線被複用了之後,延遲或者重發的資料包到達,新的連線怎麼判斷,到達的資料是屬於複用後的連線,還是複用前的連線呢?那就需要依賴前面提到的兩個時間欄位了。複用連線後,這條連線的時間被更新為當前的時間,當延遲的資料達到,延遲資料的時間是小於新連線的時間,所以,核心可以透過時間判斷出,延遲的資料可以安全的丟棄掉了。
這個配置,依賴於連線雙方,同時對timestamps的支援。同時,這個配置,僅僅影響outbound連線,即做為客戶端的角色,連線服務端[connect(dest_ip, dest_port)]時複用TIME_WAIT的socket。
-
net.ipv4.tcp_tw_recycle
字面意思,銷燬掉 TIME_WAIT。
當開啟了這個配置後,核心會快速的回收處於TIME_WAIT狀態的socket連線。多快?不再是2MSL,而是一個RTO(retransmission timeout,資料包重傳的timeout時間)的時間,這個時間根據RTT動態計算出來,但是遠小於2MSL。
有了這個配置,還是需要保障 丟失重傳或者延遲的資料包,不會被新的連線(注意,這裡不再是複用了,而是之前處於TIME_WAIT狀態的連線已經被destroy掉了,新的連線,剛好是和某一個被destroy掉的連線使用了相同的五元組而已)所錯誤的接收。在啟用該配置,當一個socket連線進入TIME_WAIT狀態後,核心裡會記錄包括該socket連線對應的五元組中的對方IP等在內的一些統計資料,當然也包括從該對方IP所接收到的最近的一次資料包時間。當有新的資料包到達,只要時間晚於核心記錄的這個時間,資料包都會被統統的丟掉。
這個配置,依賴於連線雙方對timestamps的支援。同時,這個配置,主要影響到了inbound的連線(對outbound的連線也有影響,但是不是複用),即做為服務端角色,客戶端連進來,服務端主動關閉了連線,TIME_WAIT狀態的socket處於服務端,服務端快速的回收該狀態的連線。
由此,如果客戶端處於NAT的網路(多個客戶端,同一個IP出口的網路環境),如果配置了tw_recycle,就可能在一個RTO的時間內,只能有一個客戶端和自己連線成功(不同的客戶端發包的時間不一致,造成服務端直接把資料包丟棄掉)。
我儘量嘗試用文字解釋清楚,但是,來點案例和圖示,應該有助於我們徹底理解。
我們來看這樣一個網路情況:
-
客戶端IP地址為:180.172.35.150,我們可以認為是瀏覽器
-
負載均衡有兩個IP,外網IP地址為 115.29.253.156,內網地址為10.162.74.10;外網地址監聽80埠
-
負載均衡背後有兩臺Web伺服器,一臺IP地址為 10.162.74.43,監聽80埠;另一臺為 10.162.74.44,監聽 80 埠
-
Web伺服器會連線資料伺服器,IP地址為 10.162.74.45,監聽 3306 埠
這種簡單的架構下,我們來看看,在不同的情況下,我們今天談論的tw_reuse/tw_recycle對網路連線的影響。
先做個假定:
-
客戶端透過HTTP/1.1連線負載均衡,也就是說,HTTP協議投Connection為keep-alive,所以我們假定,客戶端 對 負載均衡伺服器 的socket連線,客戶端會斷開連線,所以,TIME_WAIT出現在客戶端
-
Web伺服器和MySQL伺服器的連線,我們假定,Web伺服器上的程式在連線結束的時候,呼叫close操作關閉socket資源連線,所以,TIME_WAIT出現在 Web 伺服器端。
那麼,在這種假定下:
-
Web伺服器上,肯定可以配置開啟的配置:tcp_tw_reuse;如果Web伺服器有很多連向DB伺服器的連線,可以保證socket連線的複用。
-
那麼,負載均衡伺服器和Web伺服器,誰先關閉連線,則決定了我們怎麼配置tcp_tw_reuse/tcp_tw_recycle了
場景一:負載均衡伺服器首先關閉連線
在這種情況下,因為負載均衡伺服器對Web伺服器的連線,TIME_WAIT大都出現在負載均衡伺服器上。
在負載均衡伺服器上的配置:
-
net.ipv4.tcp_tw_reuse = 1 //儘量複用連線
-
net.ipv4.tcp_tw_recycle = 0 //不能保證客戶端不在NAT的網路啊
在Web伺服器上的配置為:
-
net.ipv4.tcp_tw_reuse = 1 //這個配置主要影響的是Web伺服器到DB伺服器的連線複用
-
net.ipv4.tcp_tw_recycle: 設定成1和0都沒有任何意義。想一想,在負載均衡和它的連線中,它是服務端,但是TIME_WAIT出現在負載均衡伺服器上;它和DB的連線,它是客戶端,recycle對它並沒有什麼影響,關鍵是reuse
場景二:Web伺服器首先關閉來自負載均衡伺服器的連線
在這種情況下,Web伺服器變成TIME_WAIT的重災區。負載均衡對Web伺服器的連線,由Web伺服器首先關閉連線,TIME_WAIT出現在Web伺服器上;Web伺服器對DB伺服器的連線,由Web伺服器關閉連線,TIME_WAIT也出現在它身上,此時,負載均衡伺服器上的配置:
-
net.ipv4.tcp_tw_reuse:0 或者 1 都行,都沒有實際意義
-
net.ipv4.tcp_tw_recycle=0 //一定是關閉recycle
在Web伺服器上的配置:
-
net.ipv4.tcp_tw_reuse = 1 //這個配置主要影響的是Web伺服器到DB伺服器的連線複用
-
net.ipv4.tcp_tw_recycle=1 //由於在負載均衡和Web伺服器之間並沒有NAT的網路,可以考慮開啟recycle,加速由於負載均衡和Web伺服器之間的連線造成的大量TIME_WAIT
回答幾個大家提到的幾個問題
1. 請問我們所說連線池可以複用連線,是不是意味著,需要等到上個連線time wait結束後才能再次使用?
所謂連線池複用,複用的一定是活躍的連線,所謂活躍,第一表明連線池裡的連線都是ESTABLISHED的,第二,連線池做為上層應用,會有定時的心跳去保持連線的活躍性。既然連線都是活躍的,那就不存在有TIME_WAIT的概念了,在上篇裡也有提到,TIME_WAIT是在主動關閉連線的一方,在關閉連線後才進入的狀態。既然已經關閉了,那麼這條連線肯定已經不在連線池裡面了,即被連線池釋放了。
2. 想請問下,作為負載均衡的機器隨機埠使用完的情況下大量time_wait,不調整你文字裡說的那三個引數,有其他的更好的方案嗎?
第一,隨機埠使用完,你可以透過調整/etc/sysctl.conf下的net.ipv4.ip_local_port_range配置,至少修改成 net.ipv4.ip_local_port_range=1024 65535,保證你的負載均衡伺服器至少可以使用6萬個隨機埠,也即可以有6萬的反向代理到後端的連線,可以支援每秒1000的併發(想一想,因為TIME_WAIT狀態會持續1分鐘後消失,所以一分鐘最多有6萬,每秒1000);如果這麼多埠都使用完了,也證明你應該加伺服器了,或者,你的負載均衡伺服器需要配置多個IP地址,或者,你的後端伺服器需要監聽更多的埠和配置更多的IP(想一下socket的五元組)
第二,大量的TIME_WAIT,多大量?如果是幾千個,其實不用擔心,因為這個記憶體和CPU的消耗有一些,但是是可以忽略的。
第三,如果真的量很大,上萬上萬的那種,可以考慮,讓後端的伺服器主動關閉連線,如果後端伺服器沒有外網的連線只有負載均衡伺服器的連線(主要是沒有NAT網路的連線),可以在後端伺服器上配置tw_recycle,然後同時,在負載均衡伺服器上,配置tw_reuse。
3. 如果想深入的學習一下網路方面的知識,有什麼推薦的?
學習網路比學一門程式語言“難”很多。所謂難,其實,是因為需要花很多的時間投入。我自己不算精通,只能說入門和理解。基本書可以推薦:《TCP/IP 協議詳解》,必讀;《TCP/IP高效程式設計:改善網路程式的44個技巧》,必讀;《Unix環境高階程式設計》,必讀;《Unix網路程式設計:卷一》,我只讀過卷一;另外,還需要熟悉一下網路工具,tcpdump以及wireshark,我的notes裡有一個一站式學習Wireshark:,也值得一讀。有了這些積累,可能就是一些實踐以及碎片化的學習和積累了。
寫在最後
這篇文章我斷斷續續寫了兩天,內容找了多個地方去驗證,包括看到Vincent Bernat的一篇文章以及Vincent在多個地方和別人的討論。期間,我也花了一些時間和Vincent探討了幾個我沒在tcp原始碼裡翻找到的有疑問的地方。
我力求比散佈在網上的文章做到準確並儘量整理的清晰一些。但是,也難免會
有疏漏或者有錯誤的地方,高手看到可以隨時指正,並和我討論,大家一起研究!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29096438/viewspace-2102355/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 系統調優,你所不知道的TIME_WAIT和CLOSE_WAITAI
- 你不知道的JavaScript——效能測試和調優JavaScript
- 更多你所不知道的 Linux 命令Linux
- Linux系統調優Linux
- TCP連線的TIME_WAIT和CLOSE_WAIT 狀態解說TCPAI
- 你所不知道的cssCSS
- 你所不知道的 POST
- 你所不知道的 Typescript 與 Redux 型別優化TypeScriptRedux型別優化
- 你所不知道的Typescript與Redux型別優化TypeScriptRedux型別優化
- 你所不知道的Java效能優化之String!Java優化
- Linux系統調優介紹Linux
- Linux系統效能調優技巧Linux
- 你所不知道的JavaScript 二JavaScript
- 你所不知道的JavaScript(三)JavaScript
- socket close和shutdown的區別,TIME_WAIT和CLOSE_WAIT,SO_REUSEADDRAI
- 你所不知道的前端效能優化不完全手冊前端優化
- 你所不知道的虛擬化和雲端計算
- 35 張圖帶你 MySQL 調優MySql
- 【MySQL】你所不知道的行復制(binlog_format=row)MySqlORM
- 你所不知道的 AI 進展AI
- 你所不知道的JavaScript陣列JavaScript陣列
- 你不得不知道的 MySQL 優化原理MySql優化
- Linux系統效能調優之效能分析Linux
- linux系統引數調優全解析Linux
- MySQL索引和SQL調優MySql索引
- 提升----你所不知道的JavaScript系列(3)JavaScript
- TCP埠狀態說明ESTABLISHED、TIME_WAIT、 CLOSE_WAITTCPAI
- (3)Linux效能調優之Linux檔案系統Linux
- linux系統關於kernel.sem調優Linux
- Linux優化之IO子系統監控與調優Linux優化
- 熟悉Linux系統的安全和優化Linux優化
- mysql效能的檢查和調優方法MySql
- Python: 你所不知道的星號 * 用法Python
- 你所不知道的 C# 10新特性C#
- JavaScript中你所不知道的陣列ArrayBufferJavaScript陣列
- 你所不知道的快速排序(js實現)排序JS
- 閉包—-你所不知道的JavaScript系列(4)JavaScript
- 調整time_waitAI