TCP Keepalive對系統(tǒng)性能有什么影響

本篇內容主要講解“TCP Keepalive對系統(tǒng)性能有什么影響”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“TCP Keepalive對系統(tǒng)性能有什么影響”吧!

事故發(fā)生時的情況

話說當天 15:30分 左右收到 Nginx 告警信息（感謝運維童鞋的努力，讓我們可以實時掌握系統(tǒng)運行情況），提示 Nginx Connection 數(shù)量超出常規(guī)設置。作為業(yè)界還算有點名聲的網(wǎng)站，OSCHINA 社區(qū)網(wǎng)站流量突然飆升的情況可以說是家常便飯，一般情況下 Nginx Connection 超出我們設置的告警閥值之后，過段時間自然就會再回落（可能有些爬蟲突然來訪、或者部分善意的童鞋發(fā)送測試請求等）。所以，一開始并沒有特別在意這個告警信息，只是等著「過段時間」即可。為了保證網(wǎng)站各項服務不出問題，我還是很小心的看了下集群中各個應用的情況 —— 一切正常如故。這時候，我也做好了準備，如果流量繼續(xù)攀升導致服務收到影響的話，集群中的其他幾臺應用也要通過 upstream 開啟分流模式，從而保證整站服務運行正常。

Nginx Connection 數(shù)量飆升

正在我猶豫是不是需要開啟備用的其他幾個應用分流時，突然又收到了 MySQL Connection 告警信息，這才開始意識到問題的嚴重性。一般情況下，我們配置的 MySQL 數(shù)據(jù)庫鏈接是足夠集群中的所有應用正常讀寫數(shù)據(jù)的，但如果 MySQL 連接數(shù)出現(xiàn)飆升的問題，集群中就可能出現(xiàn)部分節(jié)點無法拿到數(shù)據(jù)庫連接的情況，從而導致部分用戶請求受阻。就在短短幾分鐘之內，我們配置的數(shù)據(jù)庫連接池被占滿，大量用戶請求因為無法獲取數(shù)據(jù)庫連接而開始緩慢，甚至部分用戶開始出現(xiàn)無法訪問、打開很慢等情況。

MySQL Connection 數(shù)量飆升

事故過程中的分析

OSCHINA 網(wǎng)站大量使用了緩存技術，因此 MySQL 數(shù)據(jù)庫的壓力基本不大，QPS 也不會很高。但是此時，MySQL 連接數(shù)已經(jīng)超過3k而且看似根本停不下來。這就勾起了我的好奇心：到底 MySQL 在做什么事情？為什么會有這么多的連接呢？如果出現(xiàn)個別很復雜的查詢語句卡住，導致出現(xiàn)很多慢查詢的話，其他正常的請求也會逐漸無法獲取連接從而導致應用完全失去響應。立馬 ssh 到 MySQL 那臺機器查看了機器情況以及 MySQL 慢查詢，卻發(fā)現(xiàn)很多以前只需要幾十毫秒執(zhí)行時間的 SQL 查詢，如今卻穩(wěn)穩(wěn)地卡在那里沒有任何響應或者查詢耗費很久時間。這樣看來，并不是我們的應用出發(fā)了某些復雜的查詢導致 MySQL 查詢效率降低從而出現(xiàn)「卡殼」，而單純只是前端 Nginx 那邊的流量飆升導致的。

確定了各項應用的基本狀態(tài)，發(fā)現(xiàn)已經(jīng)有部分應用響應已經(jīng)出現(xiàn)不及時或者沒響應的情況。同時，有好幾位同事已經(jīng)在Q群里 at 我反饋社區(qū)網(wǎng)站打不開。眼下迫切需要完成的事情是：流量飆升是什么問題造成的？于是立馬登錄到前端 Nginx 機器查詢訪問日志，發(fā)現(xiàn)有幾個請求量很大的 IP（別問我是怎么發(fā)現(xiàn)的，這事情很多方法可以做），于是當機立斷在前端 Nginx 配置了 deny 參數(shù)封掉了那幾個搞事情的 IP。默默觀察，果然沒過多久，數(shù)據(jù)庫連接開始下降，應用逐漸開始恢復，之后 MySQL 告警恢復正常。隨后又觀察了集群中幾個應用的狀態(tài)，為了避免出現(xiàn)其他意外情況，重啟并配置了幾個應用準備應不時之需。這時，離故障出現(xiàn)（開始收到告警信息）已經(jīng)有差不多十多分鐘的時間，我們的應用都已經(jīng)恢復，MySQL Connection 也在逐漸降低至我們可以接受的合理范圍內，網(wǎng)站也能正常訪問了。但神奇的是，Nginx Connection 告警一直在繼續(xù)。難道，還有其他沒有發(fā)現(xiàn)的 IP 在搞事情么？錄到前端 Nginx 所在的機器之后卻發(fā)現(xiàn)，似乎系統(tǒng)有明顯的卡頓情況出現(xiàn)。top 看了一眼才知道 CPU 和內存莫名其妙的飆升許多。本想著流量恢復正常之后，那些莫名其妙被打開的 Nginx 連接會自動釋放，但是遲遲沒看到有變化。

