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

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),吐魯番企業(yè)網(wǎng)站建設(shè),吐魯番品牌網(wǎng)站建設(shè),網(wǎng)站定制,吐魯番網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷(xiāo),網(wǎng)絡(luò)優(yōu)化,吐魯番網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專(zhuān)業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

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

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

Nginx Connection 數(shù)量飆升

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

MySQL Connection 數(shù)量飆升

事故過(guò)程中的分析

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

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

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

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

（所以，遇到自己解決不了的問(wèn)題時(shí)，及時(shí)找大神幫忙。你們，學(xué)會(huì)了嗎？）

為什么會(huì)有 Keepalive

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

TCP Keepalive

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

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

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

到此，相信大家對(duì)“TCP Keepalive對(duì)系統(tǒng)性能有什么影響”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！