性能分析之TPS從300到750的程序-有解無憂

文章目錄

- 背景
- 問題1：TPS呈鋸齒狀，忽高忽低
- 問題2：調整資料庫引數
- 問題3：網路佇列
- 問題4：網路帶寬不足
- 問題5：資料問題
- 結論

背景

前幾天在 7DGroup 的群中，小鵬同學提了一個問題，

群里一頓討論，終于有了優化的結果，小鵬特此記錄，

先畫一個架構圖：
在這里插入圖片描述
畫架構圖是為了知道請求是從哪里到哪里，做性能分析一定先畫個圖，腦子里就會有路徑的概念了，

問題1：TPS呈鋸齒狀，忽高忽低

直接上圖如下：
在這里插入圖片描述

163 服務器（4c/8g）,cpu 使用率在 60 %左右，15 分鐘負載沒有超過 cpu 總核數，因此 163 服務器表現良好，還有上升空間，
164 服務器（2c/4g）本身配置較低,cpu 使用率在 60 %左右，15 分鐘負載跟 cpu 總核數基本持平，可作為優化點考慮，

在這里插入圖片描述

106 服務器（4c/8g）cpu 使用率在 60%，15分鐘負載也沒有超過 cpu 總核數，表現也算良好，還有一定的上升空間，
107 服務器（2c/8g）cpu 使用率已經達到 100%，15 分鐘負載已經超過 CPU 總核數一倍，明顯已經壓滿了，

在這里插入圖片描述

資料庫服務器（8c/16g）CPU 使用率在 30 左右，15 分鐘平均負載 2 低于 CPU 總核數 8，明顯壓力沒在資料庫上，

在這里插入圖片描述
詢問開發后得知，在該專案中加入了動態流量分布（備注如下），了解了動態流量分布的代碼邏輯之后，發現 TPS 的鋸齒狀的間隔時間正好是30s，TPS 鋸齒狀的原因是動態流量分布導致的，雖然在將流量分給空閑的服務器的時候，TPS 是高了，但是從配置低的 107 服務器來看，不管有沒有將它的流量分走，它都是撐不住的，

優化方案：

將107下線，找一臺和106配置相同的機器做測驗，

備注：動態流量分布即根據實際服務器的負載以及 CPU 使用率，動態的將流量分給相對空閑的服務器，每 30 s一次做輪詢，輪詢發現 A 服務器 CPU 以及負載過高，接下來的 30 s會將流量引流到空閑的服務器上，在做輪詢的同時，流量是均勻分布的，

問題2：調整資料庫引數

針對問題 1 將 107 下線，找一臺和 106 配置相同的機器做測驗，還是測驗相同的介面，

從全域監控角度來看，TPS 達到 610/2=300 多，服務器的 CPU 使用率約占到 60%，且各個服務器并沒有出現負載，由此可見服務器均沒有壓滿，還有上升空間，

但是使用MySQLreport來看，發現有幾個引數需要做下調整，

InnoDB Buffer Pool 這個引數值使用率到了100了，肯定是到了瓶頸，
在這里插入圖片描述
Tables 這個值也用到了100%，這塊需要修改下，

在這里插入圖片描述
Query cache 沒有開，Block Fragment 達到 100%

Block Fragmnt：是指記憶體塊碎片，如果你有一個回傳超小結果的海量查詢，默認的塊大小(即4KB)可能會導致大量的記憶體碎片，這個時候，需要降低"query_cache_min_res_unit"的值，比值越大，碎片越多，一般不建議超過20%，

在這里插入圖片描述

優化方案：

先調整下InnoDB Buffer Pool

show variables like 'innodb_buffer_pool%';
SET GLOBAL innodb_buffer_pool_size= 1207959552; #調成1g，后面又調整成了2g，需要根據實際情況調整

再調整：table_open_cache 和 query_cache，

set GLOBAL table_open_cache = 1000;
set GLOBAL query_cache_type = 1;

或修改組態檔：

sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf
innodb_buffer_pool_size = 2G
table_open_cache = 1000
query_cache_type = 1

調整 MySQL 配置引數之后，TPS 還是不高，大概 640/2=310 多，看來資料庫不是性能瓶頸，而且 TPS 還是不規律，還是每30s就波動一次，建議把動態分配流量去掉之后再測驗，

調整 MySQL 引數之后的 MySQLReport 資料：
在這里插入圖片描述

在這里插入圖片描述

問題3：網路佇列

去掉動態分配流量之后，還是相同的介面 TPS 較為穩定400 左右，

發現問題：所有服務器各個指標的使用率都不高，但是 CRM 和 MySQL之間的互相出現佇列，需要查找下原因，

在這里插入圖片描述

查看 106 服務器網卡中斷資訊，

watch -d -n 1 "cat /proc/softirqs"

發現 net_rx 分布不均勻，只有一個在忙，剩下三個都在偷懶，

在這里插入圖片描述
但是 si 不算太高，可以先不處理（將106物理機換成虛擬機），

接著分析，

TPS 仍然上不去，但是到 106 和 123 服務器上執行 top 命令再按 1 后發現 us 的使用率在個別 CPU 上面沖到了100，但是第三個CPU 的使用率才為1%，很明顯 CPU 使用率分布不均勻呀，

于是使用列印堆疊資訊的命令（如下）找到了 CPU 使用率較高的一行堆疊資訊，定位到了java的47行代碼，給到開發之后，順利解決，

top  #查找到cpu高的pid
top -Hp 12941   #尋找pid是12941的相關執行緒
/usr/java/jdk1.8.0_102/bin/jstack
jstack -l 12941 > 12941     #列印12941的堆疊資訊
printf '%x\n' 12951   #將執行緒12951轉換16進制
printf '%x\n' 13084
vi 12941   #進入堆疊檔案，尋找16進制的資訊

在這里插入圖片描述
通過 Java visualvm 鏈接之后，點擊執行緒 dump 按鈕，搜索關鍵詞 MySQL ，發現當前有直連 MySQL 的執行緒，是名叫 pool-6-thread-x 的執行緒，并且發現它只有4個，而且從執行緒運行狀態來看，這幾個執行緒全綠，明顯壓滿，懷疑是執行緒數量不夠用導致，