當(dāng)前位置：首頁 > 單片機(jī) > 架構(gòu)師社區(qū)

記一次單機(jī)系統(tǒng)的性能優(yōu)化：最后竟是?TCP?的鍋

時間：2021-12-08 17:11:42

關(guān)鍵字： TCP 性能優(yōu)化數(shù)據(jù)庫 PS

手機(jī)看文章

掃描二維碼
隨時隨地手機(jī)看文章

[導(dǎo)讀]前言這篇文章的主題是記錄一次Python程序的性能優(yōu)化，在優(yōu)化的過程中遇到的問題，以及如何去解決的。為大家提供一個優(yōu)化的思路，首先要聲明的一點(diǎn)是，我的方式不是唯一的，大家在性能優(yōu)化之路上遇到的問題都絕對不止一個解決方案。如何優(yōu)化首先大家要明確的一點(diǎn)是，脫離需求談優(yōu)化都是耍流氓，所...

前言

這篇文章的主題是記錄一次 Python 程序的性能優(yōu)化，在優(yōu)化的過程中遇到的問題，以及如何去解決的。為大家提供一個優(yōu)化的思路，首先要聲明的一點(diǎn)是，我的方式不是唯一的，大家在性能優(yōu)化之路上遇到的問題都絕對不止一個解決方案。

如何優(yōu)化

首先大家要明確的一點(diǎn)是，脫離需求談優(yōu)化都是耍流氓，所以有誰跟你說在xx機(jī)器上實(shí)現(xiàn)了百萬并發(fā)，基本上可以認(rèn)為是不懂裝懂了，單純的并發(fā)數(shù)完全是無意義的。其次，我們優(yōu)化之前必須要有一個目標(biāo)，需要優(yōu)化到什么程度，沒有明確目標(biāo)的優(yōu)化是不可控的。再然后，我們必須明確的找出性能瓶頸在哪里，而不能漫無目的的一通亂搞。

需求描述

這個項(xiàng)目是我在上家公司負(fù)責(zé)一個單獨(dú)的模塊，本來是集成在主站代碼中的，后來因?yàn)椴l(fā)太大，為了防止出現(xiàn)問題后拖累主站服務(wù)，所有由我一個人負(fù)責(zé)拆分出來。對這個模塊的拆分要求是，壓力測試 QPS 不能低于3萬，數(shù)據(jù)庫負(fù)載不能超過50%，服務(wù)器負(fù)載不能超過70%，單次請求時長不能超過70ms，錯誤率不能超過5%。環(huán)境的配置如下：服務(wù)器：4核8G內(nèi)存，CentOS7系統(tǒng)，SSD 硬盤
數(shù)據(jù)庫：MySQL 5.7，最大連接數(shù) 800
緩存: Redis，1G 容量。以上環(huán)境都是購買自騰訊云的服務(wù)。壓測工具：locust，使用騰訊的彈性伸縮實(shí)現(xiàn)分布式的壓測。需求描述如下：用戶進(jìn)入首頁，從數(shù)據(jù)庫中查詢是否有合適的彈窗配置，如果沒有，則繼續(xù)等待下一次請求、如果有合適的配置，則返回給前端。這里開始則有多個條件分支，如果用戶點(diǎn)擊了彈窗，則記錄用戶點(diǎn)擊，并且在配置的時間內(nèi)不再返回配置，如果用戶未點(diǎn)擊，則24小時后繼續(xù)返回本次配置，如果用戶點(diǎn)擊了，但是后續(xù)沒有配置了，則接著等待下一次。

重點(diǎn)分析

根據(jù)需求，我們知道了有幾個重要的點(diǎn)，1、需要找出合適用戶的彈窗配置，2、需要記錄用戶下一次返回配置的時間并記錄到數(shù)據(jù)庫中，3、需要記錄用戶對返回的配置執(zhí)行了什么操作并記錄到數(shù)據(jù)庫中。

調(diào)優(yōu)

我們可以看到，上述三個重點(diǎn)都存在數(shù)據(jù)庫的操作，不只有讀庫，還有寫庫操作。從這里我們可以看到如果不加緩存的話，所有的請求都壓到數(shù)據(jù)庫，勢必會占滿全部連接數(shù)，出現(xiàn)拒絕訪問的錯誤，同時因?yàn)?SQL 執(zhí)行過慢，導(dǎo)致請求無法及時返回。所以，我們首先要做的就是講寫庫操作剝離開來，提升每一次請求響應(yīng)速度，優(yōu)化數(shù)據(jù)庫連接。整個系統(tǒng)的架構(gòu)圖如下：

