大香蕉伊人黄色在线观看,日本欧美一级色情片免费观看,国产美女扣逼视频,sm在线,99亚洲天堂,人人操人人吻人人射,人妻人人操人人爽,做爱视频免费在线

作者 | Alan_beijing

來源 | cnblogs.com/wangjiming/p/13225544.html

對于線上系統(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ā)的線上問題

問題一：當秒殺的時候，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"

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增大緩存


<Resource
cachingAllowed = "true"
cacheMaxSize = "102400"
/>

# 最終優(yōu)化結果

經過幾天觀察，系統(tǒng)平穩(wěn)

1.基本監(jiān)控

2.GC

3.抽樣器cou和內存

cpu

內存

# 總結

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未做高可用集群