一薯酝、問題

最近生產(chǎn)環(huán)境的一個(gè)后端應(yīng)用老是出現(xiàn)內(nèi)存溢出OutOfMemory腿堤，然后導(dǎo)致整個(gè)服務(wù)不可用的問題椰憋。

二腕唧、背景

（1）后端應(yīng)用

springMVC的應(yīng)用或辖，原來是jsp單體的老應(yīng)用，后來改造成一個(gè)后端服務(wù)枣接。

其實(shí)就是增加了一個(gè)mobile的package颂暇，里面放了一些移動(dòng)相關(guān)的接口，其他的不動(dòng)（老項(xiàng)目都這樣但惶，復(fù)制一下拿來用）耳鸯，然后部署在weblogic服務(wù)器上，為移動(dòng)端請(qǐng)求提供接口服務(wù)膀曾。

（2）前端應(yīng)用

移動(dòng)端是H5頁面县爬，然后外面包一層安卓的殼。

（3）登錄認(rèn)證問題

登錄認(rèn)證的前后端交互沒有通過cookie和session共同作用的

登錄認(rèn)證簡(jiǎn)單來說就是：
（針對(duì)單次請(qǐng)求）
1.移動(dòng)端請(qǐng)求添谊？userid=xxx
2.后端接收到請(qǐng)求财喳，根據(jù)userid獲取用戶信息
3.getSession(),然后把用戶信息放進(jìn)session里
4.后面這個(gè)請(qǐng)求執(zhí)行一系列復(fù)雜的業(yè)務(wù)代碼，可能會(huì)在某一個(gè)步驟需要獲取用戶信息
5.從session里面讀取用戶信息
6.請(qǐng)求結(jié)束斩狱，session便沒用了

問題所在：getSession()每次都會(huì)創(chuàng)建一個(gè)新的session對(duì)象耳高，而且使用完并沒手動(dòng)session.invalidate()使session失效，只能等session超時(shí)失效后被jvm垃圾回收所踊。

session對(duì)象越積越多泌枪，所以查看dump文件時(shí)可以看到weblogic.servlet.internal.session.MemorySessionContext對(duì)象占用了40%

image.png

image.png

三、問題解決過程

(1)服務(wù)老是掛掉秕岛，而且經(jīng)常挑周末掛碌燕，周末睡得好好的误证，突然用戶群就炸了，這讓運(yùn)維妹子苦不堪言陆蟆。

image.png

（2）之前有大概看過日志雷厂，模糊記得是內(nèi)存溢出導(dǎo)致的。于是叠殷，便開始著手準(zhǔn)備排查改鲫。

（3）生成dump文件 （-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:\dump）

在startWeblogic.cmd啟動(dòng)文件中的set USER_MEM_ARGS末尾加上-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:\dump
然后重啟。

image.png

（4）靜靜等待服務(wù)器再次掛掉【手動(dòng)狗頭】

（5）果不其然林束，過了幾天掛掉了像棘，dump出一個(gè)2個(gè)豬的文件

image.png

（6）文件太大了，qq和公司郵箱沒法發(fā)壶冒，只能叫她上傳到百度云盤我再下載下來缕题，順帶體驗(yàn)了一把“用閑置寬帶為下載提速”

（7）下載回來用MemoryAnalyzer打開

第一次打開失敗，原因是文件太大了胖腾，導(dǎo)致軟件崩了烟零。后來調(diào)大MemoryAnalyzer的運(yùn)行內(nèi)存：MemoryAnalyzer.ini里的-Xmx改成了2048m，終于順利打開了

（8）分析問題

image.png

image.png

看來罪魁禍?zhǔn)拙褪撬讼套鳎沁@是個(gè)什么玩意呢锨阿？

（9）尋求度娘幫助

網(wǎng)上相關(guān)的資料不多，后來終于找到一篇
這里是原文：http://www.voidcn.com/article/p-etbhmwaj-ee.html
引用一下作者原文：

APPLIES TO:

Oracle WebLogic Server - Version 10.3.5 and later
Information in this document applies to any platform.

SYMPTOMS

There is huge consumption of memory in the production environment. A memory dump shows two WebLogic classes as leak suspects:

• weblogic.servlet.internal.session.MemorySessionContext (66.05%)
• weblogic.servlet.internal.session.MemorySessionData (21.52%)

CAUSE

