資訊專欄INFORMATION COLUMN
摘要：現(xiàn)象登入生產(chǎn)環(huán)境，使用命令因?yàn)檫@時(shí)候并沒有打的，所以只能觀察現(xiàn)象。其他的可以根據(jù)這個(gè)類推，是內(nèi)純的占用量。
前言
我們的游戲上線之初，經(jīng)常有玩家反饋卡，或者有網(wǎng)絡(luò)延遲等現(xiàn)象，造成用戶流失等現(xiàn)象，這時(shí)候我就想到是不是可能是之前的jvm配置有問題，或者存在內(nèi)存泄露等問題。
現(xiàn)象
登入生產(chǎn)環(huán)境，使用命令,因?yàn)檫@時(shí)候并沒有打gc的log，所以只能觀察現(xiàn)象。
jstat -gcutil 27084 250 20
查看gc狀態(tài)
說明：
| S0 | S1 | E | O | P | YGC | YGCT | FGC | FGCT | GCT |
|---|---|---|---|---|---|---|---|---|---|
| 54.62 | 0.00 | 42.87 | 43.52 | 86.24 | 1792 | 5.093 | 33 | 7.670 | 12.763 |
S0:新生代的susvivor0區(qū)，空間使用率為54..62%
S1:新生代的susvivor1區(qū)，空間使用率為0.00%(因?yàn)檫€沒有執(zhí)行第二次minor收集)
E:eden區(qū)，空間使用率42.87%
O:舊生代，空間使用率43.52%
P:持久帶，空間使用率86.24%
YGC:minor gc執(zhí)行次數(shù)1792次
YGCT:minor gc耗費(fèi)的時(shí)間5.093毫秒
FGC:full gc執(zhí)行次數(shù)33
FGCT:full gc耗費(fèi)的時(shí)間7.670毫秒
GCT:gc耗費(fèi)的總時(shí)間12.763毫秒
發(fā)現(xiàn)其實(shí)主要是full gc頻率過高，為什么會(huì)導(dǎo)致這個(gè)原因呢，我首先想到的是是不是老生代分配的過低，就著手分配老生代的比例
然而并沒有解決這個(gè)問題，發(fā)現(xiàn)YGC持續(xù)升高，而FGC也會(huì)逐漸上來，暫時(shí)解決了問題的表象而已。
解決問題 首先看一下該jvm使用內(nèi)存的情況使用命令jstat -gccapacity:可以顯示，VM內(nèi)存中三代（young,old,perm）對(duì)象的使用和占用大小，如：PGCMN顯示的是最小perm的內(nèi)存使用量，PGCMX顯示的是perm的內(nèi)存最大使用量，PGC是當(dāng)前新生成的perm內(nèi)存占用量，PC是但前perm內(nèi)存占用量。其他的可以根據(jù)這個(gè)類推， OC是old內(nèi)純的占用量。
發(fā)現(xiàn)問題看了一下jvm內(nèi)存分配情況，發(fā)現(xiàn)一共新生代只分配了50M左右，發(fā)現(xiàn)原來之前使用的啟動(dòng)腳本并沒有設(shè)置jvm啟動(dòng)參數(shù)
解決問題先把Jvm參數(shù)調(diào)整，gc log文件夾設(shè)置
JAVA_OPTS="-Xms2048m -Xmx2048m -XX:PermSize=64m -XX:MaxPermSize=256m -verbose:gc -Xloggc:/home/admin/logs/gc.log"
生產(chǎn)環(huán)境Java應(yīng)用的jvm參數(shù)Xms與Xmx保持一致，避免因所使用的Java堆內(nèi)存不夠?qū)е骂l繁full gc以及full gc中因動(dòng)態(tài)調(diào)節(jié)Java堆大小而耗費(fèi)延長其周期。
查看下圖，F(xiàn)GC已經(jīng)明顯下降到正常水平
學(xué)好JVM可以從JVM參數(shù)開始：
| 參數(shù)名稱 | 含義 默認(rèn)值 |
|---|---|
| -Xms | 初始堆大小 物理內(nèi)存的1/64(<1GB) 默認(rèn)(MinHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存小于40%時(shí)，JVM就會(huì)增大堆直到-Xmx的最大限制. |
| -Xmx | 最大堆大小 物理內(nèi)存的1/4(<1GB) 默認(rèn)(MaxHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存大于70%時(shí)，JVM會(huì)減少堆直到 -Xms的最小限制 |
| -Xmn | 年輕代大小(1.4or lator)注意：此處的大小是（eden+ 2 survivor space).與jmap -heap中顯示的New gen是不同的。整個(gè)堆大小=年輕代大小 + 年老代大小 + 持久代大小.增大年輕代后,將會(huì)減小年老代大小.此值對(duì)系統(tǒng)性能影響較大,Sun官方推薦配置為整個(gè)堆的3/8 |
| -XX:NewSize | 設(shè)置年輕代大小(for 1.3/1.4) |
| -XX:MaxNewSize | 年輕代最大值(for 1.3/1.4) |
| -XX:PermSize | 設(shè)置持久代(perm gen)初始值 物理內(nèi)存的1/64 |
| -XX:MaxPermSize | 設(shè)置持久代最大值 物理內(nèi)存的1/4 |
| -Xss | 每個(gè)線程的堆棧大小,JDK5.0以后每個(gè)線程堆棧大小為1M,以前每個(gè)線程堆棧大小為256K.更具應(yīng)用的線程所需內(nèi)存大小進(jìn)行 調(diào)整.在相同物理內(nèi)存下,減小這個(gè)值能生成更多的線程.但是操作系統(tǒng)對(duì)一個(gè)進(jìn)程內(nèi)的線程數(shù)還是有限制的,不能無限生成,經(jīng)驗(yàn)值在3000~5000左右,一般小的應(yīng)用， 如果棧不是很深， 應(yīng)該是128k夠用的 大的應(yīng)用建議使用256k。這個(gè)選項(xiàng)對(duì)性能影響比較大，需要嚴(yán)格的測(cè)試。（校長）和threadstacksize選項(xiàng)解釋很類似,官方文檔似乎沒有解釋,在論壇中有這樣一句話:"”-Xss is translated in a VM flag named ThreadStackSize”一般設(shè)置這個(gè)值就可以了。 |
| -XX:ThreadStackSize | Thread Stack Size (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.] |
| -XX:NewRatio | 年輕代(包括Eden和兩個(gè)Survivor區(qū))與年老代的比值(除去持久代) -XX:NewRatio=4表示年輕代與年老代所占比值為1:4,年輕代占整個(gè)堆棧的1/5Xms=Xmx并且設(shè)置了Xmn的情況下，該參數(shù)不需要進(jìn)行設(shè)置。 |
| -XX:SurvivorRatio | Eden區(qū)與Survivor區(qū)的大小比值 設(shè)置為8,則兩個(gè)Survivor區(qū)與一個(gè)Eden區(qū)的比值為2:8,一個(gè)Survivor區(qū)占整個(gè)年輕代的1/10 |
| -XX:LargePageSizeInBytes | 內(nèi)存頁的大小不可設(shè)置過大， 會(huì)影響Perm的大小 =128m |
| -XX:+UseFastAccessorMethods | 原始類型的快速優(yōu)化 |
| -XX:+DisableExplicitGC | 關(guān)閉System.gc() 這個(gè)參數(shù)需要嚴(yán)格的測(cè)試 |
| -XX:MaxTenuringThreshold | 垃圾最大年齡 如果設(shè)置為0的話,則年輕代對(duì)象不經(jīng)過Survivor區(qū),直接進(jìn)入年老代. 對(duì)于年老代比較多的應(yīng)用,可以提高效率.如果將此值設(shè)置為一個(gè)較大值,則年輕代對(duì)象會(huì)在Survivor區(qū)進(jìn)行多次復(fù)制,這樣可以增加對(duì)象再年輕代的存活 時(shí)間,增加在年輕代即被回收的概率,該參數(shù)只有在串行GC時(shí)才有效. |
| -XX:+AggressiveOpts | 加快編譯 |
| -XX:+UseBiasedLocking | 鎖機(jī)制的性能改善 |
| -Xnoclassgc | 禁用垃圾回收 |
| -XX:SoftRefLRUPolicyMSPerMB | 每兆堆空閑空間中SoftReference的存活時(shí)間 1s softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap |
| -XX:PretenureSizeThreshold | 對(duì)象超過多大是直接在舊生代分配 0 單位字節(jié) 新生代采用Parallel Scavenge GC時(shí)無效,另一種直接在舊生代分配的情況是大的數(shù)組對(duì)象,且數(shù)組中無外部引用對(duì)象. |
| -XX:TLABWasteTargetPercent | TLAB占eden區(qū)的百分比 1% |
| -XX:+CollectGen0First | FullGC時(shí)是否先YGC false |
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/66303.html
摘要：這是多處理器系統(tǒng)中，調(diào)度器用來分散任務(wù)到不同的機(jī)制，通常也被稱為處理器間中斷，。文章編寫計(jì)劃 待完成: 詳細(xì)介紹用到的各個(gè)工具 作者: 萬千鈞(祝星) 適合閱讀人群 文中的調(diào)優(yōu)思路無論是php, java, 還是其他任何語言都是用. 如果你有php使用經(jīng)驗(yàn), 那肯定就更好了 業(yè)務(wù)背景 框架及相應(yīng)環(huán)境 laravel5.7, mysql5.7, redis5, nginx1.15 cento...
摘要：這是多處理器系統(tǒng)中，調(diào)度器用來分散任務(wù)到不同的機(jī)制，通常也被稱為處理器間中斷，。文章編寫計(jì)劃 待完成: 詳細(xì)介紹用到的各個(gè)工具 作者: 萬千鈞(祝星) 適合閱讀人群 文中的調(diào)優(yōu)思路無論是php, java, 還是其他任何語言都是用. 如果你有php使用經(jīng)驗(yàn), 那肯定就更好了 業(yè)務(wù)背景 框架及相應(yīng)環(huán)境 laravel5.7, mysql5.7, redis5, nginx1.15 cento...
摘要：什么是內(nèi)存溢出內(nèi)存溢出是指，程序創(chuàng)建對(duì)象需要內(nèi)存，但是卻沒有內(nèi)存可用了，內(nèi)存就溢出了。使用命令查看個(gè)數(shù)輸入后，按診斷是文件在服務(wù)端沒讀取到，還是內(nèi)存溢出。無耐，阿里云學(xué)生機(jī)配置不好，只能稍微修改一點(diǎn)，再將文件切割為小文件上傳了參數(shù)請(qǐng)參考 1、什么是內(nèi)存泄漏內(nèi)存泄漏是指，有未被釋放的java對(duì)象，一直停留在內(nèi)存中。GCRoot 無法追蹤到此對(duì)象，導(dǎo)致此對(duì)象無法被回收。 2、什么是內(nèi)存溢出...
摘要：為了一探究竟，于是開啟了這次應(yīng)用性能調(diào)優(yōu)之旅。使用即時(shí)編譯器和都能輕輕松松的讓你的應(yīng)用程序在不用做任何修改的情況下，直接提高或者更高的性能。 這是一份事后的總結(jié)。在經(jīng)歷了調(diào)優(yōu)過程踩的很多坑之后，我們最終完善并實(shí)施了初步的性能測(cè)試方案，通過真實(shí)的測(cè)試數(shù)據(jù)歸納出了 Laravel 開發(fā)過程中的一些實(shí)踐技巧。 0x00 源起 最近有同事反饋 Laravel 寫的應(yīng)用程序響應(yīng)有點(diǎn)慢、20幾個(gè)并...
摘要：首先先解讀下這個(gè)報(bào)警內(nèi)容，原因活躍線程數(shù)過多，是監(jiān)聽的端口號(hào)用來獲取虛擬機(jī)各項(xiàng)信息，代表著此時(shí)的線程數(shù)，是設(shè)置的報(bào)警閾值。 前言 前天，一位21世紀(jì)的好好青年正在工位上默念社會(huì)主義大法好的時(shí)候，釘釘上又報(bào)警了（公司項(xiàng)目接入了open-faclon監(jiān)控，指標(biāo)不正常會(huì)報(bào)警給釘釘?shù)臋C(jī)器人），無奈默默流淚揮手告別社會(huì)主義大法開始定位線上問題。 報(bào)警內(nèi)容 首先我們先來看下報(bào)警信息，為防止泄露公...
閱讀 3001·2021-11-25 09:43
閱讀 2453·2021-11-24 09:39
閱讀 2795·2021-09-23 11:51
閱讀 1490·2021-09-07 10:11
閱讀 1515·2019-08-27 10:52
閱讀 1998·2019-08-26 12:13
閱讀 3419·2019-08-26 11:57
閱讀 1461·2019-08-26 11:31
