亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專(zhuān)欄INFORMATION COLUMN

jvm調(diào)優(yōu)

snowLu / 853人閱讀

摘要:一內(nèi)存調(diào)優(yōu)主要的目的是減小的頻率和的次數(shù)。調(diào)優(yōu)工具之主要用來(lái)輸出中運(yùn)行的進(jìn)程狀態(tài)信息。調(diào)優(yōu)工具之和用來(lái)查看堆內(nèi)存使用狀況,一般結(jié)合使用。

一、jvm內(nèi)存調(diào)優(yōu)

主要的目的是減小GC的頻率和Full GC的次數(shù)。

1.Full GC

會(huì)對(duì)整個(gè)堆進(jìn)行整理,包括Young、Tenured和Perm。Full GC由于須要對(duì)整個(gè)堆進(jìn)行回收,因此比較慢,所以應(yīng)該盡量減小Full GC的次數(shù)。數(shù)組

2.致使Full GC的緣由緩存

1)年老代(Tenured)被寫(xiě)滿服務(wù)器
調(diào)優(yōu)時(shí)盡可能讓對(duì)象在新生代GC時(shí)被回收、讓對(duì)象在新生代多存活一段時(shí)間和不要建立過(guò)大的對(duì)象及數(shù)組避免直接在舊生代建立對(duì)象 。并發(fā)
2)持久代Pemanet Generation空間不足jvm
增大Perm Gen空間,避免太多靜態(tài)對(duì)象 , 控制好新生代和舊生代的比例高并發(fā)
3)System.gc()被顯示調(diào)用工具
垃圾回收不要手動(dòng)觸發(fā),盡可能依靠JVM自身的機(jī)制

在對(duì)JVM調(diào)優(yōu)的過(guò)程當(dāng)中,很大一部分工做就是對(duì)于FullGC的調(diào)節(jié),下面詳細(xì)介紹對(duì)應(yīng)JVM調(diào)優(yōu)的方法和步驟。

二、jvm性能調(diào)優(yōu)工具及思路(重要)—面試必看

2.1.JVM調(diào)優(yōu)參數(shù)參考

1.針對(duì)JVM堆的設(shè)置,通常能夠經(jīng)過(guò)-Xms -Xmx限定其最小、最大值,為了防止垃圾收集器在最小、最大之間收縮堆而產(chǎn)生額外的時(shí)間,一般把最大、最小設(shè)置為相同的值;
2.年輕代和年老代將根據(jù)默認(rèn)的比例(1:2)分配堆內(nèi)存, 能夠經(jīng)過(guò)調(diào)整兩者之間的比率NewRadio來(lái)調(diào)整兩者之間的大小,也能夠針對(duì)回收代。
好比年輕代,經(jīng)過(guò) -XX:newSize -XX:MaxNewSize來(lái)設(shè)置其絕對(duì)大小。一樣,為了防止年輕代的堆收縮,咱們一般會(huì)把-XX:newSize -XX:MaxNewSize設(shè)置為一樣大小。
3.年輕代和年老代設(shè)置多大才算合理
1)更大的年輕代必然致使更小的年老代,大的年輕代會(huì)延長(zhǎng)普通GC的周期,但會(huì)增長(zhǎng)每次GC的時(shí)間;小的年老代會(huì)致使更頻繁的Full GC
2)更小的年輕代必然致使更大年老代,小的年輕代會(huì)致使普通GC很頻繁,但每次的GC時(shí)間會(huì)更短;大的年老代會(huì)減小Full GC的頻率
如何選擇應(yīng)該依賴應(yīng)用程序?qū)ο笊芷诘姆植紶顩r: 若是應(yīng)用存在大量的臨時(shí)對(duì)象,應(yīng)該選擇更大的年輕代;若是存在相對(duì)較多的持久對(duì)象,年老代應(yīng)該適當(dāng)增大。但不少應(yīng)用都沒(méi)有這樣明顯的特性。
在抉擇時(shí)應(yīng)該根 據(jù)如下兩點(diǎn):
(1)本著Full GC盡可能少的原則,讓年老代盡可能緩存經(jīng)常使用對(duì)象,JVM的默認(rèn)比例1:2也是這個(gè)道理 。
(2)經(jīng)過(guò)觀察應(yīng)用一段時(shí)間,看其余在峰值時(shí)年老代會(huì)占多少內(nèi)存,在不影響Full GC的前提下,根據(jù)實(shí)際狀況加大年輕代,好比能夠把比例控制在1:1。但應(yīng)該給年老代至少預(yù)留1/3的增加空間。
4.在配置較好的機(jī)器上(好比多核、大內(nèi)存),能夠?yàn)槟昀洗x擇并行收集算法: -XX:+UseParallelOldGC 。
5.線程堆棧的設(shè)置:每一個(gè)線程默認(rèn)會(huì)開(kāi)啟1M的堆棧,用于存放棧幀、調(diào)用參數(shù)、局部變量等,對(duì)大多數(shù)應(yīng)用而言這個(gè)默認(rèn)值太了,通常256K就足用。
理論上,在內(nèi)存不變的狀況下,減小每一個(gè)線程的堆棧,能夠產(chǎn)生更多的線程,但這實(shí)際上還受限于操做系統(tǒng)。