The "session-timeout" value in in web.xml is set to 1 hour (3600 seconds) by default. If the session is not invalidated or timed out in application code, each session will live for that full hour, causing objects to accumulate until the container times the session out. Combine this with heavy traffic (so lots of sessions opened), and this causes huge memory consumption.

To find if there are any invalid sessions lingering in the heap after a particular time, it is recommended that the application explicitly call session.invalidate() to invalidate a session after the user logs out. However WLS also provides a mechanism to expire sessions after a specific interval that is referred to as the "session-timeout" parameter in the web.xml. The value set in this element overrides the value set in the TimeoutSecs attribute of the element in the WebLogic-specific deployment descriptor weblogic.xml. If nothing is specified the default value of 3600 seconds is used. See [Session Timeout](javascript:void()) for more information.

SOLUTION

To reduce the memory consumption from HTTP session objects, please follow these steps:

1. Ensure that the application code explicitly calls session.invalidate() when a user logs out of their session.
2. Lower the "session-timeout" value set in in web.xml to (for example) 15 minutes.

大致說的是：weblogic 中的session-timeout配置默認(rèn)是一個(gè)小時(shí)记罚，意思是session對(duì)象默認(rèn)一個(gè)小時(shí)后才會(huì)過期墅诡，新的不斷產(chǎn)生，舊的還沒過期桐智，導(dǎo)致越來越多的session對(duì)象存活在內(nèi)存中末早，最終導(dǎo)致了內(nèi)存溢出。

四说庭、解決辦法

結(jié)合本項(xiàng)目的實(shí)際情況（每個(gè)請(qǐng)求都會(huì)產(chǎn)生新的session對(duì)象）然磷，而且項(xiàng)目中并沒有看到有代碼顯示的使session對(duì)象失效的代碼session.invalidate() ，我猜想可能是session過期時(shí)間過長(zhǎng)導(dǎo)致的口渔。

1.首先查看一下本地項(xiàng)目代碼web.xml中session-timeout样屠，我擦！居然是5400分鐘缺脉，一個(gè)半小時(shí)

image.png

2.那非常有可能就是它的鍋了痪欲，于是叫現(xiàn)場(chǎng)的同事檢查一下生產(chǎn)環(huán)境配置，果然攻礼，現(xiàn)場(chǎng)的配置也是5400

image.png

3.根據(jù)項(xiàng)目的實(shí)際情況业踢，我叫現(xiàn)場(chǎng)同事把生產(chǎn)環(huán)境配置改成10分鐘，此問題應(yīng)該可以得以解決礁扮。

觀察一段時(shí)間后再補(bǔ)充結(jié)果知举。

五瞬沦、性能提升

條件：
1.每次請(qǐng)求都產(chǎn)生一個(gè)新的session對(duì)象
2.session對(duì)象過期時(shí)間為5400分鐘
3.假設(shè)每個(gè)用戶每分鐘能發(fā)送100個(gè)請(qǐng)求

image.png

dump文件中顯示內(nèi)存溢出的時(shí)候，內(nèi)存中共有840000000多個(gè)對(duì)象
840000000÷5400÷100≈1555
共能支撐大約1555個(gè)用戶同時(shí)在線

優(yōu)化后
(840000000÷5400÷100)*540=840000

注：總用戶數(shù)才10000左右

是不是可以吹一波牛逼說雇锡，理論上性能提升了540倍呢逛钻？【手動(dòng)狗頭】

至于為什么要改成10，不改成5或者1锰提，跟項(xiàng)目有一定關(guān)系：項(xiàng)目非常老舊曙痘，而且各種調(diào)用，甚至還會(huì)去調(diào)用oracle的存儲(chǔ)過程立肘，保不準(zhǔn)會(huì)超過1分鐘边坤，改成5分鐘其實(shí)理論上已經(jīng)很穩(wěn)了，但是為了防止會(huì)有奇奇怪怪的現(xiàn)象發(fā)生谅年，還是改成10求穩(wěn)茧痒。而且改后能支撐的用戶數(shù)理論上已經(jīng)遠(yuǎn)遠(yuǎn)超過了總用戶數(shù)。

六融蹂、總結(jié)

1.學(xué)會(huì)分析dump文件
2.結(jié)合項(xiàng)目實(shí)際情況定位問題和解決問題

文中如有不準(zhǔn)確的地方旺订，還望各位批評(píng)指正。感謝超燃！