性能問題彙總

  1. 壓測端硬件、網絡或軟件

     1.域名壓測致使大量請求流向外網,並出現流量清洗java

  •   現象:測試結果顯示tps很是低,請求量壓測端統計與服務端統計相差很大
  • 解題思路:確認壓測域名是否走內網IP,ping+壓測域名獲取到的ip地址與運維確認是否爲內網ip,若不支持ping,可嘗試tracert。肯定未走內容可能須要運維協助,在入口機器(nginx)配置host將域名指定到某臺或多臺服務器上。

   2.Jmeter測試報告顯示出現各類異常報錯信息,如:500、50二、non  http  responsecodemysql

  • 現象:控制檯錯誤請求量增長、根據錯誤類型尋找錯誤提示、錯誤
  • 解決思路:肯定錯誤類型,根據錯誤類型尋找錯誤真實緣由。(500:服務器內部錯誤,沒法完成請求、502:充當網關或代理的服務器,從遠端服務器接收到了一個無效的請求、400:客戶端請求的語法錯誤,服務器沒法理解、404:服務器沒法根據客戶端的請求找到資源(網頁))其餘狀態詳解見:blog.csdn.net/t_332741160…

    3.Jmeter  Jvm 分配內存不足致使內存溢出nginx

  • 現象:控制檯出現報錯,出現OutOfMemoryError
  • 解決思路:Windows中對應的文件路徑:Jmeter_Home/bin/jmeter.bat
  •       set HEAP=-Xms512m -Xmx512m
  •       set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
  •      Linux下對應文件路徑:Jmeter_Home/bin/jmeter
  •      HEAP=-Xms512m -Xmx512m
  •      NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
  •      一般就meter默認的HEAP -Xms512:初始化內存大小,-Xmx512m:最大堆內存。須要增 加內存的時候須要注意
  •  - 通常會將-Xms和-Xmx兩個值配置爲相同值,目的是爲了能在java的GC完成後堆內存不須要從新分隔計算堆區大小而浪費資源
  • - -Xms和-Xmx兩個值修改的值通常須要爲512的整數倍
  • - -Xmx不要超過物理內存的50%,超出可能會致使jmeter變慢
  • - 當腳本執行過程當中出現內存溢出outfmenmory錯誤,先嚐試增長增長HEAP的-Xms和-Xmx
  • - JDK32位的電腦Xmx不能超過1500m,最大1378m.不然在啓動Jmeter時會報錯
  • - -XX:MaxNewSize:新生代可被分配的內存的最大上限,這個值應該小於-Xmx的值,由於新生代佔內存來自整個堆內存一般設置爲-Xmx的三分之一
  • - jvm在執行GC時,會中止工做。MaxnewSize的增大,能夠下降GC頻率

   4.端口被佔用web

  • 現象:併發6000次/s,錯誤率高達66.89%
  • 錯誤日誌:Non HTTP response code:java.net.BindException,Non HTTP response message: Address already in use
  • 緣由:Jmeter windows壓測環境:Windows Server 缺失MaxUserPort和TcpTimedWaitDelay;限制了tcpip最大鏈接數和響應時間
  • 解決辦法:註冊表HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters;添加MaxUserPort和TcpTimedWaitDelay,分別設置值爲6553四、30,以增大可分配的tcp鏈接端口數、減少處於TIME_WAIT狀態的鏈接的生存時間

2.服務器硬件、網絡

1.壓測方式使用的是域名壓測,走的外部網絡,因此壓測壓力未能如預期同樣對目標服務器施壓,致使TPS很是低,服務器各類資源消耗也很小。redis

  • 現象:使用單臺壓測機器分別進行了100、500、1000進程壓測,500個線程的時候tps只有180-200.再增長壓力Tps上不去。
  • 解決思路:一開始覺得服務器鏈接數有問題,修改Tomcat最大鏈接數無效果。最後統計壓測端請求量與被測服務器接收請求量相差比較大
  • 解決方式:網絡入口配置host/dns的形式將指定域名的請求所有指向測試服務器(對應IP)

2.原有集羣到達最大限制,TPS達到280左右就出現CPU適應太高狀況sql

  • 現象:2臺web和4臺service在調整配置、代碼優化出現瓶頸,使用單臺壓測機器分別進行了100、500、1000進程壓測,500個線程的時候tps達到280位最高併發,90%響應時間最小並且CPU等資源正常,增長併發數到1000後tps下降、響應時間增長CPU使用率>70%
  • 解決方法:增長集羣機器

3. 中間件

