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

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

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

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

Nginx Connection 數(shù)量飆升

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

MySQL Connection 數(shù)量飆升

事故過程中的分析

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

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

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

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

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

為什么會有 Keepalive

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

TCP Keepalive

拋開 HTTP Keepalive 不談，TCP Keepalive 并不是一個大家約定的標(biāo)準(zhǔn)，但卻被廣泛支持。當(dāng)網(wǎng)絡(luò)上的連接已經(jīng)建立之后，如果應(yīng)用層很久沒有傳輸數(shù)據(jù)、或者其他意外情況發(fā)生時，當(dāng)前連接是不是應(yīng)該繼續(xù)保持呢？TCP Keepalive 正是檢測 TCP 連接是否需要保持亦或需要斷開的檢測依據(jù)。TCP Keepalive 的機制是：它會在隔開一段時間之后發(fā)送幾次沒有數(shù)據(jù)內(nèi)容的網(wǎng)絡(luò)請求來判斷當(dāng)前連接是不是應(yīng)該繼續(xù)保留。在 CentOS 系統(tǒng)中 /etc/sysctl.conf 文件有關(guān)于 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ù)包來檢測當(dāng)前連接是否應(yīng)該保持，然后間隔 75秒 再檢測，一共檢測 9 次。這幾個數(shù)字是默認值，根據(jù)自己的實際情況來做一定的調(diào)整即可達到更好的網(wǎng)絡(luò)吞吐目的。

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

網(wǎng)站標(biāo)題：TCPKeepalive對系統(tǒng)性能有什么影響
網(wǎng)頁鏈接：http://www.rwnh.cn/article40/jjeoho.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供Google、全網(wǎng)營銷推廣、營銷型網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化、ChatGPT、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)