@性能瓶頸案例及定位方法，純手打，轉載請注明出處
性能測驗程序中遇到瓶頸，怎么辦
總結下這些年遇到最常見的性能瓶頸，回應時間不達標
一般測驗：這里顯示資料怎么這么慢？
開發：…
記住，測驗不單單要發現問題，還要定位問題出現的原因,找出bug只是測驗的責任，定位到問題才是測驗能力的體現
話不多說，上干貨
資料在哪
最簡單的模型：
請求：客戶端→應用服務器→資料庫
回應：資料庫→應用服務器→客戶端
- 正常使用中客戶端發送請求是用戶的網路，這個沒什么必要去考慮，因為我們性能測驗的目的檢查的是服務器的性能，用戶愛用啥就用啥，最多就是看下請求資料大小問題，發送的資料多了，要么壓縮，要么就得分拆，別往一個請求里塞；
- 資料庫回傳資料檢查有沒有慢查詢
- 應用服務器接收請求，訪問資料庫后處理資料，通俗來講就是后端寫的邏輯代碼，新手總寫一堆if做判斷，老手已然呼叫方法風生水起
網路分析定位
出現回應時間過長，第一步排查網路
1、調出服務器的access.log
2、通過里面的request_time與upstream_response_time進行對比
3、如果request_time遠大于upstream_response_time 則說明請求網路帶寬不足，這時候需要增加帶寬或者壓縮傳輸資料或者分拆請求資料
解釋一下
request_time：
作用是收到請求開始到發送完回應資料這個時間
upstream_response_time：
從與服務器建立連接到接收完資料并關閉連接的時間
cpu占用率高居不下
那如果沒有問題怎么搞？
那就要看下服務器的cpu了
top之后 按Shift+P鍵就能按cpu占用情況排序啦
如果發現有行程占用巨高，那么，恭喜你，你找到原因了
我之前遇到有個服務的行程居然cpu占用率高達70%,然后另一個服務正是對應回應時間變慢的功能介面，妥妥的架構不合理啊，最后解決辦法是搭建了分布式服務器（當然這是開發干的活，我只是好奇咨詢了一下），走到現在來看，可能微服務架構會更好一點
快取過多也會導致服務器回應變慢
1）按正常走下去，cpu如果么得問題，那記憶體也得瞅瞅
查看記憶體用到命令 free -m
total是總記憶體
used是已用記憶體
free是可用記憶體
2）再用top查看下記憶體，大概計算一下是不是等于剛查到的used的值
3）為什么這樣做，因為我遇到過這種情況，已用記憶體是12GB，但是top查出來的記憶體總和大概9GB，那剩下的3GB呢，跑哪去了？
4）用cat /proc/meminfo查看記憶體更加詳細的資訊
我發現不見了的3GB近乎全部在Slab（Slab是用于存放內核資料結構快取）下面；
5）通過slabtop命令查看這部分記憶體的使 用情況，發現大部分記憶體被dentry_cache占用了；
把問題反饋給開發后，開發通過釋放Slab占用的cache記憶體空間解決
解決命令需要sudu的權限
sync
sudo sysctl -w vm.drop_caches=3
sudo sysctl -w vm.drop_caches=0 #recovery drop_caches
資料庫慢查詢
遇到過一個問題，表中沒有創建索引導致回應時間長，CPU占用變高
有個介面120的tps，cpu使用率卻高達90%，回應時間大于1秒，
定位問題
進入mysql的命令模式
set global slow_query_log = on; 開啟慢查詢日志
set long_query_time = 1; 設定慢查詢時長為1s
set globle log_output = 路徑/檔案名 設定慢查詢日志檔案存放路徑
意味著查詢超過1s的sql陳述句寫入慢查詢日志
通過進入資料庫定位發現該陳述句沒有創建索引
解決后tps上升到240，回應時間下降到280ms左右，
問：怎么看有沒有創建索引？
答：mysql命令模式輸入SHOW INDEX FROM 表名
碼字累了，還有一些坑，慢慢更吧~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/183873.html
標籤：其他