將寫庫操作放到一個先進(jìn)先出的消息隊(duì)列中來做，為了減少復(fù)雜度，使用了Redis 的 list 來做這個消息隊(duì)列。然后進(jìn)行壓測，結(jié)果如下：QPS 在 6000 左右 502 錯誤大幅上升至 30%，服務(wù)器 CPU 在 60%-70% 之間來回跳動，數(shù)據(jù)庫連接數(shù)被占滿 TCP 連接數(shù)為 6000 左右，很明顯，問題還是出在數(shù)據(jù)庫，經(jīng)過排查 SQL 語句，查詢到原因就是找出合適用戶的配置操作時每次請求都要讀取數(shù)據(jù)庫所導(dǎo)致的連接數(shù)被用完。因?yàn)槲覀兊倪B接數(shù)只有 800，一旦請求過多，勢必會導(dǎo)致數(shù)據(jù)庫瓶頸。好了，問題找到了，我們繼續(xù)優(yōu)化，更新的架構(gòu)如下：

我們將全部的配置都加載到緩存中，只有在緩存中沒有配置的時候才會去讀取數(shù)據(jù)庫。接下來我們再次壓測，結(jié)果如下：

QPS 壓到 2萬左右的時候就上不去了，服務(wù)器 CPU 在 60%-80% 之間跳動，數(shù)據(jù)庫連接數(shù)為300個左右，每秒TPC連接數(shù)為1.5萬左右。這個問題是困擾我比較久的一個問題，因?yàn)槲覀兛梢钥吹剑覀?萬的 QPS，但是TCP 連接數(shù)卻并沒有達(dá)到2萬，我猜測，TCP連接數(shù)就是引發(fā)瓶頸的問題，但是因?yàn)槭裁丛蛩l(fā)的暫時無法找出來。

這個時候猜測，既然是無法建立 TCP 連接，是否有可能是服務(wù)器限制了 socket 連接數(shù)，驗(yàn)證猜測，我們看一下，在終端輸入 ulimit -n 命令，顯示的結(jié)果為65535，看到這里，覺得 socket 連接數(shù)并不是限制我們的原因，為了驗(yàn)證猜測，將 socket 連接數(shù)調(diào)大為100001.再次進(jìn)行壓測，結(jié)果如下：QPS壓到2.2萬左右的時候就上不去了，服務(wù)器cpu在60%-80%之間跳動，數(shù)據(jù)庫連接數(shù)為300個左右，每秒 TCP 連接數(shù)為1.7萬左右。雖然有一點(diǎn)提升，但是并沒有實(shí)質(zhì)性的變化，接下來的幾天時間，我發(fā)現(xiàn)都無法找到優(yōu)化的方案，那幾天確實(shí)很難受，找不出來優(yōu)化的方案，過了幾天，再次將問題梳理了一遍，發(fā)現(xiàn)，雖然socket連接數(shù)足夠，但是并沒有全部被用上，猜測，每次請求過后，tcp連接并沒有立即被釋放，導(dǎo)致socket無法重用。經(jīng)過查找資料，找到了問題所在，

TCP 鏈接在經(jīng)過四次握手結(jié)束連接后并不會立即釋放，而是處于 timewait 狀態(tài)，會等待一段時間，以防止客戶端后續(xù)的數(shù)據(jù)未被接收。

好了，問題找到了，我們要接著優(yōu)化，首先想到的就是調(diào)整 TCP 鏈接結(jié)束后等待時間，但是 Linux 并沒有提供這一內(nèi)核參數(shù)的調(diào)整，如果要改，必須要自己重新編譯內(nèi)核，幸好還有另一個參數(shù) net.ipv4.tcp_max_tw_buckets， timewait 的數(shù)量，默認(rèn)是180000。我們調(diào)整為 6000，然后打開 timewait 快速回收，和開啟重用，完整的參數(shù)優(yōu)化如下：

#timewait 的數(shù)量，默認(rèn)是 180000。net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.ip_local_port_range = 1024 65000
#啟用 timewait 快速回收。net.ipv4.tcp_tw_recycle = 1#開啟重用。允許將 TIME-WAIT sockets 重新用于新的 TCP 連接。net.ipv4.tcp_tw_reuse = 1 我們再次壓測，結(jié)果顯示：QPS 5萬，服務(wù)器 CPU 70%，數(shù)據(jù)庫連接正常，TCP 連接正常，響應(yīng)時間平均為 60ms，錯誤率為 0%。

結(jié)語

