記一次線上商城系統(tǒng) Tomcat、JVM 高并發(fā)的優(yōu)化
掃描二維碼
隨時隨地手機看文章
對于線上系統(tǒng)調優(yōu),它本身是個技術活,不僅需要很強的技術實戰(zhàn)能力,很強的問題定位,問題識別,問題排查能力,還需要很豐富的調優(yōu)能力。
本篇文章從實戰(zhàn)角度,從問題識別,問題定位,問題分析,提出解決方案,實施解決方案,監(jiān)控調優(yōu)后的解決方案和調優(yōu)后的觀察等角度來與大家一起交流分享本次線上高并發(fā)調優(yōu)整個閉環(huán)過程。
一、項目簡要情況概述
該項目為基于SSM架構的商城類單體架構項目,其中有一個秒殺重磅模塊,如下為當前線上環(huán)境的簡要架構部署圖,大致描述一下:
(1)項目為SSM架構
(2)服務器類別:1臺負載均衡服務器(F5),3臺運用程序服務器,1臺計時器服務器,1臺redis服務器,1臺圖片服服務器和1臺基于Pass架構的Mysql主從服務器(微軟云)
(3)調用邏輯
二、何為單體架構項目
從架構發(fā)展角度,軟件項目經歷了如下階段的發(fā)展:
1.單體架構:可理解為傳統(tǒng)的前后端未分離的架構
2.垂直架構:可理解為前后端分離架構
3.SOA架構:可理解為按服務類別,業(yè)務流量,服務間依賴關系等服務化的架構,如以前的單體架構ERP項目,劃分為訂單服務,采購服務,物料服務和銷售服務等
4.微服務:可理解為一個個小型的項目,如之前的ERP大型項目,劃分為訂單服務(訂單項目),采購服務(采購項目),物料服務(物料項目)和銷售服務(銷售項目),以及服務之間調用
三、本SSM項目引發(fā)的線上問題
1.當秒殺的時候,cpu暴增
該系統(tǒng)每天秒殺分為三個時間端:10點,13點和20點,如下為秒殺的簡要頁面
2.單臺運用服務器cpu
3.單臺運用服務器請求數(shù)
4.rdis連接數(shù)(info clients)
這個未保存截圖,記得是600左右
connected_clients:600
5.mysql請求截圖
四、排查過程及分析
(一)排查思路
根據(jù)服務部署和項目架構,從如下幾個方面排查:
(1)運用服務器:排查內存,cpu,請求數(shù)等;
(2)文件圖片服務器:排查內存,cpu,請求數(shù)等;
(3)計時器服務器:排查內存,cpu,請求數(shù)等;
(4)redis服務器:排查內存,cpu,連接數(shù)等;
(5)db服務器:排查內存,cpu,連接數(shù)等;
(二)排查過程
在秒殺后30分鐘內,
1.運用程序服務器cpu暴增,內存暴增,造成cpu和內存暴增的根本原因是請求數(shù)過高,單臺運用服務器達到3000多;
2.redis請求超時
3.jdbc連接超時
4.通過gc查看,發(fā)現(xiàn)24小時內,F(xiàn)ullGC發(fā)生了152次
5.再看看堆棧,發(fā)現(xiàn)有一些線程阻塞和死鎖
jstat -l pid,也可以通過VisualVM分析
6.發(fā)現(xiàn)有2000多個線程請求無效資源
(三)造成本次系統(tǒng)異常主要因素分析
(1)在秒殺時,請求量過高,導致運用服務器負載過高;
(2)redis連接池滿,獲取不到連接,connot get a connection from thread pool
(3)jdbc連接池滿,獲取不到連接和超時
(4)存在大對象代碼,如向list集合中不停添加對象,不能及時回收對象導致內存增加,頻繁發(fā)生Full GC
(5)tomcat并發(fā)參數(shù),jvm優(yōu)化參數(shù),jedis配置參數(shù),jdbc配置參數(shù)不合理
(6)未對請求量進行削峰和限流
(7)資源連接未及時釋放,如redis連接,jdbc連接未及時釋放
五、最終解決方案
1.增加運用服務,做流量削峰和分流
由于該項目未增加MQ,因此只能采用硬負載,增加服務器水平擴展方式來實現(xiàn)流量削峰和流量分流
2.優(yōu)化jvm參數(shù),如下為本次優(yōu)化后的參數(shù)
JAVA_OPTS="-server -Xmx9g -Xms9g -Xmn3g -Xss500k -XX:+DisableExplicitGC -XX:MetaspaceSize=2048m -XX:MaxMetaspaceSize=2048m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -Dfile.encoding=UTF8 -Duser.timezone=GMT+08"
關于這個jvm參數(shù)的優(yōu)化,jvm理論是怎樣的,官方建議是怎樣的,實戰(zhàn)是怎樣的,將在下篇文章中分析。
3.優(yōu)化tomcat并發(fā)相關參數(shù)
主要是兩方面:
(1)修改bio協(xié)議為nio2? (2)根據(jù)服務器配置,業(yè)務場景,業(yè)務流量等合理設置相關參數(shù),盡量達到最優(yōu)
關于tomcat相關參數(shù)優(yōu)化,在接下來的文章中分析。
4.redis 和jdbc參數(shù)優(yōu)化
由于涉及到安全性問題,這里不列出
5.代碼優(yōu)化
(1)優(yōu)化掉大對象
(2)優(yōu)化未及時釋放的對象和連接資源
6.解決000多個線程請求無效資源問題
在conf/context.xml增大緩存"true" cacheMaxSize = "102400" />
六、最終優(yōu)化結果
經過幾天觀察,系統(tǒng)平穩(wěn)
1.基本監(jiān)控
2.GC
3.抽樣器cou和內存
七、總結
1.本篇文章從實戰(zhàn)角度,從問題識別,問題定位,問題分析,提出解決方案,實施解決方案,監(jiān)控調優(yōu)后的解決方案和調優(yōu)后的觀察等角度來與大家一起交流分享本次線上高并發(fā)調優(yōu)整個閉環(huán)過程,當然,由于篇幅的限制,
有些細節(jié)和優(yōu)化手段未在本篇文章中提及;
2.雖然解決了該問題,但是從長遠來看,該單體項目任然存在很大的問題和隱患,下面隨便舉幾個:
(1)前后端緊耦合,未分離
(2)由于該系統(tǒng)秒殺業(yè)務屬于非持續(xù)性并發(fā),即局部性并發(fā),當前并未做局部并發(fā)架構的調整
(3)由于該系統(tǒng)秒殺業(yè)務與該項目緊緊耦合在一起,未進行隔離,未獨立成單獨模塊,未單獨部署,從而存在因秒殺業(yè)務造成整個系統(tǒng)癱瘓的風險;
(4)未做流量削峰和流量限流,如加mq等軟手段;
(5)redis為做高可用集群
特別推薦一個分享架構+算法的優(yōu)質內容,還沒關注的小伙伴,可以長按關注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!