1.Tomcat鏈接處瓶頸,致使高併發時出現接口超時數據庫

  • 現象:500線程組併發的時候,服務端日誌出現大量超時提示,排查Tomcat線程數配置的時候發現maxThreads(線程池中最大活躍線程數)爲100
  • 解決:修改maxThreads、accept-count爲500後錯誤解決
  • - maxThreads:最大請求進程數,默認設置爲200,該值設置應該考慮實際狀況,當
  • 請求進程數達到最大值時,通常會出現錯誤提示:SEVERE: All threads (150) are currently busy, waiting. Increase maxThreads (150) or check the servlet status
  • - accept:可接隊列長度,與maxThreads對應,當達到maxThreads後進入等待隊列。而等待隊列數達到最大值後,再有新請求後就會出現refuse connection(拒絕請求)

2.502 Bad Gateway和504 Gateway  Time-outwindows

  • 問題定位:tomcat的參數配置問題
  • 解決辦法:調整tomact配置文件server.xml的配置:主要是最大線程數、最大創建鏈接數和最長鏈接時間

3.JVM優化緩存

  • 現象:TPS每隔段時間就將爲0
  • 問題定位:(1)監控tcp的鏈接數,等待數;(netstat -an |grep 6222 | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}')(2)查看服務端FULL GC的次數(過多,FULL GC會致使全部線程
  • 解決辦法:JVM調優+ tomcat參數調優
  • 一、取消飛行記錄模式,去除參數(-XX:+UnlockCommercialFeatures -XX:+FlightRecorder)
  • 二、jdk1.8 下取消了-XX:PermSize=500m-XX:MaxPermSize=500m
  • 三、垃圾回收機制改爲G1模式(堆內存被劃分爲固定大小的多個區域,存活的對象從一塊區域轉移到另外一塊區域,這樣能夠進行垃圾回收的同時不中止其餘應用程序線程)
  • JVM的經常使用參數以下:
  •        -Xms設置初始化堆的最大值
  •       -Xmx 設置堆的最大值
  •        PS:-Xms和-Xmx通常是相同的,能夠減小Full GC的頻率,最大能夠到服務器總內存 的80%
  •        -Xmn 設置年輕代的大小(年老代=最大值-年輕代),通常爲最大值的1/3左右。

4. 數據庫、緩存等

1.DB優化tomcat

  • 優化sql,儘量少使用join、or語句,select出來的字段是必需的字段
  • 優化索引,讓每條select都走索引
  • 設置鏈接池的最大鏈接數,設置爲10000/14=700,(10000 爲項目使用的mysql 最

      大鏈接數,14 爲機器數)

  • 嘗試測試不一樣的鏈接池,選擇性能最佳的
  • 不使用數據庫事務,由於數據庫操做代碼都在消費者中,在代碼中作冪等性。查詢一條語句性能測試(ms)

2.redis優化存儲數結構

  • 將db 中的數據load 保存爲redis 的hash 結構(全表保存),根據業務優化redis 存儲結構,減小redis 查詢次數(例如將phone 和券code 的領取狀態單獨存儲)。

2.1.redis  cpu爲單核,進行分片處理

  • 大量查詢會成爲嚴重短板,經過hash 值進行分片處理,由於項目不存在熱點key 的問

題。優化事後redis 可以承受的量是以前的3 倍

2.2.設置redis最大鏈接數

  • Redis 最大鏈接數設置爲:3*10000/14 = 2100(這裏乘以3 是由於微利項目有三臺redis)

3.mq優化消息

  • 消息體通常爲redis key,能夠去redis 拿取數據,優化消息存儲大小。按功能不一樣,拆

分多個隊列,加快單邏輯處理速度,微利項目根據業務拆分爲5 個隊列

3.1.加快消費者消費速度

  • 增長消費者數量爲20 個,根據下游(DB、業務方)TPS 屢次測試得出,能夠利用消費者數

量控制下游的負載。

  • 增長消費者預讀取數據數量爲50 個,從而減小網絡請求次數。
  • 優化消費邏輯,完善冪等操做(解決消息重複消費問題),db 操做,業務查詢操做。

4.redis鏈接池pingjing

  • 優化後配置:

     redis.pool.maxTotal=5000

    redis.pool.maxIdle=100

    redis.pool.minIdle=50

  • 關鍵參數說明:

   maxTotal:資源池中最大鏈接池,默認值8

 - 最大鏈接數的配置須要結合實際狀況進行調整,而考慮的關鍵因素包括:

 - 業務要求Redis達到的併發量

 - 客戶端執行命令時間

 - Redis資源:如應用個數*maxTotal不能超過Redis的最大鏈接數

 - 資源開銷:控制空閒鏈接,儘可能使鏈接池的頻繁建立、釋放形成沒必要要的開銷

相關文章
相關標籤/搜索