到此為止，整個服務(wù)的開發(fā)、調(diào)優(yōu)、和壓測就結(jié)束了?；仡欉@一次調(diào)優(yōu)，得到了很多經(jīng)驗(yàn)，最重要的是，深刻理解了web開發(fā)不是一個獨(dú)立的個體，而是網(wǎng)絡(luò)、數(shù)據(jù)庫、編程語言、操作系統(tǒng)等多門學(xué)科結(jié)合的工程實(shí)踐，這就要求web開發(fā)人員有牢固的基礎(chǔ)知識，否則出現(xiàn)了問題還不知道怎么分析查找。ps：服務(wù)端開啟了 tcp_tw_recycle 和 tcp_tw_reuse是會導(dǎo)致一些問題的，我們?yōu)榱藘?yōu)化選擇犧牲了一部分，獲得另一部分，這也是我們要明確的，具體的問題可以查看耗子叔的文章TCP 的那些事兒（上）

本站聲明：本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布，目的在于傳遞更多信息，并不代表本站贊同其觀點(diǎn)，本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者，如若文章內(nèi)容侵犯您的權(quán)益，請及時聯(lián)系本站刪除。

換一批

與傳統(tǒng)的驅(qū)動方式相比，共陰恒流驅(qū)動在能效有哪些優(yōu)勢

LED驅(qū)動電源的輸入包括高壓工頻交流(即市電)、低壓直流、高壓直流、低壓高頻交流(如電子變壓器的輸出)等。

關(guān)鍵字：驅(qū)動電源

[電源]

工業(yè)電機(jī)驅(qū)動電源設(shè)計(jì)：反電動勢抑制與過流保護(hù)的集成方案

在工業(yè)自動化蓬勃發(fā)展的當(dāng)下，工業(yè)電機(jī)作為核心動力設(shè)備，其驅(qū)動電源的性能直接關(guān)系到整個系統(tǒng)的穩(wěn)定性和可靠性。其中，反電動勢抑制與過流保護(hù)是驅(qū)動電源設(shè)計(jì)中至關(guān)重要的兩個環(huán)節(jié)，集成化方案的設(shè)計(jì)成為提升電機(jī)驅(qū)動性能的關(guān)鍵。

關(guān)鍵字：工業(yè)電機(jī) 驅(qū)動電源

[電源]

如何解決 LED 驅(qū)動電源的易損壞問題

LED 驅(qū)動電源作為 LED 照明系統(tǒng)的 “心臟”，其穩(wěn)定性直接決定了整個照明設(shè)備的使用壽命。然而，在實(shí)際應(yīng)用中，LED 驅(qū)動電源易損壞的問題卻十分常見，不僅增加了維護(hù)成本，還影響了用戶體驗(yàn)。要解決這一問題，需從設(shè)計(jì)、生...

關(guān)鍵字：驅(qū)動電源照明系統(tǒng) 散熱

[電力電工電路]

LED設(shè)計(jì)中LED驅(qū)動電源的公式

根據(jù)LED驅(qū)動電源的公式，電感內(nèi)電流波動大小和電感值成反比，輸出紋波和輸出電容值成反比。所以加大電感值和輸出電容值可以減小紋波。

關(guān)鍵字： LED 設(shè)計(jì) 驅(qū)動電源

[汽車電子]

EV主驅(qū)IGBT隔離驅(qū)動電源方案選擇問題探討

電動汽車(EV)作為新能源汽車的重要代表，正逐漸成為全球汽車產(chǎn)業(yè)的重要發(fā)展方向。電動汽車的核心技術(shù)之一是電機(jī)驅(qū)動控制系統(tǒng)，而絕緣柵雙極型晶體管(IGBT)作為電機(jī)驅(qū)動系統(tǒng)中的關(guān)鍵元件，其性能直接影響到電動汽車的動力性能和...

關(guān)鍵字：電動汽車新能源驅(qū)動電源

[電源]

合理的驅(qū)動電源方案成為大功率區(qū)域照明的主流選擇

在現(xiàn)代城市建設(shè)中，街道及停車場照明作為基礎(chǔ)設(shè)施的重要組成部分，其質(zhì)量和效率直接關(guān)系到城市的公共安全、居民生活質(zhì)量和能源利用效率。隨著科技的進(jìn)步，高亮度白光發(fā)光二極管(LED)因其獨(dú)特的優(yōu)勢逐漸取代傳統(tǒng)光源，成為大功率區(qū)域...

關(guān)鍵字：發(fā)光二極管驅(qū)動電源 LED

[消費(fèi)電子]