這下事情就很清晰了：流量突然飆升導致 Nginx Connection 數(shù)量大增，同時也會帶動應用的 MySQL Connection 數(shù)量大增（這個過程也正好可以通過我收到的告警過程得到驗證）。在解決了問題且流量恢復正常之后，應用層的 MySQL Connection 逐步釋放并得到恢復。然而，那些已經(jīng)失效的網(wǎng)絡請求造成的 Nginx Connection 卻始終無法被釋放。所以，Nginx Connection 告警一直沒有停止。

這時，雖然各項應用都已經(jīng)恢復，但 Nginx Connection 告警一直未停止，令人不厭其煩。沒辦法只能向運維大神 @atompi 求救了。跟大神講明了情況之后，大神果斷登錄到前端機器并查看了 Nginx 運行情況，沒過多久回復說：很多底層 TCP 連接依舊不能正常釋放，導致 Nginx Connection 居高不下。隨即，我們簡單驗證了這個想法，發(fā)現(xiàn)系統(tǒng)默認配置的 TCP Keepalive 失效時間竟然需要兩個小時之久（可能一開始配置系統(tǒng)參數(shù)時疏忽了）。馬修改了相關配置，徹底停止再重啟 Nginx 之后，一切恢復正常，Nginx Connection 數(shù)量也下降并恢復到正常值。

（所以，遇到自己解決不了的問題時，及時找大神幫忙。你們，學會了嗎？）

為什么會有 Keepalive

想必大家都知道 HTTP 的 Request -> Response 無狀態(tài)模式，在早期 HTTP 1.0 時代每個請求執(zhí)行完成之后，作為 OSI七層模型 中傳輸層 TCP 連接是需要斷開連接的，甚至每一次的請求中都需要 TCP三次握手四次揮手 才能完整處理。這樣的處理方式雖然保證了網(wǎng)絡傳輸?shù)臏蚀_性及完整性，但效率實在不高。為了能夠提升效率，在后來的 HTTP 1.1 規(guī)范中把 Connection 頭寫入了標準，并且默認啟用。通過這個標準的定義，約束底層的 TCP 連接不會立馬被釋放（復用 TCP 連接），從而提升網(wǎng)絡傳輸效率?，F(xiàn)代瀏覽器基本上都默認會開啟 Connection: keep-alive 以提升訪問速度。（現(xiàn)代 web 服務器都具備自己的 keepalive_timeout 或者類似的配置，具體參數(shù)可能會有不同，但大致都是同樣的作用。關于 HTTP Keepalive 以及 web 性能的分析，請閱讀 《HTTP Keepalive Connections and Web Performance》）

TCP Keepalive

拋開 HTTP Keepalive 不談，TCP Keepalive 并不是一個大家約定的標準，但卻被廣泛支持。當網(wǎng)絡上的連接已經(jīng)建立之后，如果應用層很久沒有傳輸數(shù)據(jù)、或者其他意外情況發(fā)生時，當前連接是不是應該繼續(xù)保持呢？TCP Keepalive 正是檢測 TCP 連接是否需要保持亦或需要斷開的檢測依據(jù)。TCP Keepalive 的機制是：它會在隔開一段時間之后發(fā)送幾次沒有數(shù)據(jù)內容的網(wǎng)絡請求來判斷當前連接是不是應該繼續(xù)保留。在 CentOS 系統(tǒng)中 /etc/sysctl.conf 文件有關于 TCP Keepalive 的幾個重要參數(shù)：

tcp_keepalive_time = 7200 (seconds)
tcp_keepalive_intvl = 75 (seconds)
tcp_keepalive_probes = 9 (number of probes)

上面幾個參數(shù)可以通俗的理解為： TCP Keepalive 進程會等待 7200秒 之后發(fā)送第一個測試數(shù)據(jù)包來檢測當前連接是否應該保持，然后間隔 75秒 再檢測，一共檢測 9 次。 這幾個數(shù)字是默認值，根據(jù)自己的實際情況來做一定的調整即可達到更好的網(wǎng)絡吞吐目的。

到此，相信大家對“TCP Keepalive對系統(tǒng)性能有什么影響”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！