2.2.調(diào)優(yōu)工具之jps(Java Virtual Machine Process Status Tool)

jps主要用來(lái)輸出JVM中運(yùn)行的進(jìn)程狀態(tài)信息。語(yǔ)法格式如下:

jps [options] [hostid]

如果不指定hostid就默認(rèn)為當(dāng)前主機(jī)或服務(wù)器。
命令行參數(shù)選項(xiàng)說(shuō)明如下:

-q 不輸出類(lèi)名、Jar名和傳入main方法的參數(shù)
-m 輸出傳入main方法的參數(shù)
-l 輸出main類(lèi)或Jar的全限名
-v 輸出傳入JVM的參數(shù)

比如下面:

root@ubuntu:/# jps -m -l2458 org.artifactory.standalone.main.Main /usr/local/artifactory-2.2.5/etc/jetty.xml29920 com.sun.tools.hat.Main -port 9998 /tmp/dump.dat3149 org.apache.catalina.startup.Bootstrap start30972 sun.tools.jps.Jps -m -l8247 org.apache.catalina.startup.Bootstrap start25687 com.sun.tools.hat.Main -port 9999 dump.dat21711 mrf-center.jar

2.3.調(diào)優(yōu)工具之jstack

jstack主要用來(lái)查看某個(gè)Java進(jìn)程內(nèi)的線程堆棧信息。語(yǔ)法格式如下:
jstack [option] pid
jstack [option] executable core
jstack [option] [server-id@]remote-hostname-or-ip
命令行參數(shù)選項(xiàng)說(shuō)明如下:

-l long listings,會(huì)打印出額外的鎖信息,在發(fā)生死鎖時(shí)可以用jstack -l pid來(lái)觀察鎖持有情況
-m mixed mode,不僅會(huì)輸出Java堆棧信息,還會(huì)輸出C/C++堆棧信息(比如Native方法)

jstack可以定位到線程堆棧,根據(jù)堆棧信息我們可以定位到具體代碼,所以它在JVM性能調(diào)優(yōu)中使用得非常多。下面我們來(lái)一個(gè)實(shí)例找出某個(gè)Java進(jìn)程中最耗費(fèi)CPU的Java線程并定位堆棧信息,用到的命令有ps、top、printf、jstack、grep。

第一步先找出Java進(jìn)程ID,我部署在服務(wù)器上的Java應(yīng)用名稱(chēng)為mrf-center:

root@ubuntu:/# ps -ef | grep mrf-center | grep -v grep
root     21711     1  1 14:47 pts/3    00:02:10 java -jar mrf-center.jar

得到進(jìn)程ID為21711,第二步找出該進(jìn)程內(nèi)最耗費(fèi)CPU的線程,可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid,我這里用第三個(gè),輸出如下:


TIME列就是各個(gè)Java線程耗費(fèi)的CPU時(shí)間,CPU時(shí)間最長(zhǎng)的是線程ID為21742的線程,用

printf "%x/n" 21742

得到21742的十六進(jìn)制值為54ee,下面會(huì)用到。

OK,下一步終于輪到j(luò)stack上場(chǎng)了,它用來(lái)輸出進(jìn)程21711的堆棧信息,然后根據(jù)線程ID的十六進(jìn)制值grep,如下:

root@ubuntu:/# jstack 21711 | grep 54ee
"PollIntervalRetrySchedulerThread" prio=10 tid=0x00007f950043e000 nid=0x54ee in Object.wait() [0x00007f94c6eda000]

可以看到CPU消耗在PollIntervalRetrySchedulerThread這個(gè)類(lèi)的Object.wait(),我找了下我的代碼,定位到下面的代碼:

// Idle waitgetLog().info("Thread [" + getName() + "] is idle waiting...");schedulerThreadState = PollTaskSchedulerThreadState.IdleWaiting;long now = System.currentTimeMillis();long waitTime = now + getIdleWaitTime();long timeUntilContinue = waitTime - now;synchronized(sigLock) {    try {        if(!halted.get()) {            sigLock.wait(timeUntilContinue);        }    }    catch (InterruptedException ignore) {    }}

它是輪詢?nèi)蝿?wù)的空閑等待代碼,上面的sigLock.wait(timeUntilContinue)就對(duì)應(yīng)了前面的Object.wait()。

2.4.調(diào)優(yōu)工具之jmap(Memory Map)和jhat(Java Heap Analysis Tool)

jmap用來(lái)查看堆內(nèi)存使用狀況,一般結(jié)合jhat使用。

jmap語(yǔ)法格式如下:

jmap [option] pid
jmap [option] executable core
jmap [option] [server-id@]remote-hostname-or-ip

如果運(yùn)行在64位JVM上,可能需要指定-J-d64命令選項(xiàng)參數(shù)。

jmap -permstat pid

打印進(jìn)程的類(lèi)加載器和類(lèi)加載器加載的持久代對(duì)象信息,輸出:類(lèi)加載器名稱(chēng)、對(duì)象是否存活(不可靠)、對(duì)象地址、父類(lèi)加載器、已加載的類(lèi)大小等信息,如下圖:

使用jmap -heap pid查看進(jìn)程堆內(nèi)存使用情況,包括使用的GC算法、堆配置參數(shù)和各代中堆內(nèi)存使用情況。比如下面的例子:

root@ubuntu:/# jmap -heap 21711Attaching to process ID 21711, please wait...Debugger attached successfully.Server compiler detected.JVM version is 20.10-b01 using thread-local object allocation.Parallel GC with 4 thread(s) Heap Configuration:   MinHeapFreeRatio = 40   MaxHeapFreeRatio = 70   MaxHeapSize      = 2067791872 (1972.0MB)   NewSize          = 1310720 (1.25MB)   MaxNewSize       = 17592186044415 MB   OldSize          = 5439488 (5.1875MB)   NewRatio         = 2   SurvivorRatio    = 8   PermSize         = 21757952 (20.75MB)   MaxPermSize      = 85983232 (82.0MB) Heap Usage:PS Young GenerationEden Space:   capacity = 6422528 (6.125MB)   used     = 5445552 (5.1932830810546875MB)   free     = 976976 (0.9317169189453125MB)   84.78829520089286% usedFrom Space:   capacity = 131072 (0.125MB)   used     = 98304 (0.09375MB)   free     = 32768 (0.03125MB)   75.0% usedTo Space:   capacity = 131072 (0.125MB)   used     = 0 (0.0MB)   free     = 131072 (0.125MB)   0.0% usedPS Old Generation   capacity = 35258368 (33.625MB)   used     = 4119544 (3.9287033081054688MB)   free     = 31138824 (29.69629669189453MB)   11.683876009235595% usedPS Perm Generation   capacity = 52428800 (50.0MB)   used     = 26075168 (24.867218017578125MB)   free     = 26353632 (25.132781982421875MB)   49.73443603515625% used   ....

使用jmap -histo[:live] pid查看堆內(nèi)存中的對(duì)象數(shù)目、大小統(tǒng)計(jì)直方圖,如果帶上live則只統(tǒng)計(jì)活對(duì)象,如下:

root@ubuntu:/# jmap -histo:live 21711 | more  num     #instances         #bytes  class name----------------------------------------------   1:         38445        5597736  <constMethodKlass>   2:         38445        5237288  <methodKlass>   3:          3500        3749504  <constantPoolKlass>   4:         60858        3242600  <symbolKlass>   5:          3500        2715264  <instanceKlassKlass>   6:          2796        2131424  <constantPoolCacheKlass>   7:          5543        1317400  [I   8:         13714        1010768  [C   9:          4752        1003344  [B  10:          1225         639656  <methodDataKlass>  11:         14194         454208  java.lang.String  12:          3809         396136  java.lang.Class  13:          4979         311952  [S  14:          5598         287064  [[I  15:          3028         266464  java.lang.reflect.Method  16:           280         163520  <objArrayKlassKlass>  17:          4355         139360  java.util.HashMap$Entry  18:          1869         138568  [Ljava.util.HashMap$Entry;  19:          2443          97720  java.util.LinkedHashMap$Entry  20:          2072          82880  java.lang.ref.SoftReference  21:          1807          71528  [Ljava.lang.Object;  22:          2206          70592  java.lang.ref.WeakReference  23:           934          52304  java.util.LinkedHashMap  24:           871          48776  java.beans.MethodDescriptor  25:          1442          46144  java.util.concurrent.ConcurrentHashMap$HashEntry  26:           804          38592  java.util.HashMap  27:           948          37920  java.util.concurrent.ConcurrentHashMap$Segment  28:          1621          35696  [Ljava.lang.Class;  29:          1313          34880  [Ljava.lang.String;  30:          1396          33504  java.util.LinkedList$Entry  31:           462          33264  java.lang.reflect.Field  32:          1024          32768  java.util.Hashtable$Entry  33:           948          31440  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;

class name是對(duì)象類(lèi)型,說(shuō)明如下:

B  byteC  charD  doubleF  floatI  intJ  longZ  boolean[  數(shù)組,如[I表示int[][L+類(lèi)名 其他對(duì)象

還有一個(gè)很常用的情況是:用jmap把進(jìn)程內(nèi)存使用情況dump到文件中,再用jhat分析查看。jmap進(jìn)行dump命令格式如下:

jmap -dump:format=b,file=dumpFileName pid

我一樣地對(duì)上面進(jìn)程ID為21711進(jìn)行Dump:

root@ubuntu:/# jmap -dump:format=b,file=/tmp/dump.dat 21711  
Dumping heap to /tmp/dump.dat ...
Heap dump file created

dump出來(lái)的文件可以用MAT、VisualVM等工具查看,這里用jhat查看:

root@ubuntu:/# jhat -port 9998 /tmp/dump.datReading from /tmp/dump.dat...Dump file created Tue Jan 28 17:46:14 CST 2014Snapshot read, resolving...Resolving 132207 objects...Chasing references, expect 26 dots..........................Eliminating duplicate references..........................Snapshot resolved.Started HTTP server on port 9998Server is ready

注意如果Dump文件太大,可能需要加上-J-Xmx512m這種參數(shù)指定最大堆內(nèi)存,即jhat -J-Xmx512m -port 9998 /tmp/dump.dat。然后就可以在瀏覽器中輸入主機(jī)地址:9998查看了:


上面紅線框出來(lái)的部分大家可以自己去摸索下,最后一項(xiàng)支持OQL(對(duì)象查詢語(yǔ)言)

2.5.jstat(JVM統(tǒng)計(jì)監(jiān)測(cè)工具)

語(yǔ)法格式如下:

jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

vmid是Java虛擬機(jī)ID,在Linux/Unix系統(tǒng)上一般就是進(jìn)程ID。interval是采樣時(shí)間間隔。count是采樣數(shù)目。比如下面輸出的是GC信息,采樣時(shí)間間隔為250ms,采樣數(shù)為4:

root@ubuntu:/# jstat -gc 21711 250 4 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT  192.0  192.0   64.0   0.0    6144.0   1854.9   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649192.0  192.0   64.0   0.0    6144.0   1972.2   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649192.0  192.0   64.0   0.0    6144.0   1972.2   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649192.0  192.0   64.0   0.0    6144.0   2109.7   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

要明白上面各列的意義,先看JVM堆內(nèi)存布局:

可以看出:

堆內(nèi)存 = 年輕代 + 年老代 + 永久代
年輕代 = Eden區(qū) + 兩個(gè)Survivor區(qū)(From和To)

現(xiàn)在來(lái)解釋各列含義:

S0C、S1C、S0U、S1U:Survivor 0/1區(qū)容量(Capacity)和使用量(Used)
EC、EU:Eden區(qū)容量和使用量
OC、OU:年老代容量和使用量
PC、PU:永久代容量和使用量
YGC、YGT:年輕代GC次數(shù)和GC耗時(shí)
FGC、FGCT:Full GC次數(shù)和Full GC耗時(shí)
GCT:GC總耗時(shí)

2.6.hprof(Heap/CPU Profiling Tool)

hprof能夠展現(xiàn)CPU使用率,統(tǒng)計(jì)堆內(nèi)存使用情況。

語(yǔ)法格式如下:

java -agentlib:hprof[=options] ToBeProfiledClass
java -Xrunprof[:options] ToBeProfiledClass
javac -J-agentlib:hprof[=options] ToBeProfiledClass

完整的命令選項(xiàng)如下:

Option Name and Value  Description                    Default---------------------  -----------                    -------heap=dump|sites|all    heap profiling                 allcpu=samples|times|old  CPU usage                      offmonitor=y|n            monitor contention             nformat=a|b             text(txt) or binary output     afile=<file>            write data to file             java.hprof[.txt]net=<host>:<port>      send data over a socket        offdepth=<size>           stack trace depth              4interval=<ms>          sample interval in ms          10cutoff=<value>         output cutoff point            0.0001lineno=y|n             line number in traces?         ythread=y|n             thread in traces?              ndoe=y|n                dump on exit?                  ymsa=y|n                Solaris micro state accounting nforce=y|n              force output to <file>         yverbose=y|n            print messages about dumps     y

來(lái)幾個(gè)官方指南上的實(shí)例。

CPU Usage Sampling Profiling(cpu=samples)的例子:

java -agentlib:hprof=cpu=samples,interval=20,depth=3 Hello

上面每隔20毫秒采樣CPU消耗信息,堆棧深度為3,生成的profile文件名稱(chēng)是java.hprof.txt,在當(dāng)前目錄。

CPU Usage Times Profiling(cpu=times)的例子,它相對(duì)于CPU Usage Sampling Profile能夠獲得更加細(xì)粒度的CPU消耗信息,能夠細(xì)到每個(gè)方法調(diào)用的開(kāi)始和結(jié)束,它的實(shí)現(xiàn)使用了字節(jié)碼注入技術(shù)(BCI):

javac -J-agentlib:hprof=cpu=times Hello.java

Heap Allocation Profiling(heap=sites)的例子:

javac -J-agentlib:hprof=heap=sites Hello.java

Heap Dump(heap=dump)的例子,它比上面的Heap Allocation Profiling能生成更詳細(xì)的Heap Dump信息:

javac -J-agentlib:hprof=heap=dump Hello.java

雖然在JVM啟動(dòng)參數(shù)中加入-Xrunprof:heap=sites參數(shù)可以生成CPU/Heap Profile文件,但對(duì)JVM性能影響非常大,不建議在線上服務(wù)器環(huán)境使用。

2.7.jconsole、jvisualvm

利用jconsole、jvisualvm分析內(nèi)存信息(各個(gè)區(qū)如Eden、Survivor、Old等內(nèi)存變化情況),如果查看的是遠(yuǎn)程服務(wù)器的JVM,程序啟動(dòng)需要加上如下參數(shù):

"-Dcom.sun.management.jmxremote=true" "-Djava.rmi.server.hostname=12.34.56.78" "-Dcom.sun.management.jmxremote.port=18181" "-Dcom.sun.management.jmxremote.authenticate=false" "-Dcom.sun.management.jmxremote.ssl=false"

下圖是jconsole界面,概覽選項(xiàng)可以觀測(cè)堆內(nèi)存使用量、線程數(shù)、類(lèi)加載數(shù)和CPU占用率;內(nèi)存選項(xiàng)可以查看堆中各個(gè)區(qū)域的內(nèi)存使用量和左下角的詳細(xì)描述(內(nèi)存大小、GC情況等);線程選項(xiàng)可以查看當(dāng)前JVM加載的線程,查看每個(gè)線程的堆棧信息,還可以檢測(cè)死鎖;VM概要描述了虛擬機(jī)的各種詳細(xì)參數(shù)。(jconsole功能演示)

下圖是jvisualvm的界面,功能比jconsole略豐富一些,不過(guò)大部分功能都需要安裝插件。概述跟jconsole的VM概要差不多,描述的是jvm的詳細(xì)參數(shù)和程序啟動(dòng)參數(shù);監(jiān)視展示的和jconsole的概覽界面差不多(CPU、堆/方法區(qū)、類(lèi)加載、線程);線程和jconsole的線程界面差不多;抽樣器可以展示當(dāng)前占用內(nèi)存的類(lèi)的排行榜及其實(shí)例的個(gè)數(shù);Visual GC可以更豐富地展示當(dāng)前各個(gè)區(qū)域的內(nèi)存占用大小及歷史信息(下圖)(jvisualvm功能演示)

工具路徑://java/jdk1.8xxx/bin/JVisuaVM.exe

監(jiān)控本地的Tomcat
監(jiān)控遠(yuǎn)程Tomcat
監(jiān)控普通的JAVA進(jìn)程

這個(gè)有不懂得可以看此文:如何利用 JConsole觀察分析Java程序的運(yùn)行,進(jìn)行排錯(cuò)調(diào)優(yōu)

2.8.jinfo

jinfo命令主要用于查看應(yīng)用程序的配置參數(shù),以及打印運(yùn)行JVM時(shí)候所指定的JVM參數(shù)。jinfo可以使用-sysprops選項(xiàng)將虛擬機(jī)進(jìn)程中所指定的System.getProperties()的內(nèi)容打印出來(lái),并且該命令還可以查看未被顯示指定的JVM參數(shù)的系統(tǒng)默認(rèn)值,這通過(guò)jps -v是無(wú)法看到的。同時(shí)jinfo命令還能夠在運(yùn)行期修改JVM參數(shù),通過(guò)使用 -flag name=value 或者 -flag [+|-]name 來(lái)修改一部分運(yùn)行期可修改的虛擬機(jī)參數(shù)

其他的一些工具如BTrace、Reference等有興趣可以自己查下資料的

2.9.依賴、參考的數(shù)據(jù)有系統(tǒng)運(yùn)行日志、堆棧錯(cuò)誤信息、gc日志、線程快照、堆轉(zhuǎn)儲(chǔ)快照進(jìn)行調(diào)優(yōu)

此處參考大佬的文章:JVM性能調(diào)優(yōu) 倒也不失為一種思路 大家可根據(jù)自己業(yè)務(wù)場(chǎng)景或者其他因素進(jìn)行篩選使用

①系統(tǒng)運(yùn)行日志:系統(tǒng)運(yùn)行日志就是在程序代碼中打印出的日志,描述了代碼級(jí)別的系統(tǒng)運(yùn)行軌跡(執(zhí)行的方法、入?yún)ⅰ⒎祷刂档龋?,一般系統(tǒng)出現(xiàn)問(wèn)題,系統(tǒng)運(yùn)行日志是首先要查看的日志。

②堆棧錯(cuò)誤信息:當(dāng)系統(tǒng)出現(xiàn)異常后,可以根據(jù)堆棧信息初步定位問(wèn)題所在,比如根據(jù)“java.lang.OutOfMemoryError: Java heap space”可以判斷是堆內(nèi)存溢出;根據(jù)“java.lang.StackOverflowError”可以判斷是棧溢出;根據(jù)“java.lang.OutOfMemoryError: PermGen space”可以判斷是方法區(qū)溢出等。
③GC日志:程序啟

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://www.ezyhdfw.cn/yun/123898.html

相關(guān)文章

  • 面試官問(wèn)我JVM調(diào)優(yōu),我忍不住了!

    面試官:今天要不來(lái)聊聊JVM調(diào)優(yōu)相關(guān)的吧?面試官:你曾經(jīng)在生產(chǎn)環(huán)境下有過(guò)調(diào)優(yōu)JVM的經(jīng)歷嗎?候選者:沒(méi)有面試官:...候選者:嗯...是這樣的,我們一般優(yōu)化系統(tǒng)的思路是這樣的候選者:1. 一般來(lái)說(shuō)關(guān)系型數(shù)據(jù)庫(kù)是先到瓶頸,首先排查是否為數(shù)據(jù)庫(kù)的問(wèn)題候選者:(這個(gè)過(guò)程中就需要評(píng)估自己建的索引是否合理、是否需要引入分布式緩存、是否需要分庫(kù)分表等等)候選者:2. 然后,我們會(huì)考慮是否需要擴(kuò)容(橫向和縱向都...

    不知名網(wǎng)友 評(píng)論0 收藏0
  • JVM體系結(jié)構(gòu)與GC調(diào)優(yōu)(二)

    摘要:在設(shè)計(jì)堆的大小時(shí)。設(shè)計(jì)為比更大的數(shù)前提是內(nèi)存允許。這樣既可以降低堆調(diào)整的頻率,還可以提高系統(tǒng)的負(fù)載能力新生代調(diào)優(yōu)大小增大區(qū)。因?yàn)闀r(shí)間跟存活對(duì)象成正比新生代調(diào)優(yōu)晉升盡可能讓對(duì)象停留在中。 jvm支持的垃圾收集器組合 showImg(https://segmentfault.com/img/bVbbcTv?w=1101&h=351); 組合選擇的標(biāo)準(zhǔn) 吞吐量=應(yīng)用運(yùn)行時(shí)間/總時(shí)間 關(guān)...

    DirtyMind 評(píng)論0 收藏0
  • JVM調(diào)優(yōu)之經(jīng)驗(yàn)

    摘要:內(nèi)存設(shè)置現(xiàn)在線上業(yè)務(wù)系統(tǒng)基本物理內(nèi)存都是夠用的,不過(guò)物盡其用,我們調(diào)優(yōu)就是爭(zhēng)取讓每空間都發(fā)揮出最大的作用。區(qū)總內(nèi)存減去一個(gè)區(qū)的大小不宜過(guò)大,否則可能把物理內(nèi)存耗光。 在生產(chǎn)系統(tǒng)中,高吞吐和低延遲一直都是JVM調(diào)優(yōu)的最終目標(biāo),但這兩者恰恰又是相悖的,魚(yú)和熊掌不可兼得,所以在調(diào)優(yōu)之前要清楚舍誰(shuí)而取誰(shuí)。一般計(jì)算任務(wù)和組件服務(wù)會(huì)偏向高吞吐,而web展示則偏向低延遲才會(huì)帶來(lái)更好的用戶體驗(yàn)。 本文...

    worldligang 評(píng)論0 收藏0
  • 記一次JVM調(diào)優(yōu)

    摘要:現(xiàn)象登入生產(chǎn)環(huán)境,使用命令因?yàn)檫@時(shí)候并沒(méi)有打的,所以只能觀察現(xiàn)象。其他的可以根據(jù)這個(gè)類(lèi)推,是內(nèi)純的占用量。 前言 我們的游戲上線之初,經(jīng)常有玩家反饋卡,或者有網(wǎng)絡(luò)延遲等現(xiàn)象,造成用戶流失等現(xiàn)象,這時(shí)候我就想到是不是可能是之前的jvm配置有問(wèn)題,或者存在內(nèi)存泄露等問(wèn)題。 現(xiàn)象 登入生產(chǎn)環(huán)境,使用命令,因?yàn)檫@時(shí)候并沒(méi)有打gc的log,所以只能觀察現(xiàn)象。 jstat -gcutil 270...

    sugarmo 評(píng)論0 收藏0
  • Java性能調(diào)優(yōu)概述

    摘要:性能調(diào)優(yōu)概述性能優(yōu)化有風(fēng)險(xiǎn)和弊端,性能調(diào)優(yōu)必須有明確的目標(biāo),不要為了調(diào)優(yōu)而調(diào)優(yōu)盲目調(diào)優(yōu),風(fēng)險(xiǎn)遠(yuǎn)大于收益程序性能的主要表現(xiàn)點(diǎn)執(zhí)行速度程序的反映是否迅速,響應(yīng)時(shí)間是否足夠短內(nèi)存分配內(nèi)存分配是否合理,是否過(guò)多地消耗內(nèi)存或者存在內(nèi)存泄漏啟動(dòng)時(shí)間程序 [TOC] Java性能調(diào)優(yōu)概述 性能優(yōu)化有風(fēng)險(xiǎn)和弊端,性能調(diào)優(yōu)必須有明確的目標(biāo),不要為了調(diào)優(yōu)而調(diào)優(yōu)!?。∶つ空{(diào)優(yōu),風(fēng)險(xiǎn)遠(yuǎn)大于收益?。?! 程序性...

    ad6623 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<