記一次性能優化,單臺4核8G機器支撐5萬QPS

朱小厮 2021-09-19 09:19:20 阅读数:940

一次性 一次 性能 8g qps
點擊上方“朱小厮的博客”,選擇“設為星標”
後臺回複"書",獲取
後臺回複“k8s”,可領取k8s資料

前言

這篇文章的主題是記錄一次程序的性能優化,在優化的過程中遇到的問題,以及如何去解决的。

為大家提供一個優化的思路,首先要聲明的一點是,我的方式不是唯一的,大家在性能優化之路上遇到的問題都絕對不止一個解决方案。

如何優化

首先大家要明確的一點是,脫離需求談優化都是耍流氓。所以,有誰跟你說在 xx 機器上實現了百萬並發,基本上可以認為是不懂裝懂了,單純的並發數完全是無意義的

其次,我們優化之前必須要有一個目標。需要優化到什麼程度,沒有明確目標的優化是不可控的。再然後,我們必須明確的找出性能瓶頸在哪裏,而不能漫無目的的一通亂搞。

需求描述

這個項目是我在上家公司負責一個單獨的模塊。本來是集成在主站代碼中的,後來因為並發太大,為了防止出現問題後拖累主站服務,所有由我一個人負責拆分出來。

對這個模塊的拆分要求是,壓力測試 QPS 不能低於 3 萬,數據庫負責不能超過 50%,服務器負載不能超過 70%,單次請求時長不能超過 70ms,錯誤率不能超過 5%。

環境的配置如下: 

  • 服務器:4 核 8G 內存,CentOS 7 系統,SSD 硬盤 

  • 數據庫:MySQL 5.7,最大連接數 800 

  • 緩存:Redis,1G容量。以上環境都是購買自騰訊雲的服務。

  • 壓測工具:Locust,使用騰訊的彈性伸縮實現分布式的壓測。

需求描述如下:

  1. 用戶進入首頁,從數據庫中查詢是否有合適的彈窗配置。

  2. 如果沒有,則繼續等待下一次請求、如果有合適的配置,則返回給前端。

這裏開始則有多個條件分支

  • 如果用戶點擊了彈窗,則記錄用戶點擊,並且在配置的時間內不再返回配置;

  • 如果用戶未點擊,則24小時後繼續返回本次配置;

  • 如果用戶點擊了,但是後續沒有配置了,則接著等待下一次。

重點分析

根據需求,我們知道了有幾個重要的點:

  • 需要找出合適用戶的彈窗配置,

  • 需要記錄用戶下一次返回配置的時間並記錄到數據庫中,

  • 需要記錄用戶對返回的配置執行了什麼操作並記錄到數據庫中。

調優

我們可以看到,上述三個重點都存在數據庫的操作,不只有讀庫,還有寫庫操作。

從這裏我們可以看到,如果不加緩存的話,所有的請求都壓到數據庫,勢必會占滿全部連接數,出現拒絕訪問的錯誤。同時因為 SQL 執行過慢,導致請求無法及時返回。

所以,我們首先要做的就是將寫庫操作剝離開來。提昇每一次請求響應速度,優化數據庫連接。

整個系統的架構圖如下:

c95a0838308ade7f3dd4509fa833c50d.png

將寫庫操作放到一個先進先出的消息隊列中來做。為了减少複雜度,使用了 Redis 的 list 來做這個消息隊列。

然後進行壓測,結果如下:

  • QPS 在 6000 左右 502 錯誤大幅上昇至 30%;

  • 服務器 CPU 在 60%-70% 之間來回跳動;

  • 數據庫連接數被占滿 TCP 連接數為 6000 左右。

很明顯,問題還是出在數據庫

經過排查 SQL 語句,查詢到原因就是:找出合適用戶的配置操作時每次請求都要讀取數據庫所導致的連接數被用完。

因為我們的連接數只有 800,一旦請求過多勢必會導致數據庫瓶頸。好了,問題找到了,我們繼續優化。

更新的架構如下:

dde78f219758cdbc447bfd352eadbdf0.png

我們將全部的配置都加載到緩存中,只有在緩存中沒有配置的時候才會去讀取數據庫。

接下來我們再次壓測,結果如下:

  • QPS 壓到 2 萬左右的時候就上不去了;

  • 服務器 CPU 在 60%-80% 之間跳動;

  • 數據庫連接數為 300 個左右,每秒 TCP 連接數為 1.5 萬左右。

這個問題是困擾我比較久的一個問題。因為我們可以看到,我們 2 萬的 QPS,但是 TCP 連接數卻並沒有達到 2 萬

我猜測,TCP 連接數就是引發瓶頸的問題,但是因為什麼原因所引發的暫時無法找出來。

這個時候猜測,既然是無法建立 TCP 連接,是否有可能是服務器限制了 socket 連接數。

驗證猜測,我們看一下,在終端輸入 ulimit -n 命令,顯示的結果為 65535。看到這裏,覺得 socket 連接數並不是限制我們的原因,為了驗證猜測,將 socket 連接數調大為100001。

再次進行壓測,結果如下:

  • QPS 壓到 2.2 萬左右的時候就上不去了;

  • 服務器 CPU 在 60%-80% 之間跳動;

  • 數據庫連接數為 300 個左右,每秒 TCP 連接數為 1.7 萬左右。

雖然有一點提昇,但是並沒有實質性的變化。

接下來的幾天時間,我發現都無法找到優化的方案。那幾天確實很難受,找不出來優化的方案,過了幾天再次將問題梳理了一遍,發現雖然 socket 連接數足够,但是並沒有全部被用上。猜測每次請求過後,TCP 連接並沒有立即被釋放,導致 socket 無法重用。

經過查找資料,找到了問題所在:

TCP 鏈接在經過四次握手結束連接後並不會立即釋放,而是處於 timewait 狀態。會等待一段時間,以防止客戶端後續的數據未被接收。

好了,問題找到了,我們要接著優化。

首先想到的就是調整 TCP 鏈接結束後等待時間。但是 Linux並沒有提供這一內核參數的調整,如果要改必須要自己重新編譯內核。幸好還有另一個參數net.ipv4.tcp_max_tw_buckets, timewait 的數量。默認是 180000。我們調整為6000。然後打開 timewait 快速回收和開啟重用。

完整的參數優化如下:

#timewait 的數量,默認是 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
我們再次壓測,結果顯示:
  • QPS 5萬,服務器 CPU 70%;

  • 數據庫連接正常,TCP 連接正常;

  • 響應時間平均為 60ms,錯誤率為 0%。

結語

到此為止,整個服務的開發、調優、和壓測就結束了。回顧這一次調優,得到了很多經驗。最重要的是,深刻理解了Web 開發不是一個獨立的個體,而是網絡、數據庫、編程語言、操作系統等多門學科結合的工程實踐。這就要求 Web 開發人員有牢固的基礎知識,否則出現了問題還不知道怎麼分析查找。

來源:https://segmentfault.com/a/1190000018075241

  

想知道更多?掃描下面的二維碼關注我後臺回複"技術",加入技術群
後臺回複“k8s”,可領取k8s資料
【精彩推薦】
版权声明:本文为[朱小厮]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/09/20210919091919852T.html