ZERO
????持續(xù)更新 請關(guān)注：https://zorkelvll.cn/blogs/zorkelvll/articles/2019/01/16/1547619476722
背景
????在一次某個項目sp-jar運行過程中，總是在過一段時間后該jar進程總是會“無緣無故”（怎么可能是無緣無故呢缓淹，一切都是有原因的匿情，只不過自己還不知道而已）結(jié)束掉或者被殺死棉圈，因此決定進行一次進行查找以自我地提升报辱，畢竟在很小的一個以外包demo服務(wù)為導(dǎo)向的非技術(shù)性公司，這樣的機會也是非常少的吗铐！
????既然息楔，難得有這樣的實戰(zhàn)機會，就不應(yīng)該再僅僅停留在理論上對各類故障定位解決重斑、JVM分析的理論層面上!于是兵睛，決定進行一番探索！
1窥浪、系統(tǒng)日志
首先祖很，在該應(yīng)用運行過程中，記錄其運行的PID號為24296
-
在系統(tǒng)日志/var/log/messages中定位原因漾脂，執(zhí)行命令
cd /var/log
cat messages | grep 24296
- 如查詢結(jié)果假颇，顯然知道是出現(xiàn)了OOM異常，被系統(tǒng)殺死了骨稿；接下來笨鸡，就是定位是應(yīng)用中哪段代碼導(dǎo)致的該異常
分析插曲：
畢竟第一次摸索著實踐，也沒啥有經(jīng)驗人士面基坦冠，因此分析以為：
- 第一次以為形耗，在應(yīng)用發(fā)生關(guān)閉的時候，是系統(tǒng)內(nèi)存超了辙浑；而這個時候成肘，系統(tǒng)會自動查找一個內(nèi)存占用最大的進程也即sp給殺死（=>但是sp被殺死启泣，并不一定就是因為sp這個應(yīng)用而導(dǎo)致的系統(tǒng)內(nèi)存超出的，也有可能是其他的應(yīng)用導(dǎo)致的系統(tǒng)內(nèi)存超出隙轻，然后系統(tǒng)去殺死了內(nèi)存占用最大的這個sp）
- =>，因此決定去查看上面那一段報錯之前的一段log信息內(nèi)容氓轰，只能vim messages加上搜索時間點”Jan 16 02:34:34“，去查看詳細的時間點的內(nèi)容如下,
雖然也看不太懂（汗顏）
- 再次分析，通過zabbix上系統(tǒng)的內(nèi)存監(jiān)控累澡，發(fā)現(xiàn)系統(tǒng)內(nèi)存好像并沒有超出系統(tǒng)最大值，因此上面的以為是系統(tǒng)內(nèi)存超出了而殺死的占用最大的內(nèi)存進程般贼，說法不一定是對的
(其實愧哟，zabbix上的時間內(nèi)存飆升的那一個時間點剛好上02:34:34 + 8差不多這個時間)，
=>另外疑惑的是哼蛆，在這一時刻蕊梧，系統(tǒng)內(nèi)存確實是在飆升的，但是根據(jù)監(jiān)控圖顯示來說的系統(tǒng)內(nèi)存也還是有的腮介，仍然有6G多的內(nèi)存可供使用肥矢！一方面系統(tǒng)中被使用的內(nèi)存確實突增，另一方面叠洗，確實使用也沒有爆掉整個系統(tǒng)的內(nèi)存
=>更進一步地思考甘改，觀察zabbix中該系統(tǒng)使用內(nèi)存的走勢來說，進一步發(fā)現(xiàn)被使用的最多也就是達到2G灭抑！因此十艾，考慮：或者操作系統(tǒng)本身安全考慮導(dǎo)致的某個地方的配置內(nèi)存上限，或者JVM中的內(nèi)存最大參數(shù)Xmx設(shè)置
- 然后腾节，因此也有可能該sp這個應(yīng)用本身的最大可用內(nèi)存超了忘嫉，即重新設(shè)置Xmx？案腺？庆冕？？救湖？愧杯？
